UNIDAD I UNIDAD II

UNIDAD III
UNIDAD IV

UNIDAD V
UNIDAD VI

INTRODUCCION A LA INGENIERIA DE SOFTWARE

REQUISITOS DEL SOFTWARE

MODELADO DE ANALISIS

INGENIERIA DE DISEO

DISEO A NIVEL DE COMPONENTES

PRUEBAS Y METRICAS

Definiciones Consideraciones De Software y Hardware Factores De Calidad Y Productividad Bibliografa

Toda aplicacin de las ciencias fsicas, qumicas y matemticas; de la tcnica industrial y en general, del ingenio humano, a la utilizacin e invencin sobre la materia.

Instrucciones de computadora que cuando se ejecutan cumplen una funcin y tienen un comportamiento deseados, estructuras de datos que facilitan a los programadores la adecuada manipulacin de la informacin, y documentos que describen la operacin y el uso de los programas.

La Ingeniera de Software es una disciplina o rea de la Informtica o Ciencias de la Computacin, que ofrece mtodos y tcnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo.

1. El

software se desarrolla, no se fabrica en un sentido clsico. 2. El software no se desgasta. 3. La mayora del software se construye a la medida, en vez de ensamblar piezas existentes. 4. El xito se mide por la calidad de una nica entidad.

Factores humanos: El tamao y la experiencia de la organizacin de desarrollo. Factores del problema: La complejidad del problema que se debe resolver y el nmero de cambios en las restricciones o los requisitos del diseo.

Factores del proceso: Tcnicas del anlisis y diseo qu se utilizan, lenguajes y herramientas CASE y tcnicas de revisin. Factores del producto: Fiabilidad y rendimiento del sistema basado en computadora. Factores del recurso: Disponibilidad de herramientas CASE, y recursos (hardware y software).

Ingeniera De Software. Roger Pressman. Ingenieria De Software. Ian Sommerville http://www.eici.ucm.cl/Academicos/R_Villarroel/de scargas/ing_sw_ 1/ModelosProcesoSoftware.pdf
SOFTWARE RECOMENDADO:
Data architect (power designer) Enterprise Architect UML

Tareas De La Ingeniera De Requisitos Obtencin De Requisitos Desarrollo De Casos De Uso Ejemplos Construccin Del Modelo De Anlisis Bibliografa

Ingeniera De Software. Roger Pressman. Ingenieria De Software. Ian Sommerville

SOFTWARE RECOMENDADO:
Data architect (power designer) Enterprise Architect UML

Ejemplo 1
Ejemplo 2

La ingeniera de requisitos es el uso sistemtico de procedimientos, tcnicas, lenguajes y herramientas para obtener con un coste reducido el anlisis, documentacin, evolucin continua de las necesidades del usuario y la especificacin del comportamiento externo de un sistema que satisfaga las necesidades del usuario.

La IR proporciona el mecanismo apropiado para entender lo que el cliente quiere, analizar necesidades, evaluar la factibilidad, negociar una solucin razonable, especificar la solucin sin ambigedades, validar la especificacin y administrar los requisitos conforme stos se transforman en un sistema operacional. Para poder llevar a cabo todo lo anterior se requieren de siete funciones o tareas: inicio, obtencin, elaboracin, negociacin, especificacin, validacin y gestin.

Durante esta actividad los participantes de la comunidad de negocios definen un caso de negocios para la idea, tratan de identificar la amplitud y profundidad del mercado, hacen un anlisis preliminar de factibilidad, e identifican una descripcin funcional del mbito del proyecto. El objetivo de la tarea de inicio es:
establecer una comprensin bsica del problema, Las personas que quieren una solucin, La naturaleza de la solucin que se desea, y La efectividad de la comunicacin preliminar entre el cliente y el desarrollador.

Parece simple preguntarle al cliente, usuarios y otros interesados cules son los objetivos para el sistema o producto qu es lo que se debe lograr, de que forma el producto satisface las necesidades del negocio y como se utilizar el sistema, por lo que la obtencin de los requisitos es difcil, los ingenieros de requisitos deben realizar en forma organizada la actividad de recopilacin de requisitos. Christel y Kang identifican los problemas que ayudan a entender por qu es difcil la obtencin de requisitos: Problemas de mbito: mala definicin del lmite del sistema, especificacin de detalles tcnicos innecesarios. Problemas de comprensin: el cliente no est seguro de lo que necesita, desconoce el alcance de su ambiente de computo, no comprende el dominio del problema, se le dificulta expresar sus necesidades, omiten informacin, requisitos ambiguos o que chocan con los de otros usuarios. Problemas de volatilidad: requisitos cambiantes.

Esta actividad se enfoca en el desarrollo del modelo tcnico refinado de las funciones, caractersticas y restricciones del software. La elaboracin es una accin del modelado de anlisis, el resultado final es un modelo de anlisis que define el dominio de la informacin, las funciones y el comportamiento del problema.

Se trata de que el ingeniero de requisitos trate de conciliar por medio de la negociacin los diversos conflictos que pudieran surgir como:

Los clientes y los usuarios piden ms de los que se puede lograr. Los requisitos de unos entran en conflicto con los de otro. Para solucionar: Ordenar los requisitos y discutirlos con relacin a la prioridad. Identificar y analizar riesgos asociados con cada requisito. Hacer estimaciones preliminares de esfuerzo y se evala el impacto de cada requisito con el costo del proyecto y tiempo de entrega.

Es el producto de trabajo final que genera la ingeniera de requisitos. Sirve como base para las actividades de ingeniera de software subsecuentes. Describe la funcin y el desempeo de un sistema basado en computadora y las restricciones que regirn su desarrollo.

Es la evaluacin de los productos de trabajo procedentes de la ingeniera de requisitos. Examina la especificacin para asegurar que todos los requisitos de software se han establecido de manera precisa; que se han detectado las inconsistencias, omisiones y errores y que stos se han corregido, y que los productos de trabajo cumplen con los estndares establecidos para el proceso, proyecto y producto.

Es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a stos en cualquier momento mientras se desarrolla el proyecto. Para esto se pueden usar tablas de rastreabilidad, como las siguientes:
Tabla Tabla Tabla Tabla Tabla de de de de de rastreabilidad rastreabilidad rastreabilidad rastreabilidad rastreabilidad de las caractersticas. de la fuente. de dependencia. del subsistema. de la interfaz.

El formato de preguntas y respuestas propuesto en la tarea de inicio es til solo en la etapa inicial, de hecho se debe de usar para el primer encuentro y despus se debe reemplazar por un formato de obtencin de requisitos que combine elementos de la resolucin, elaboracin, negociacin y especificacin del problema.

Recopilacin conjunta de requisitos. Se han propuestos muchos enfoques para la recopilacin conjunta de requisitos. Cada uno utiliza un escenario diferente muy diferente. Pero todos aplican alguna variacin de las siguientes directrices bsicas: Las reuniones las dirige alguno de los asistentes, ya sea un ingeniero de software o un cliente. Se establecen reglas para la preparacin y la participacin. Se sugiere una agenda que sea tan formal como para cubrir todos los puntos importantes, pero tan informal como para estimular el flujo de ideas. Un moderador debe controlar la reunin. Se utiliza un mecanismo de definicin (hojas de trabajo, grficos, un tablero electrnico o un foro virtual). La meta es identificar el problema, proponer elementos de solucin, negociar diferentes enfoques y especificar un conjunto de requisitos de solucin preliminares en una atmsfera que conduzca al cumplimiento de la meta.

Para entender mejor, se presenta un escenario que describe la secuencia de eventos que conducen a la reunin para la recopilacin de requisitos y que ocurren durante la reunin y despus de sta. Los participantes escriben una solicitud del producto en 1 o 2 pginas. Se fijan un lugar, una fecha y una hora para la reunin y se selecciona un moderador. Cada asistente debe hacer una lista de: Objetos que son parte del ambiente que rodea al sistema. Servicios (procesos o funciones) que manipulan o interactan con los objetos. Restricciones (costo, tamao, reglas de negocio) . Criterios de rendimiento (velocidad, exactitud). .

El primer tpico a tratar en la reunin es la necesidad y justificacin del nuevo producto. Despus, cada participante presenta sus listas para examinarlas. En una forma ideal, cada asunto en la lista debe permitir manipularse por separado para que las listas se puedan combinar, se le hagan eliminaciones o adiciones. El grupo crea listas combinadas para cada una de las reas de los distintos tpicos. El moderador coordina el debate. La lista combinada se reduce, se incrementa o replantea para reflejar de manera apropiada el producto/sistema que se desarrollar. El objetivo es desarrollar una lista consensada en el rea de cada tpico (objetos, servicios, restricciones y rendimiento). Despus dichas listas se integran para la accin posterior.

Requisitos normales. Reflejan los objetivos y metas establecidas para un producto o sistema durante las reuniones con el cliente, por ejemplo las funciones especficas del sistema, los grficos en pantalla y los niveles de rendimiento solicitados. Requisitos esperados. Estn son tan obvios que el explcitamente, pero su insatisfaccin significativa. interaccin, correccin, facilidad de instalacin. implcitos en el producto y cliente no los establece ausencia causara una Por ejemplo facilidad de confiabilidad operacional,

Requisitos estimulantes: Reflejan las caractersticas que van ms all de las expectativas del cliente. Por ejemplo, un procesador de palabras se solicita con caractersticas estndar y el producto entregado contiene capacidades de configuracin de pgina que son satisfactorias e inesperadas.

Segn Cockburn, un caso de uso describe el comportamiento del sistema en diferentes condiciones mientras ste responde a las peticiones de uno de sus usuarios. En esencia, un caso de uso cuenta una historia estilizada de la manera en que un usuario final interacta con el sistema en un conjunto especfico de circunstancias. Sin importar su forma, un caso de uso muestra el sistema desde el punto de vista del usuario final.

El primer paso al escribir un caso de uso consiste en definir el conjunto de actores que estarn involucrados en la historia. Los actores puede ser alguien o algo que se comunica con el sistema y que es externo al sistema en s mismo. Cada actor tiene una o ms metas cuando utiliza el sistema. La obtencin de requisitos es una actividad evolutiva, por lo que no todos los actores podrn ser identificados en la primera iteracin.

Hay dos tipos de actores: Primarios: interactan para lograr la funcin requerida del sistema y obtienen el beneficio que se espera de ste. Secundarios: dan soporte al sistema de manera que los actores primarios puedan hacer su trabajo.

Proceso de venta: llega un cliente al mostrador con los artculos que quiere comprar. El cajero usa el sistema POS para registrar cada artculo vendido. El sistema presenta el total de la venta y los artculos detallados lnea por lnea. El cliente incorpora la informacin del pago, la cual es validada y registrada por el sistema. El sistema actualiza el inventario. El cliente recibe una factura del sistema y luego se va con sus artculos.

Actor principal: cajero Interesados: cajero: quiere exactitud, entrada rpida y no pagar errores. Vendedor: quiere las comisiones de las ventas actualizadas. Cliente: quiere compras y servicios rpidos con mnimo esfuerzo. Quiere prueba de compra para poder regresar. Compaa: .. Precondiciones: que el cajero se identifique. Garanta de xito (Poscondiciones): la venta es almacenada. El impuesto es calculado correctamente. Contabilidad e inventarios se actualizan, se registran las comisiones, se genera el recibo y la autorizacin del pago es aprobado y registrado.

Escenario exitoso principal (flujo bsico): 1. Llega el cliente a la caja con artculos y/o servicios para comprar 2. El cajero inicia una nueva venta 3. El cajero introduce el cdigo del art. . Extensiones (flujo alternativo) 3a. Cdigo invalido 3-6b. El cliente le dice al cajerto que cancele la venta ..

Requerimientos especiales: La respuesta de autorizacin de crdito debe ser de 30 segundos mximo. Una touch screeen. El texto debe ser visible a 1 metro. Tecnologa 1. El identificador de los artculos se lee por medio de un lector de cdigos de barra o por el teclado. 2. La firma de los pagos de crdito se captura en el recibo de papel. Pero dentro de 2 aos se predice que muchos clientes querrn una captura digital de su firma.

Frecuencia de ocurrencia: (lo que podra continuar cercanamente) - Explorar el servicio remoto de recuperacin. - Qu adecuaciones son necesarias para los diferentes tipos de negocios? - Puede el cliente usar directamente el lector de tarjeta o debe hacerlo el cajero? - .

La Plantilla que se muestra en la siguiente figura es de un caso de uso para un videojuego, el caso de uso se llama iniciar partida. Para ver todos los casos de uso consultar:
http://www.lsi.us.es/~javierj/cursos_ficheros/ 03.%20Sokoban.%20Un%20ejemplo%20de%20 plantillas.pdf

El objetivo del modelo de anlisis es describir los dominios requeridos de informacin, funcionamiento y comportamiento para un sistema basado en computadoras. El modelo cambia en forma dinmica conforme los desarrolladores aprenden ms acerca del sistema que se va a construir y los interesados entienden mejor lo que necesitan.

Ingeniera De Software. Roger Pressman. Ingenieria De Software. Ian Sommerville

SOFTWARE RECOMENDADO:
Data architect (power designer) Enterprise Architect UML

Enfoque Del Modelado De Anlisis Conceptos Del Modelado De Datos Modelado Basados En Escenarios Ejemplo Modelado Orientado al flujo Ejemplo Modelado Basado En Clases Ejemplo Bibliografa

Una visin del modelado de anlisis llamado anlisis estructurado, considera que los datos y el proceso que transforma los datos son entidades separadas. Los objetos de datos se modelan en una forma que definen sus atributos y relaciones. Los procesos que manipulan los objetos de datos se modelan de tal manera que muestran cmo transforman los datos, mientras los objetos de datos fluyen por el sistema.

Un segundo enfoque de modelado del anlisis, llamado anlisis orientado a objetos, se centra en la definicin de clases y objetos y la manera en que stos colaboran entre si para satisfacer los requisitos del sistema.

Objeto de datos: es una representacin de cualquier informacin compuesta que el software debe entender. Informacin compuesta: se refiere a algo que tiene muchas propiedades o atributos diferentes, por ejemplo: Anchura: es un valor individual, no sera un objeto de datos vlido Dimensiones: la incorporacin de anchura, altura y profundidad podran definirse como un objeto de datos.

Relaciones. Los objetos de datos estn conectados entre s de muchas maneras diferentes. Las relaciones se determinan o definen entendiendo el papel o rol que juegan los objetos de datos dentro del contexto del software que se construir. Se puede definir un conjunto de parejas objeto/relacin que definan las relaciones relevantes: Las relaciones posee y est asegurada para conducir definen las conexiones relevantes entre persona y auto.
Una persona posee un auto. Una persona est asegurada para conducir un auto.

a) Una conexin bsica entre objetos de datos

persona

automvil

b) Relaciones entre objetos de datos

persona

posee Asegurada para manejar

automvil

Aunque el xito de un sistema basado en computadora se mide en muchas formas, la satisfaccin del cliente es la principal. En la medida en que los ingenieros de software entiendan la manera en que los usuarios finales quieren interactuar con el sistema, sern ms capaces de caracterizar en forma apropiada los requisitos y construir modelos significativos de anlisis y diseo.
Por lo que el modelado de anlisis con UML comienza con la creacin de escenarios en la forma de casos de uso, diagramas de actividad y diagramas de carril.

El concepto de caso de uso es relativamente fcil de entender: describe un escenario de uso especfico en un lenguaje directo desde el punto de vista de un actor definido. Para que los casos de uso tengan un valor como herramienta para el modelado de anlisis deben contestarse las siguientes preguntas: Sobre qu escribir? Cunto escribir acerca de ello? Qu tan detallada debe ser la descripcin? Cmo organizar la descripcin?

La funcin de vigilancia en el hogar de hogar seguro identifica las siguientes funciones (lista abreviada) que realiza el actor identificado como propietario de la casa: Tener acceso a la cmara de vigilancia va internet. Seleccionar la cmara que desea ver. Solicitar vistas en miniatura de todas las cmaras. Desplegar vistas de la cmara en una ventana de una PC. Controlar la visin panormica y de acercamiento en una cmara especfica. Registrar en forma selectiva la salida de cmara. Repetir la salida de cmara. El equipo de recopilacin de requisitos desarrolla casos de uso para cada una de las funciones mencionadas. Se pueden describir en un estilo narrativo informal o se puede utilizar un formato estructurado (como el que ya vimos).

Caso de uso: Acceso a la cmara de vigilancia despliegue de vistas de cmara (ACV DVC). Actor: Propietario. Si me encuentro en un lugar lejano, puedo usar una PC con un software de navegacin apropiado para entrar al sitio WEB de los productos Hogar Seguro. Ingreso mi clave de usuario y dos niveles de contrasea y, despus de que estoy validado tengo acceso a toda la funcionalidad de mi sistema HogarSeguro instalado. Para tener acceso a la vista de una cmara especfica selecciono vigilancia de los botones desplegados para las funciones ms importantes. Despus escojo seleccionar una cmara y se despliega un plano de planta de la casa. Entonces selecciono la cmara en la que estoy interesado. En forma alterna puedo ver una simultneamente una lista con vistas en miniatura de todas las cmaras a l seleccionar todas las cmaras como mi opcin de visualizacin. Una vez que he seleccionado una cmara, selecciono vista y una vista de un cuadro por segundo aparece en una ventana, a la cual identifica la cmara clave. Si quiero cambiar de cmara elijo seleccionar una cmara y la ventana de visin original desaparece y se despliega de nuevo el plano de planta de la casa.

Caso de uso: Acceso a la cmara de vigilancia despliegue de vistas de cmara (ACV DVC). Actor: Propietario. 1. El propietario entra en el sitio WEB de HogarSeguro. 2. El propietario introduce su clave de usuario. 3. El propietario introduce las contraseas (c/u de al menos 8 caracteres). 4. El sistema despliega todos los botones de las funciones ms importantes. 5. El propietario selecciona vigilancia. 6. El propietario elije seleccionar una cmara 7. El sistema despliega el plano de planta de la casa. 8. El propietario selecciona un cono de cmara del plano de planta. 9. El propietario selecciona el botn vista. 10. El sistema despliega una ventana de visin, identificado por la clave de la cmara. 11. El sistema muestra salida de video dentro de la venta de visin con una velocidad de un marco por segundo.

La representacin diagramtica puede facilitar la comprensin de un escenario de uso, en particular cuando este es complejo. UML proporciona una capacidad para hacer diagramas de casos de uso. Cada caso de uso se representa mediante un valo.

Hogar Seguro Acceso a la cmara de vigilancia va internet Configurara sistema

Cmaras

Propietario de la casa

Configurar alarma

El diagrama de actividad en UML complementa el caso de uso al proporcionar una representacin grfica del flujo de interaccin de un escenario especfico. Notacin:
Los rectngulos con esquinas redondeadas representan funciones. Las flechas representan el flujo a travs del sistema. Los rombos representan decisiones Lneas horizontales slidas para indicar que ocurren actividades paralelas.

Diagrama de actividades para la Introducir contrasea funcin de acceso a la e ID de usuario cmara de vigilanciadespliegue de vistas Contraseas/ID de cmara Contraseas/ID vlidas no vlidas Selecciona una Funcin importante
Seleccionar vigilancia

Opcin para reingreso Restan intentos

Vistas en miniatura Selecciona una Cmara especifica

Seleccionar una cmara especifica

Selecciona un icono de cmara

No restan intentos

Ver la salida de una cmara en una ventana etiquetada

Salir de esta funcin

Opcin para otra vista

Ver otra cmara

El modelo de datos orientado al flujo es una de las notaciones de anlisis ms utilizadas. El diagrama de flujo de datos (DFD) tiene una visin del sistema del tipo entrada-procesosalida. Esto significa que los objetos de datos fluyen hacia el interior del software se transforman mediante elementos de procesamiento, y los objetos de datos resultantes fluyen al exterior del software.

El DFD se representa en forma jerrquica, esto es, el primer modelo de flujo de datos (DFD de nivel 0 o diagrama de contexto) representa el sistema como un todo. Los DFD subsecuentes refinan el diagrama de contexto, ya que proporcionan una cantidad creciente de detalles con cada nivel subsecuente.

Para ilustrar el uso de estas recomendaciones, se usar como ejemplo el sistema de seguridad Hogar seguro, a continuacin se presenta una narrativa de procesamiento para Hogar seguro: El software Hogar Seguro permite al propietario de la vivienda configurar el sistema de seguridad al instalarlo; controla todos los sensores conectados al sistema de seguridad e interacta con el propietario a travs de un teclado numrico y unas teclas de funcin que se encuentran en el panel de control de Hogar Seguro

Durante la instalacin se usa el panel de control de Hogar Seguro para programar y configurar el sistema. Cada sensor tiene asignado un nmero y un tipo; existe una contrasea maestra para activar y desactivar el sistema, y se introduce(n) un(os) telfono(s) con los que contactar cuando se produce un suceso detectado por un sensor. Cuando el software detecta la sensorizacin de un suceso. Hace que suene una alarma audible que est incorporada en el sistema. Tras un retardo, especificado por el propietario durante la configuracin del sistema, el programa marca un nmero de telfono de un servicio de monitorizacin, proporciona informacin sobre la situacin e informa sobre la naturaleza del suceso detectado.

Cada 20 segundos se volver a marcar el nmero de telfono hasta que se consiga establecer comunicacin. Toda la interaccin con Hogar Seguro est gestionada por un subsistema de interaccin con el usuario que lee la informacin a travs del teclado numrico y las teclas de funcin, muestra mensajes de peticin en un monitor LCD y nuestra informacin sobre el estado del sistema en el mismo monitor

Panel de control
Comandos y datos de usuario Interactuar con el usuario Contrase a

Configurar sistema
Peticin de Configuraci n

Datos de Configuraci n Informacin de Configuraci n Datos de Configuraci n

Subsistema de interaccin con el usuario

Iniciar/deten er

Activar/ desactivar sistema

Mensaje de A/D Desplegar mensajes y estatus

Monitor de Panel de Control

Procesar contrase Mensaje de ID vlido a Datos de Configuraci n

Desplegar informacin

Sensores

Estatus del Sensor

Monitorear sensores

Informacin del sensor Tipo de alarma Tonos del nmero telefnico

Alarma Lnea Telefnica

DFD de nivel 1 para HogarSeguro

Al mirar al interior de una habitacin se ver que existe un conjunto de objetos fsicos que pueden identificarse, clasificarse y definirse con facilidad (atributos y operaciones). Pero cuando se observa el espacio del problema de una aplicacin de software quizs las clases y los objetos sean ms difciles de comprender. Se puede iniciar la identificacin de clases al examinar el enunciado del problema, haciendo un anlisis gramatical sobre las narrativas o sobre los casos de uso. Las clases se determinan al localizar cada sustantivo, los sinnimos deben anotarse.

Las clases se manifiestan en una de las siguientes formas: Entidades externas, por ejemplo personas, dispositivo, otros sistemas que producen o consumen informacin que usar el sistema Cosas, como reportes, despliegues, letras o seales que son parte del dominio de informacin del problema. Sucesos o eventos que ocurren dentro del contexto de la operacin de un sistema. Papeles que desempean personas que interactan con el sistema (p.ej.: gerente, ingeniero, personal de venta, cajero, etc.). Unidades organizacionales relevantes para alguna aplicacin, por ejemplo divisin, grupo, equipo, etc. Sitios, por ejemplo el puerto de carga, el rea de manufactura, etc. Que establecen el contexto del problema y la funcin global del sistema Estructuras que definen una clase de objetos o clases de objetos relacionados, por ejemplo: sensores, vehculos de cuatro ruedas, computadoras, etc.

En un sistema automatizado para punto de venta, dos de las abstracciones clave incluyen productos y ventas.

Se puede establecer una asociacin simple entre estas dos clases: la clase Producto denota los productos que se venden como parte de una venta, y la clase Venta denota la transaccin por la cual varios productos acaban de venderse. Esta asociacin sugiere una relacin bidireccional: dada una instancia de Producto, deberamos ser capaces de encontrar el objeto que denota su venta y, dada una instancia de Venta, deberamos ser capaces de localizar todos los productos vendidos en esa transaccin.

Producto

1.. *

Venta

Esto se puede representar en C++, consideremos la declaracin muy resumida de estas dos clases: class Producto; class Venta { class Venta; public: class Producto { .. public: protected: .. Producto ** protected: productoVendido; Venta * ultimaVenta; }; }; Aqu se muestra una asociacin uno-a-muchos: cada instancia de Producto puede tener un apuntador a su ltima venta, y cada instancia de Venta puede tener una coleccin de apuntadores que denota los productos vendidos en esa venta.

Conceptos De Diseo El Modelo Del Diseo Diseo De Software Basado En Patrones Diseo Arquitectnico Estilos Y Patrones Arquitectnicos Evaluacin De Diseos Arquitectnicos Bibliografa

Ingeniera De Software. Roger Pressman. Ingenieria De Software. Ian Sommerville SOFTWARE RECOMENDADO:
Data architect (power designer) Enterprise Architect UML

El diseo de software es la ltima accin de la ingeniera correspondientes a la actividad de modelado, la cual establece una plataforma para la construccin (generacin de cdigo y pruebas). Cada uno de los elementos de anlisis proporciona la informacin necesaria para crear los cuatro modelos que se requieren para una especificacin completa de diseo.

Conceptos De Diseo
La importancia del diseo del software se puede expresar con una sola palabra: CALIDAD El diseo proporciona las representaciones del software que pueden evaluarse respecto a la calidad. El diseo de software sirve como fundamento para todas las actividades subsecuentes de la IS y del soporte del sistema. Sin diseo se construye un sistema inestable; que fallar en cuanto se realicen cambios pequeos; que ser difcil de probar; cuya calidad no se pueda evaluar sino hasta etapas tardas, cuando queda poco tiempo y se ha gastado mucho dinero en l.

Mantenimient o
Mantenimiento Prueba Implementacin Prueba Implementacin

Diseo Con diseo

Sin diseo

Es una de las formas fundamentales en las que el humano enfrenta la complejidad . La abstraccin es el examen selectivo de ciertos aspectos de un problema. Su finalidad es aislar aquellos aspectos que sean importantes para algn objetivo y suprimir los aspectos que no lo sean. La abstraccin siempre debe hacerse con algn objetivo prefijado, porque el propsito determina lo que es y lo que no es importante.

La arquitectura del software es el proceso de disear la organizacin global de un sistema software, incluye la divisin del software en subsistemas, decisiones de cmo van a interactuar los subsistemas y determinar sus interfaces. Los ingenieros de software discuten todos los aspectos del diseo de un sistema en trminos del modelo arquitectnico. Por lo tanto, las decisiones hechas mientras este modelo est siendo desarrollado, tienen un profundo impacto sobre el resto de las actividades del proceso de diseo. El modelo arquitectnico es el ncleo del diseo, as que todos los miembros del equipo de desarrollo necesitan entenderlo.

Hay 4 razones principales por las que es necesario desarrollar un modelo arquitectnico: 1. Permitir un mejor entendimiento del sistema 2. Permitir que la gente trabaje en piezas individuales del sistema en forma aislada. 3. Prepararse para la extensin del sistema. 4. Facilitar la reusabilidad.

El software se divide en componentes con nombres independientes y que es posible abordar en forma individual. Estos componentes llamados mdulos se integran para satisfacer los requisitos del problema. Se ha dicho que la modularidad es el atributo particular del software que permite que un programa sea manejable de manera intelectual. El software monoltico (un gran programa compuesto de un nico mdulo) no puede ser entendido fcilmente por un lector.

El refinamiento es un proceso de elaboracin. Se inicia en el enunciado de una funcin (o una descripcin de datos) que se define con un alto grado de abstraccin, es decir el enunciado describe la funcin o los datos de manera conceptual pero no proporciona informacin acerca de los trabajos internos de la funcin o de la estructura interna de los datos. El refinamiento hace que el diseador trabaje sobre el enunciado original y que conforme se realiza cada refinamiento (elaboracin) sucesivo proporcione ms y ms detalles.

El modelo de diseo puede verse en dos dimensiones diferentes: La dimensin del proceso: indica la evolucin del modelo de diseo conforme se ejecutan las tareas de diseo como una parte del proceso del software. La dimensin de abstraccin: representa el grado de detalle a medida que cada elemento del modelo de anlisis se transforma en un equivalente del diseo y despus se refina de una manera iterativa.

alto Modelo de anlisis

Diagrama de clases Paquetes de anlisis Diagramas de flujo de datos Narrativas de procesamiento Diagramas de estado Diagramas de secuencia

Dimensin de Abstraccin

Diagrama de clases Paquetes de anlisis Diagramas de flujo de datos Narrativas de procesamiento

Casos de uso Diagrama de casos de uso Diagramas de estado Diagrama de secuencia

Requisitos: Restricciones Interoperabilidad Objetivos y configuracin

Modelo de diseo baj o

Realizaciones de clases de diseo Diagramas de Diseo de interfase Subsistemas componente Diagramas de colaboracin tcnica Clases de diseo Realizacin de clases de diseo Diseo de navegacin Diagramas de actividad Subsistemas Diseo de IGU Diagramas de secuencia Diagramas de colaboracin Diagramas de componente Clases de diseo Diagramas de actividad Refinamientos a: Refinamientos a: Diagramas de secuencia Realizaciones de clases Diagramas de de diseo componente Subsistemas Clases de diseo Diagramas de Diagramas de actividad colaboracin Diagramas de secuencia Elementos Arquitectnicos Elem. de interfaz Diagramas de despliegue Elem. al nivel de componentes Elem. al nivel de despliegue

Dimensin del proceso

Conforme se obtiene experiencia en el desarrollo de software OO, se empieza a notar que muchas partes de los diseos reaparecen, con solamente algunos insignificantes cambios, en muchos diferentes sistemas o subsistemas. Estos aspectos recurrentes de diseo son llamados patrones de diseo. Muchos de ellos han sido documentados sistemticamente para que todos lo desarrolladores de software los usen. Definiciones: Un patrn es un par problema/solucin con nombre que se puede aplicar a nuevos contextos, con consejos acerca de cmo aplicarlo en nuevas situaciones. Un patrn es el resultado de una solucin reusable para un problema general encontrado en un contexto particular.

Nombre del patrn: describe la esencia del patrn en un nombre corto pero expresivo. Intencin: Describe el patrn y lo que hace. Tambin-conocido-como: lista de los sinnimos para el patrn. Motivacin: proporciona un ejemplo del problema. Aplicabilidad: situaciones especficas de diseo en las cuales es aplicable el patrn Estructura: describe las clases que se requieren para implementar el patrn. Participantes: describe las responsabilidades de las clases que se requieren para implementar el patrn. Colaboraciones: describe cmo colaboran los participantes para llevar a cabo sus responsabilidades. Consecuencias: describe las fuerzas de diseo que afectan al patrn y los intercambios potenciales que deben considerarse cuando se implementa el patrn. Patrones relacionados: patrones de diseo relacionados mediante referencias cruzadas.

El diseo arquitectnico representa la estructura de datos y los componentes de programa necesarios para construir un sistema computacional. Asume el estilo arquitectnico que tomar el sistema y las interrelaciones entre todos los componentes arquitectnicos de un sistema. La arquitectura del software de un programa o sistema de computo es la estructura del sistema, que incluyen los componentes del software, las propiedades visibles externamente de los componentes y las relaciones entre ellos

La arquitectura es la representacin que permite que un ingeniero de software: 1. Analice la efectividad del diseo para cumplir con los requisitos establecidos. 2. Considere opciones arquitectnicas en una etapa en que an resulta relativamente fcil hacer cambios al diseo y, 3. Reduzca los riesgos asociados con la construccin del software.

Razones claves por las cuales la arquitectura del software es importante: Las representaciones de la arquitectura del software permiten la comunicacin entre todas las partes (participantes) interesadas en el desarrollo del sistema. La arquitectura destaca las decisiones inciales relacionadas con el diseo que tendrn un impacto profundo en todo el trabajo de la IS que le sigue, y tambin en el xito final del sistema. La arquitectura constituye un modelo relativamente pequeo e intelectualmente comprensible de cmo est estructurado el sistema y como trabajan juntos sus componentes.

Un estilo arquitectnico es un mecanismo descriptivo para diferenciar una construccin de otra (en el contexto de la construccin de edificios). Pero algo ms importante es que el estilo arquitectnico es una plantilla para la construccin, resultar necesario proporcionar mayores detalles, agregar caractersticas personales, etc. Pero el estilo que se haya elegido es el que gua el trabajo del constructor. El software que se construye para sistemas de computo puede mostrar uno o muchos estilos arquitectnicos.

Cada estilo describe una categora de sistemas que abarca: 1. Un conjunto de componentes que realizan una funcin requerida por el sistema. 2. Un conjunto de conectores que permiten la comunicacin, coordinacin y cooperacin entre los componentes. 3. Restricciones que definen cmo se integran los componentes para formar el sistema. 4. Modelos semnticos que permiten a un diseador, mediante el anlisis de las propiedades conocidas de las partes que lo integran, comprender las propiedades generales de un sistema.

En el centro de esta arquitectura se encuentra un almacn de datos (base de datos o archivos); otros componentes tienen acceso a l y cuentan con la opcin de agregar, eliminar o modificar los datos de ese almacn. Una arquitectura centrada en datos promueve la capacidad de integracin, esto significa que es posible cambiar componentes existentes y agregar nuevos componentes cliente a la arquitectura sin ningn problema, ya que los componentes cliente operan de manera independiente.

Software cliente

Software cliente

Software cliente

Software cliente

Almacn de datos

Software cliente

Software cliente

Software cliente

Software cliente

Esta arquitectura se aplica cuando los datos de entrada se habrn de transformar en datos de salida mediante una serie de componentes para el clculo o la manipulacin. Se representa mediante una estructura de tuberas y filtros, en la que los componentes se denomina filtros que estn conectados por tuberas que transmiten datos de un componente al siguiente. Cada filtro funciona sin tomar en cuenta el flujo de los componentes (ascendente o descendente), est diseado para esperar la entrada de datos con cierta forma y producir su salida de una manera especfica. No es necesario que un filtro conozca el funcionamiento de los filtros vecinos.

Filtro

Filtro

Filtro

Filtro

Filtro
Filtro Filtro Tuberas y Filtros Filtro

Filtro
Filtro

Arquitectura orientada a objetos: Los componentes de un sistema encapsulan los datos y las operaciones que deben aplicarse para manipular los datos. La comunicacin y coordinacin entre componentes se consigue mediante el paso de mensajes. Arquitectura estratificada: Aqu se definen varias capas, cada una de ellas realiza operaciones que se acercan progresivamente al conjunto de instrucciones de la mquina. En la capa externa los componentes sirven a las operaciones de interfaz de usuario. En la capa interna los componentes sirven como interfaz con el sistema operativo. Las capas intermedias proporcionan servicios de utilera y de software de aplicaciones.

Definicin De Componente Diseo De Componentes Basado En Clases Diseo De Interfaces De Usuario Reglas En El Diseo De Interfaces Pasos En El Diseo De Interface Bibliografa

Ingeniera De Software. Roger Pressman. Ingenieria De Software. Ian Sommerville http://ingenieria.uatx.mx/labastida/files/201 1/08/DISE%C3%91OS-DE-COMPONENTESBASADOS-EN-CLASES.pdf
SOFTWARE RECOMENDADO:
Data architect (power designer) Enterprise Architect UML

Es un bloque de construccin modular para el software. La OMG define un componente como una parte modular, desplegable y reemplazable de un sistema que encapsula implementacin y expone un conjunto de interfaces.

Hay 4 principios bsicos de diseo que se pueden aplicar: Principio abierto-cerrado: Un componente debe estar abierto a extensiones pero debe estar cerrado para modificaciones. Principio de substitucin de Liskov: Las subclases deben ser sustituibles por sus clases bases. Cualquier clase derivada de una clase base debe cumplir con cualquier contrato implcito de la clase base con respecto a los componentes que la usan.

Principio de dependencia de inversin: Se debe depender de abstracciones, no de eventos concretos Principio de segregacin de interfaces: Varias interfaces dependientes del cliente son mejor que una interfaz de propsito general

El diseo de la interfaz se concentra en tres reas:

1. El diseo de interfaces entre componentes de software. 2. El diseo de interfaces entre el software y otros productos y consumidores de informacin que no son humanos. 3. El diseo de la interfaz entre un ser humano y la computadora

1. 2. 3.

Dar el control al usuario. Reducir la carga en la memoria del usuario. Lograr que la interfaz sea consistente.

Estas reglas forman la base de un conjunto de principios de diseo de interfaces de usuario que servirn de gua en esta importante accin de diseo de software.

Mandel define varios principios de diseo que permiten al usuario mantener el control: Definir los modos de interaccin de modo que el usuario no realice acciones innecesarias o indeseables. Proporcionar una interaccin flexible. Incluir las opciones de interrumpir y deshacer la interaccin del usuario. Depurar la interaccin a medida que aumentan los grados de destreza y permitir que se personalice la interaccin. Oculte al usuario ocasional los elementos tcnicos internos. Disear interaccin directa con los objetos que aparecen en la pantalla.

Principios para lograr la regla 2, reducir la carga en la memoria del usuario: Reducir la demanda de memoria a corto plazo. Definir valores por defecto que tengan significado. Definir accesos directos intuitivos. El formato visual de la interfaz debe basarse en una metfora tomada de la realidad. Desglosar la informacin de manera progresiva.

Principios que ayudan a construir una interfaz consistente: Permitir que el usuario incluya la tarea actual en un contexto que tenga algn significado. Mantener la consistencia en toda una familia de aplicaciones. Si modelos interactivos anteriores han generado expectativas en el usuario, no hacer cambios a menos que haya razones inexcusables.

1.

2.

3.

4.

Con base en la informacin desarrollada durante el anlisis de informacin, definir los objetos y las acciones de la interfaz. Definir eventos (acciones de usuario) que cambiarn el estado de la interfaz. Modelar este comportamiento. Representar cada estado de la interfaz como lo ver el usuario final. Indicar cmo interpreta el usuario el estado del sistema a partir de la interfaz proporcionada mediante la interfaz.

Fundamentos De Las Pruebas Del Software Pruebas De Caja Negra Y Blanca Mtodos De Pruebas Orientadas A Objetos Bibliografa

Ingeniera De Software. Roger Pressman. Ingenieria De Software. Ian Sommerville

SOFTWARE RECOMENDADO:
Data architect (power designer) Enterprise Architect UML

Las pruebas representan un interesante reto para los ingenieros de software. Las pruebas requieren que el desarrollador descarte nociones preconcebidas de lo que es correcto en el software y entonces disee difciles casos de prueba para romperlo. Una vez generado el cdigo fuente, es necesario probar el software para descubrir (y corregir) la mayor cantidad de errores posibles antes de entregarlo al cliente. El objetivo es disear una serie de casos de prueba que tengan una alta probabilidad de encontrar errores mediante tcnicas de prueba del software.

Estas tcnicas proporcionan directrices sistemticas para pruebas de diseo que: Comprueben la lgica interna y las interfaces de todo componente de software y Comprueben los dominios de entrada y salida del programa para descubrir errores en su funcin, comportamiento y desempeo.

El objetivo de las pruebas es encontrar errores. Se dice que una buena prueba es aquella que tiene una alta probabilidad de encontrar un error. Por lo que un ingeniero de software debe tener en mente la facilidad de prueba al disear e implementar un sistema de computo. La facilidad de prueba del software indica si es fcil o no probar un programa de computadora.

Hay dos maneras de probar cualquier producto construido: 1. Si se conoce la funcin especfica para la que se dise el producto, se aplican pruebas que demuestren que cada funcin es plenamente operacional, mientras se buscan los errores de cada funcin (prueba de caja negra). 2. Si se conoce el funcionamiento interno del producto, se aplican pruebas para asegurarse de que todas las piezas encajan, es decir, que las operaciones internas se realizan de acuerdo con las especificaciones, y que se han probado todos los componentes internos de manera adecuada (prueba de caja blanca).

Se basa en un examen cercano al detalle procedimental, se prueban las rutas lgicas del software y la colaboracin entre componentes, al proporcionar casos de prueba que ejerciten conjuntos especficos de condiciones, bucles o ambos. Al emplear los mtodos de prueba de caja blanca, el ingeniero de software podr derivar casos de prueba que: 1. Garanticen que todas las rutas independientes dentro del mdulo se han ejecutado por lo menos una vez. 2. Se ejecuten los lados verdadero y falso de todas las decisiones lgicas. 3. Se ejecuten todos los bucles en sus limites y dentro de sus lmites operacionales. 4. Ejerciten estructuras de datos internos para asegurar su validez.

Tambin se les llama prueba de comportamiento, son las que se aplican a la interfaz del software. Una prueba de este tipo examina algn aspecto funcional de un sistema que tiene poca relacin con la estructura lgica interna del software. Se concentran en los requisitos funcionales, permiten al ingeniero de software derivar conjuntos de condiciones de entrada que ejerciten por completo todos los requisitos funcionales de un programa. La prueba de caja negra no es una opcin frente a las tcnicas de caja blanca, sino un enfoque complementario que tiene probabilidades de descubrir una clase diferente de errores de los que se descubriran con mtodos de caja blanca.

La arquitectura del software OO genera una serie de subsistemas separados en capas que encapsulan las clases que colaboran entre si. Cada uno de estos elementos del sistema (subsistemas y clases) realiza funciones que ayudan a cumplir con los requisitos del software. Es necesario probar un sistema OO en diferentes niveles para descubrir errores que podran ocurrir a medida que las clases colaboran entre si y los subsistemas se comunican entre las capas de la arquitectura.
11 5