Anlisis Orientado a Objetos Ingeniera de software 2

Introduccin al anlisis Orientado a Objetos (AOO) Contenido del seminario. Porqu orientado a objetos? Definiciones generales Ciclo de vida de un proyecto Actividades del estudio de factibilidad Actividades de anlisis Actividades de diseo Objetivos Identificar las ventajas e usar Orientacin a objetos Definir los trminos ms importantes del Anlisis y diseo Orientado a Objetos. Diferenciar el Anlisis estructurado y el Anlisis Orientado a Objetos. Porqu disear Sistemas orientados a objetos Se requiere implementar soluciones estratgicas en el menor tiempo posible. Disminucin de costos con alta calidad y oportuno aprovechamiento de tecnologas emergentes. Se propone disear sistemas con Arquitectura Orientada a Objetos para crear estructuras estables. Evolucin Estratgica de Procesamiento de datos La ventaja competitiva de las organizaciones depende de la velocidad de implementacin de las decisiones estratgicas del negocio. La mayora de cambios estratgicos deben apoyarse en soluciones tecnolgicas que crean nuevas oportunidades de negocio mejorando el servicio al cliente. Evolucin Primeramente existi Orientacin a Procesos Fundamentado en Anlisis y diseo estructurado. Documentos tcnicos principales: Especificacin de requerimientos Descomposicin funcional Diagramas de flujo de datos. Diagramas de estructuras. Los Procesos no son estables Evolucin Luego existi Orientacin a Datos Fundamentada en ingeniera de la informacin (modelamiento de datos). Documentos tcnicos principales: Especificacin de requerimientos o descripcin del negocio. Modelo entidad relacin: lgico y fsico. Diagrama de jerarqua de procesos Matriz de uso Entidad-Proceso. Los datos no son estables. Demasiada documentacin que actualizar. Ahora Orientacin a Objetos Fundamentada en objetos que interactan dentro de un sistema Documentos tcnicos principales: Especificacin de requerimientos o del negocio. Casos de uso.

Diagramas de clases. Diagramas de interaccin o interaccin de mensajes. Diagramas de estados. OBJETOS Se definir un objeto como un concepto, abstraccin o cosa con lmites bien definidos y con significado a efectos del problema que se tenga entre manos. Los objetos tienen dos propsitos: promover la comprensin del mundo real y proporcionar una base prctica para la implementacin por computadora Ejemplo de objetos

Qu es orientado a Objetos? El trmino orientado a objetos significa que el software se organiza como una coleccin de objetos discretos que contienen tanto estructuras de datos como un comportamiento. Ejemplo 1 Pensar en trminos de objetos es muy parecido a cmo lo haramos en la vida real. Por ejemplo vamos a pensar en un coche para tratar de modelizarlo en un esquema de POO. Diramos que el coche es el elemento principal que tiene una serie de caractersticas, como podran ser el color, el modelo o la marca. Adems tiene una serie de funcionalidades asociadas, como pueden ser ponerse en marcha, parar o aparcar. Pues en un esquema POO el coche sera el objeto, las propiedades seran las caractersticas como el color o el modelo y los mtodos seran las funcionalidades asociadas como ponerse en marcha o parar.

Ejemplo 2 Por poner otro ejemplo vamos a ver cmo modelizaramos en un esquema POO una fraccin, es decir, esa estructura matemtica que tiene un numerador y un denominador que divide al numerador, por ejemplo 3/2. La fraccin ser el objeto y tendr dos propiedades, el numerador y el denominador. Luego podra tener varios mtodos como simplificarse, sumarse con otra fraccin o nmero, restarse con otra fraccin, etc. Estos objetos se podrn utilizar en los programas, por ejemplo en un programa de matemticas hars uso de objetos fraccin y en un programa que gestione un taller de coches utilizars objetos coche.

Los programas Orientados a objetos utilizan muchos objetos para realizar las acciones que se desean realizar y ellos mismos tambin son objetos. Es decir, el taller de coches ser un objeto que utilizar objetos coche, herramienta, mecnico, recambios, etc. Caractersticas de los Objetos Identidad. Clasificacin. Poliformismo y Herencia. Caractersticas de los Objetos Identidad, quiere decir que los datos estn cuantificados en entidades discretas y distinguibles denominadas objetos. Ejemplo: Un prrafo de un documento, una ventana de mi estacin de trabajo y la reina blanca de un juego de ajedrez podran ser tomados como objetos. Caractersticas de los Objetos Clasificacin, significa que los objetos con la misma estructura de datos (atributos) y comportamientos (operaciones) se aglutinan para formar una clase. Ejemplo: vehculos, Prrafo, ventana y PiezadeAjedrez son ejemplos de clases. Una clase es una abstraccin que describe propiedades importantes para una aplicacin y que ignora el resto.

Abstraccin Abstraccin consiste en aislar un elemento de su contexto o del resto de los elementos que lo acompaan. En programacin, el trmino se refiere al nfasis en el "qu hace?" ms que en el "cmo lo hace?". Caractersticas de los Objetos Poliformismo, significa que una misma operacin puede comportarse de modos distintos en distintas clases. La operacin mover, por ejemplo, se puede comportar de modo distinto en las clases ventana y PiezaDeAjedrez. Una Operacin es una accin o de transformacin que se lleva a cabo o que se aplica a un objeto.

Justificar a la derecha, visualizar y mover son ejemplos de operaciones Caractersticas de los Objetos Herencia, es compartir atributos y operaciones entre clases tomando como base una relacin jerrquica. En trminos generales se puede definir una clase que despus se ir refinando sucesivamente para producir subclases. Todas las subclases poseen o heredan, todas y cada una de las propiedades de su superclase y aaden, a adems, sus propiedades exclusivas. Por ejemplo: Ventana de desplazamiento, ventana fija son subclases de ventana. Ambas subclases heredan las propiedades de la clase ventana Temas Orientados a Objetos Abstraccin, consiste en centrarse en los aspectos esenciales inherentes de una entidad, e ignorar sus propiedades accidentales. En el desarrollo de sistemas esto significa centrarse en lo que es y lo que hace un objeto antes de decidir cmo debera ser implementado. La gran mayora de lenguajes modernos proporcionan abstraccin de datos pero la capacidad de utilizar herencia y polimorfismo proporciona una potencia adicional. El uso de la abstraccin durante el anlisis significa tratar solamente conceptos del dominio de la aplicacin y no tomar decisiones de diseo o de implementacin antes de haber comprendido el problema. Temas Orientados a Objetos Encapsulacin, (denominada tambin ocultamiento de la informacin) consiste en separar los aspectos externos del objeto, a los cuales pueden acceder otros objetos, de los detalles internos de implementacin del mismo, que quedan ocultos para los dems. La encapsulacin evita que el programa llegue a ser tan interdependiente que un pequeo cambio tenga efectos secundarios masivos. Diferencias con la programacin estructurada Aunque la programacin estructurada (a veces llamada procedural o procedimental) condujo a mejoras de la tcnica de programacin secuencial, los mtodos modernos de diseo de software orientado a objetos incluyen mejoras entre las que estn el uso de los patrones de diseo, diseo por contrato, y lenguajes de modelado (ej: UML). Las principales diferencias entre la programacin estructurada y la orientada a objetos son: La programacin orientada a objetos es ms moderna, es una evolucin de la programacin estructurada que plasma en el diseo de una familia de lenguajes conceptos que existan previamente con algunos nuevos. 2. La programacin orientada a objetos se basa en lenguajes que soportan sintctica y semnticamente la unin entre los tipos abstractos de datos y sus operaciones (a esta unin se la suele llamar clase). 3. La programacin orientada a objetos incorpora en su entorno de ejecucin mecanismos tales como el polimorfismo y el envo de mensajes entre objetos. Metodologa orientada a objetos La metodologa consiste en construir un modelo de un dominio de aplicacin aadindosele detalles de implementacin durante el diseo de un sistema. Esta aproximacin se denomina la tcnica de Modelado de Objetos (OMT). Dicha metodologa consta de las siguientes fases: Tcnica de Modelado de Objetos (OMT)

1.

Fases de la OMT: 1.- Anlisis: Comenzando desde la descripcin del problema el analista construye un modelo de la situacin del mundo real que muestra sus propiedades importantes. Dicho analista debe trabajar con quin hace la solicitud para comprender el problema ms porque las definiciones del mismo no suelen ser completas ni correctas El modelo de anlisis es una abstraccin resumida y precisa de lo que debe hacer el sistema deseado y no la forma en que se har. 2.- Diseo del sistema: el diseador de sistemas toma decisiones de alto nivel acerca de la arquitectura global. Durante el diseo, el sistema de destino se organiza en subsistemas basados tanto en la estructura del anlisis como en la arquitectura propuesta. Deber decidir qu caractersticas de rendimiento hay que optimizar. Seleccionando una estrategia para atacar el problema y efectuando unas reservas de recursos tentativas. Por ejemplo, el diseador del sistema podra decidir que los cambios habidos en la pantalla de la estacin de trabajo sean rpidos y suaves aunque se muevan o borren las ventanas y seleccionar un protocolo de comunicaciones adecuado as como una estrategia de reserva de memoria. 3.- Diseo de objetos: el diseador de objetos construye un modelo de diseo basndose en el modelo de anlisis que lleven incorporados detalles de implementacin. El diseador aade detalles al modelo de acuerdo con la estrategia establecida durante el diseo del sistema. El foco de atencin del diseo de objetos son las estructuras de datos y los algoritmos necesarios para implementar cada una de las clases. Por ejemplo, las operaciones de la clase Ventana se especifican en trminos del hardware y del sistema operativo subyacentes. Tcnica de Modelado de Objetos (OMT) 4.- Implementacin: las clases de objetos y las relaciones desarrolladas durante su diseo se traducen finalmente a un lenguaje de programacin concreto, a una base de datos o una implementacin de hardware. La programacin debera ser una parte relativamente pequea del ciclo de desarrollo y fundamentalmente mecnica porque todas las decisiones importantes debern hacerse durante el diseo. Por ejemplo, la clase Ventana se codificar en un lenguaje de programacin utilizando llamadas al sistema de grficos subyacente en la estacin de trabajo. Tres modelos La metodologa OMT emplea tres clases de modelos para describir el sistema: El modelo de objetos que describe los objetos del sistema y sus relaciones El modelo dinmico que describe las interacciones existentes entre objetos del sistema Modelo funcional que describe las transformaciones de datos de sistema. Tres modelos 1.- El modelo de objetos describe la estructura esttica de los objetos del sistema y tambin sus relaciones. El modelo de objetos contiene diagramas de objetos. Un diagrama de objetos es un grafo cuyos nodos son clases de objetos y cuyos arcos son relaciones entre clases

Tres modelos 2.- El modelo dinmico describe los aspectos de un sistema que cambian con el tiempo. El modelo dinmico se utiliza para especificar e implementar los aspectos del control del sistema. Este modelo contiene diagramas de estados, que es un grafo cuyos nodos son estados y cuyos arcos son transacciones entre estados causadas por sucesos o eventos.

3.- el modelo funcional describe las transformaciones de valores de datos que ocurren dentro del sistema. El modelo funcional contiene diagramas de flujo de datos, que representa un clculo. Un diagrama de flujo de datos es un grafo cuyos nodos son procesos y cuyos arcos son flujo de datos

MODELA DE ANALISIS Modelado de anlisis Introduccin La ingeniera de software comienza con una serie de tareas de modelado que conducen a una especificacin de requisitos y a una representacin completa del diseo de software que se construir. El modelo de anlisis, que en realidad es una serie de modelos, es la primera representacin tcnica de un sistema. Tom De Marco describe el proceso de la siguiente manera:

 Los productos del anlisis deben tener una elevada facilidad de mantenimiento. Los problemas de gran tamao deben tratarse con un mtodo efectivo de particin. Deben utilizarse grficas cuando sea posible. Se debe diferenciar entre consideraciones lgicas(esenciales) y fsicas(de implementacin). Como mnimo se necesita: Algo que ayude a hacer una particin de los requisitos y a documentarla antes de la especificacin. Algunos medios para el seguimiento y evaluacin de las interfaces. Herramientas nuevas para describir la lgica y la tctica, algo mejor que un texto narrativo. Qu es? El modelado de anlisis utiliza una combinacin de formatos en texto y diagramas para representar los requisitos de los datos. Las funciones y el comportamiento de una manera relativamente fcil de entender y an ms importante, conduce a una revisin para lograr la correccin, la integridad y la consistencia. Quin los hace? Un ingeniero de software construye el modelo empleando requisitos obtenidos del cliente. Porqu es importante? Para validar los requisitos del software es necesario examinarlos desde algunos puntos de vista diferentes. El modelado de anlisis representa los requisitos en mltiples dimensiones, con lo que se incrementa la probabilidad de encontrar errores, de que surjan inconsistencias y de que se descubran omisiones. Cules son los pasos? Los requisitos de informacin funcionales y de comportamiento se modelan mediante varios tipos de diagramas: Modelado basado en escenarios El modelo orientado a flujos El modelado basado en clases El modelado del comportamiento. Una vez creado los modelos preliminares, estos se refinan y analizan para evaluar su calidad, integridad y consistencia, despus lo validan los interesados. Anlisis de requisitos El anlisis de requisitos genera la especificacin de caractersticas operacionales de software; indica la interfaz de del software con otros elementos del sistema, y establece las restricciones que debe tener el software. Proporciona al diseador de software un representacin de informacin, funcin y comportamiento que puede trasladar a diseos arquitectnicos de interfaz y en el nivel de componentes. Por ltimo, el modelo de anlisis y la especificacin de requisitos ofrecen al desarrollador y al cliente los medios para evaluar la calidad una vez construido el software. Filosofa y objetivos generales EL modelo de anlisis debe cumplir tres objetivos primarios: Describir lo que requiere el cliente. Establecer una base para la creacin de un diseo de software. Definir un conjunto de requisitos que puedan validarse una vez construido el software.

 El modelo de anlisis como un puente entre la descripcin del sistema y el modelo de diseo. Reglas prcticas de anlisis Debe centrarse en los requisitos visibles dentro del problema o dominio de negocio. El grado de abstraccin debe ser alto de forma relativa. Cada elemento del modelo debe agregarse a un acuerdo general de los requisitos de software y proporcionar una visin interna del dominio de informacin, funcin y comportamiento del sistema. Debe retrasarse la consideracin de la infraestructura y otros modelos no funcionales hasta el diseo. Se debe minimizar el acoplamiento de todo el sistema. Se debe tener la seguridad de que el modelo de anlisis porporciona valor a todos los interesados. Al Anlisis del dominio Es la identificacin, el anlisis y la especificacin de requisitos comunes de un dominio especfico de aplicacin para, de manera tpica, reutilizarlo en mltiples proyectos dentro de ese Enfoques de modelado del Anlisis Un modelado de anlisis llamado anlisis estructurado, considera que los datos y el proceso que transforman los datos son entidades separadas. Los objetos de datos se modelan en una forma que define sus atributos y relaciones. Los procesos que manipulan los objetos de los datos se moldean de tal manera que muestran como transforman los datos, mientras los objetos de datos fluyen por el sistema. Un segundo enfoque del modelado del anlisis, llamado anlisis orientado a objetos, se centra en la definicin de clases y en la manera en que estas colaboran entre ellas para efectuar los requisitos del cliente. OBJETIVO_INGENIERIA _DE_SOFTWARE Ingeniera de software 2 1. Introduccin Este trmino fue introducido a finales de los 60 a raz de la crisis del software. Esta crisis fue el resultado de la introduccin de la tercera generacin del hardware. El hardware dej de ser un impedimento para el desarrollo de la informtica; redujo los costos y mejor la calidad y eficiencia en el software producido La crisis se caracteriz por los siguientes problemas: Imprecisin en la planificacin del proyecto y estimacin de los costos. Baja calidad del software. Dificultad de mantenimiento de programas con un diseo poco estructurado, etc. Por otra parte se exigi que el software sea eficz y barato tanto en el desarrollo como en la compra. Tambin se requiri una serie de caractersticas como fiabilidad, facilidad de mantenimiento y de uso, eficiencia, etc. 2. Objetivos de la ingeniera de software

En la construccin y desarrollo de proyectos se aplican mtodos y tcnicas para resolver los problemas, la informtica aporta herramientas y procedimientos sobre los que se apoya la ingeniera de software. Mejorar la calidad de los productos de software Aumentar la productividad y trabajo de los ingenieros del software. Facilitar el control del proceso de desarrollo de software. Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente. Definir una disciplina que garantice la produccin y el mantenimiento de los productos de software desarrollados en el plazo fijado y dentro del costo estimado.

Objetivos de los proyectos de sistemas: Para que los objetivos se cumplan las empresas emprenden proyectos por las siguientes razones: "Las cinco C "

"Las cinco C
1. 2. 3. 4. 5. CAPACIDAD COSTO CONTROL COMUNICACIN COMPETITIVIDAD

1. Capacidad
Las actividades de la organizacin estn influenciadas por la capacidad de sta para procesar transacciones con rapidez y eficiencia. Los sistemas de informacin mejoran esta capacidad en tres formas: 1.- Aumentan la velocidad de procesamiento: Los sistemas basados en computadora pueden ser de ayuda para eliminar la necesidad de clculos tediosos y comparaciones repetitivas. Un sistema automatizado puede ser de gran utilidad si lo que se necesita es un procesamiento acelerado. 2.- Aumento en el volumen: La incapacidad para mantener el ritmo de procesamiento no significa el abandono de los procedimientos existentes. Quiz stos resulten inadecuados para satisfacer las demandas actuales. En estas situaciones el analista de sistemas considera el impacto que tiene la introduccin de procesamiento computarizado, si el sistema existente es manual. Es poco probable que nicamente el aumento de la velocidad sea la respuesta. El tiempo de procesamiento por transaccin aumenta si se considera la cantidad de actividades comerciales de la empresa junto con su patrn de crecimiento. 3.- Recuperacin ms rpida de la informacin: Las organizaciones almacenan grandes cantidades de datos, por eso, debe tenerse en cuenta donde almacenarlos y como recuperarlos cuando se los necesita. Cuando un sistema se desarrolla en forma apropiada, se puede recuperar en forma rpida la informacin.

2. Costo
* Vigilancia de los costos: Para determinar si la compaa evoluciona en la forma esperada, de acuerdo con lo presupuestado, se debe llevar a cabo el seguimiento de los costos de mano de obra, bienes y gastos generales. La creciente competitividad del mercado crea la necesidad de mejores mtodos para seguir los costos y relacionarlos con la productividad individual y organizacional. * Reduccin de costos: Los diseos de sistemas ayudan a disminuir los costos, ya que toman ventaja de las capacidades de clculo automtico y de recuperacin de datos que estn incluidos en procedimientos de programas en computadora. Muchas tareas son realizadas por programas de cmputo, lo cual deja un nmero muy reducido de stas para su ejecucin manual, disminuyendo al personal.

3. Control
*Mayor seguridad de informacin: Algunas veces el hecho de que los datos puedan ser guardados en una forma adecuada para su lectura por medio de una mquina, es una seguridad difcil de alcanzar en un medio ambiente donde no existen computadoras. Para aumentar la seguridad, generalmente se desarrollan sistemas de informacin automatizados. El acceso a la informacin puede estar controlado por un complejo sistemas de contraseas, limitado a ciertas reas o personal, si est bien protegido, es difcil de acceder. *Menor margen de error: (mejora de la exactitud y la consistencia) Esto se puede lograr por medio del uso de procedimientos de control por lotes, tratando de que siempre se siga el mismo procedimiento. Cada paso se lleva a cabo de la misma manera, consistencia y con exactitud: por otra parte se efectan todos los pasos para cada lote de transacciones. A diferencia del ser humano, el sistema no se distrae con llamadas telefnicas, ni olvidos e interrupciones que sufre el ser humano. Si no se omiten etapas, es probable que no se produzcan errores.

4. Comunicacin
La falta de comunicacin es una fuente comn de dificultades que afectan tanto a cliente como a empleados. Sin embargo, los sistemas de informacin bien desarrollados amplan la comunicacin y facilitan la integracin de funciones individuales. * Interconexin: ( aumento en la comunicacin) Muchas empresas aumentan sus vas de comunicacin por medio del desarrollo de redes para este fin, dichas vas abarcan todo el pas y les permiten acelerar el flujo de informacin dentro de sus oficinas y otras instalaciones que no se encuentran en la misma localidad. Una de las caractersticas ms importantes de los sistemas de informacin para oficinas es la transmisin electrnica de informacin, como por ejemplo, los mensajes y los documentos. * Integracin de reas en las empresas: Con frecuencia las actividades de las empresas abarcan varias reas de la organizacin, la informacin que surge en un rea se necesita en otra rea, por ejemplo.

Los sistemas de informacin ayudan a comunicar los detalles del diseo a los diferentes grupos, mantienen las especificaciones esenciales en un sitio de fcil acceso y calculan factores tales como el estrs y el nivel de costos a partir de detalles proporcionados por otros grupos.

5. Competitividad
Los sistemas de informacin computacionales son un arma estratgica, capaz de cambiar la forma en que la compaa compite en el mercado, en consecuencia stos sistemas mejoran la organizacin y la ayudan a ganar "ventaja competitiva", sin embargo, si los competidores de la compaa tienen capacidades mas avanzadas para el procesamiento de informacin, entonces los sistemas de informacin pueden convertirse en una "desventaja competitiva". Una organizacin puede ganar ventaja competitiva a travs de sus sistemas de informacin de diferentes formas. * Asegurar clientes: Como los clientes son los ms importante para una organizacin, los directivos buscan diferentes formas para conseguir nuevos clientes y mantener los que tienen. Para eso las empresas proporcionan: 1- Mejores precios 2- Servicios exclusivos. 3- Productos diferentes.

Competitividad
La ventaja en precios se observa continuamente en la actividad comercial (s el producto es exclusivo o distinto entonces tener el liderazgo en precios bajos quizs no sea el objetivo a alcanzar). La estrategia eficaz de precios a menudo se alcanza al desarrollar sistemas de informacin por razones tales como reduccin de costos y ganancia en la exactitud. Generalmente cuando una compaa puede ofrecer servicios exclusivos y atraer clientes, es posible que los competidores no sean capaces de atraer a los clientes de la compaa. * Dejar fuera a los competidores: Pasar sobre los competidores puede ser un inconveniente si ellos se encuentran la forma para duplicar los logros de la compaa, los sistemas de informacin pueden ser la base para dejar fuera del mercado a la competencia ya sea el disuadir sus intentos por ingresar al mercado o crendoles obstculo para su entrada.

*Mejores acuerdos con los proveedores: En los negocios, los proveedores tambin tienen importancia estratgica. Una manera de utilizar los sistemas de informacin para favorecer arreglos con los proveedores es ofreciendo un mejor precio. Disminuyendo los costos. Formar bases para nuevos productos. Los sistemas de informacin tambin forman la base de muchos productos y servicios nuevos. Los servicios de base de datos experimentan un crecimiento comn en todas las industrias.

Productos que van desde programas personales hasta planes de construccin pueden hacerse a la medida del cliente gracias al procesamiento de informacin. Una cosa es clara, es necesario que los sistemas entren en operacin y que trabajen de manera confiable.

4. Estrategias para su desarrollo Los sistemas de informacin basados en computadoras sirven para diversas finalidades que van desde el procesamiento de las transacciones de una empresa hasta proveer de la informacin necesaria para decidir sobre asuntos que se presentan con frecuencia. En algunos casos los factores que deben considerarse en un proyecto de sistemas de informacin, como el aspecto ms apropiado de la computadora o la tecnologa de comunicaciones que se va a utilizar; el impacto del nuevo sistema sobre los empleados de la empresa y las caractersticas especficas que el sistema debe tener se pueden determinar de manera secuencial. Todas estas situaciones estn determinadas por tres mtodos bsicos:

5. Mtodo del ciclo de vida clsico

El mtodo del ciclo de vida para desarrollo de sistemas es el conjunto de actividades que los analistas, diseadores y usuarios realizan para desarrollar e implantar un sistema de informacin. El mtodo del ciclo de vida para el desarrollo de sistemas consta de las siguientes actividades: 1) Investigacin preliminar La solicitud para recibir ayuda de un sistema de informacin pueden originarse por una persona, cuando se formula la solicitud comienza la primera actividad del sistema. Esta actividad tiene tres partes:

1.1 ) Aclaracin de la solicitud Antes de considerar cualquier investigacin de sistemas, la solicitud de proyecto debe examinarse para determinar con precisin lo que el solicitante desea; ya que muchas solicitudes que provienen de empleados y usuarios no estn formuladas de manera clara.

Mtodo del ciclo de vida clsico

1.2) Estudio de factibilidad En la investigacin preliminar un punto importante es determinar que el sistema solicitado sea factible. Existen tres aspectos relacionados con el estudio de factibilidad, que son realizados generalmente por analistas capacitados o directivos: Factibilidad tcnica.

Estudia si el trabajo para el proyecto, puede desarrollarse con el software y el personal existente, y si en caso de necesitar nueva tecnologa, cuales son las posibilidades de desarrollarla (no solo el hardware). Factibilidad econmica.

Investiga si los costos se justifican con los beneficios que se obtienen, y si se ha invertido demasiado, como para no crear el sistema si se cree necesario.

Mtodo del ciclo de vida clsico

Factibilidad operacional:

Investiga si ser utilizado el sistema, si los usuarios usarn el sistema, como para obtener beneficios. 1.3) Aprobacin de la solicitud

Algunas organizaciones reciben tantas solicitudes de sus empleados que slo es posible atender unas cuantas. Sin embargo, aquellos proyectos que son deseables y factibles deben incorporarse en los planes. En algunos casos el desarrollo puede comenzar inmediatamente, aunque lo comn es que los miembros del equipo de sistemas estn ocupados en otros proyectos. Cuando esto ocurre, la administracin decide que proyectos son los ms importantes y el orden en que se llevarn acabo. Despus de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario para terminarlo y las necesidades de personal 2) Determinacin de los requisitos del sistema. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a ciertas preguntas claves. Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles relacionados con los procesos de la empresa. Cuando no es posible entrevistar, en forma personal a los miembros de grupos grandes dentro de la organizacin, se emplean cuestionarios para obtener esta informacin. Las investigaciones detalladas requieren el estudio de manuales y reportes, la observacin en condiciones reales de las actividades del trabajo y, en algunas ocasiones, muestras de formas y documentos con el fin de comprender el proceso en su totalidad. Reunidos los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar las caractersticas que debe tener el nuevo sistema. 3)Diseo del sistema.(diseo lgico) El diseo de un sistema de informacin responde a la forma en la que el sistema cumplir con los requerimientos identificados durante la fase de anlisis. Es comn que los diseadores hagan un esquema del formato o pantalla que esperan que aparezca cuando el sistema esta terminado, se realiza en papel o en la pantalla de una terminal utilizando algunas de las herramientas automatizadas disponibles para el desarrollo de sistemas. Tambin se indican los datos de entrada, los que sern calculados y los que deben ser almacenados. Los diseadores seleccionan las estructuras de archivo y los dispositivos de almacenamiento. Los procedimientos que se escriben indican cmo procesar los datos y producir salidas. Los documentos que contienen las especificaciones de diseo representan a ste mediante diagramas, tablas y smbolos especiales. La informacin detallada del diseo se proporciona al equipo de programacin para comenzar la fase de desarrollo de software. Los diseadores son responsables de dar a los programadores las especificaciones de software completas y claramente delineadas. 4) Desarrollo de software (diseo fsico). Los encargados de desarrollar software pueden instalar software comprado a terceros o escribir programas diseados a la medida del solicitante. La eleccin depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores.

Los programadores son responsables de la documentacin de los programas y de explicar su codificacin, esta documentacin es esencial para probar el programa y hacer el mantenimiento. 5) Prueba de sistemas. Durante esta fase, el sistema se emplea de manera experimental para asegurarse que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan como entradas conjuntos de datos de prueba para su procesamiento y despus se examinan los resultados. En ocasiones se permite que varios usuarios utilicen el sistema, para que los analistas observen si tratan de emplearlo en formas no previstas, antes de que la organizacin implante el sistema y dependa de l. En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo que escribi los programas originales; para asegurarse de que las pruebas sean completas e imparciales y, por otra, que el software sea ms confiable. 6) Implantacin y evaluacin.

La implantacin es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicacin y construir todos los archivos de datos necesarios para utilizarla. Cada estrategia de implantacin tiene sus mritos de acuerdo con la situacin que se considere dentro de la empresa. Sin importar cul sea la estrategia utilizada, los encargados de desarrollar el sistema procuran que el uso inicial del sistema se encuentre libre de problemas. Los sistemas de informacin deben mantenerse siempre al da, la implantacin es un proceso de constante evolucin. La evaluacin de un sistema se lleva a cabo para identificar puntos dbiles y fuertes. La evaluacin ocurre a lo largo de cualquiera de las siguientes dimensiones: Dimensiones:

Evaluacin operacional Valoracin de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de informacin, confiabilidad global y nivel de utilizacin. Impacto organizacional Identificacin y medicin de los beneficios para la organizacin en reas como finanzas (costos, ingresos y ganancias), eficiencia operacional e impacto competitivo. Opinin de los administradores Evaluacin de las actitudes de directivos y administradores dentro de la organizacin as como de los usuarios finales. Dimensiones:

Desempeo del desarrollo La evaluacin del proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estndares, y otros criterios de administracin de proyectos. Cuando la evaluacin de sistema se conduce en forma adecuada proporciona mucha informacin que puede ayudar a mejorar la efectividad de los esfuerzos cuando la evaluacin de sistemas se conduce en forma adecuada proporciona

mucha informacin que puede ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones subsecuentes. 6. Mtodo de desarrollo por anlisis estructurado Muchos especialistas en sistemas de informacin reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. El mtodo de desarrollo del anlisis estructurado tiene como finalidad superar esta dificultad por medio de: la divisin del sistema en componentes y la construccin de un modelo del sistema. El mtodo incorpora elementos tanto de anlisis como de diseo El anlisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicacin. Permite que las personas observen los elementos lgicos (lo que har el sistema) separados de los componentes fsicos (computadora, terminales, sistemas de almacenamiento, etc.). Despus de esto se puede desarrollar un diseo fsico eficiente para la situacin donde ser utilizado. El anlisis estructurado es un mtodo para el anlisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. ste anlisis permite al analista conocer un sistema o proceso en una forma lgica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle pertinente. Componentes Smbolos grficos: Iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes. Diccionario de datos: descripcin de todos los datos usados en el sistema. Puede ser manual o automatizado. Descripciones de procesos y procedimientos: declaraciones formales que usan tcnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema. Reglas: estndares para describir y documentar el sistema en forma correcta y completa.

Diseo Estructurado.
El diseo Estructurado es otro elemento del Mtodo de Desarrollo por Anlisis Estructurado que emplea la descripcin grfica, se enfoca en el desarrollo de especificaciones del software. El objetivo del Diseo Estructurado es programas formados por mdulos independientes unos de otros desde el punto de vista funcional. El Diseo Estructurado es una tcnica especfica para el diseo de programas. La herramienta fundamental del Diseo Estructurado es el diagrama estructurado que es de naturaleza grfica y evitan cualquier referencia relacionada con el hardware o detalles fsicos. Su finalidad no es mostrar la lgica de los programas (que es la tarea de los diagramas de flujo). Los Diagramas Estructurados describen la interaccin entre mdulos independientes junto con los datos que un mdulo pasa a otro cuando interacciona con l.

Ingeniera de Software II
Introduccin Qu es? Es el producto que los ingenieros de software construyen y despus mantienen en el largo plazo. Incluye los programas que se ejecutan dentro de la computadora de cualquier tamao y arquitectura. Quin lo hace? Los ingenieros de software los construyen y los mantienen, y casi todos en el mundo industrializado lo usan de manera directa o indirecta. En la sociedad moderna el papel de la ingeniera es proporcionar si stemas y productos que mejoren los aspectos materiales de la vida humana, para que as la vida sea ms fcil, segura y placentera. Richard Fairly y Mary Willshire

Introduccin
Porqu es importante? Porque afecta de forma muy cercana todos los aspectos de nuestras vidas y se ha vuelto indispensable en el comercio, la cultura y las actividades cotidianas. Cules son los pasos? Mediante la aplicacin de un proceso que conduzca a un resultado de lata calidad que satisfaga las necesidades de la gente que usar el producto. Cul es el producto obtenido? El producto obtenido lo forman los programas, el contenido (datos) y los documento que constituyen el software. Pero desde le punto de vista del usuario, el producto es la informacin resultante.

Evolucin del software

En la actualidad, el software tiene un papel dual. Es a la vez, un producto y un vehculo mediante el cual se entrega un producto. El software entrega el producto ms importante de nuestro tiempo: Informacin. El papel del software de computadora ha experimentado un cambio significativo en un perodo un poco mayor a 50 aos. Las mejoras sustanciales en el desempeo del hardware, los cambios profundos en las arquitecturas de cmputo, los enormes incrementos en las capacidades de memoria y almacenamiento, y la amplia variedad de opciones de entrada y salida ha propiciado el surgimiento de sistemas ms elaborados y complejos basados en computadoras. En la actualidad una enorme industria del software se ha convertido en un factor dominante en la economa del mundo industrializado. El programador solitario de la era inicial ha sido sustituido por equipos de especialistas en software, en los que cada uno se enfoca en una parte de la tecnologa requerida para desarrollar una aplicacin compleja. Hasta ahora, las preguntas formuladas al programador solitario son las mismas que se hacen cuando se construyen los sistemas basados en computadoras modernas: Porqu tarda tanto la obtencin del software terminado?

Porqu son tan altos los costos de desarrollo del software? Porqu es imposible encontrar todos los errores en el software antes de entregarlo a los clientes? Porqu se gastan tanto tiempo y esfuerzo en el mantenimiento de los programas existentes? Porqu es difcil medir el progreso al desarrollar y darle mantenimiento al software? Estas y muchas otras muchas preguntas demuestran la preocupacin de la industria por el software y por la manera en que sta se desarrolla, una preocupacin que ha conducido a la adopcin de la prctica de la ingeniera de software.

Software
Para entender el software (y la ingeniera del software), es importante examinar las caractersticas que lo hacen diferente de otras cosas que se construyen. El software es un elemento lgico, en lugar de fsico, de un sistema. Por lo tanto el software tiene caractersticas muy diferentes a las del hardware: El software se desarrolla o construye, no se manufactura en el sentido clsico.

1.

A pesar de la similitud entre el desarrollo y la manufactura, las dos actividades son diferentes en lo fundamental. En ambas, la calidad se alcanza por medio del buen diseo, pero la fase de manufactura del hardware puede incluir problemas de calidad inexistentes en el software. Ambas actividades requieren la construccin de un producto , pero los enfoques son diferentes. Los costos del software se concentran en la ingeniera. Esto significa que los proyectos de software no se pueden manejar como si fueran proyectos de manufactura. 2. El software no se desgasta

En la fig.1 se muestra, para el hardware, la tasa de fallas como una funcin del tiempo. La relacin a menudo llamada curva de la baera. Curva de fallas para el hardware

La curva de la baera indica que el hardware tiene un numero considerablemente alto de fallas al inicio de su vida (a menudo stas se atribuyen a defectos de diseo o manufactura). Despus, los defectos se corrigen y la tasa de fallas baja hasta un nivel estable (se desea que ste sea muy bajo) por algn perodo. Sin embargo conforme pasa el tiempo, la tasa de fallas se eleva de nuevo conforme los componentes del hardware sufren los efectos acumulativos del polvo, la vibracin, el abuso, las temperaturas extremas y muchos otros males ambientales. Expresado en forma ms simple, el hardware comienza a desgastarse. El software es inmune a los males ambientales que desgastan el hardware. Por lo tanto, la curva de la tasa de fallas para el software debera tener la forma de la "curva idealizada" que se muestra en la figura 2. Los defectos sin descubrir causan tasas de falla altas en las primeras etapas de vida de un programa. Sin

embargo, los errores se corrigen (en el mejor de los casos sin agregar otros errores) y la curva se aplana como se muestra en la figura 2. La curva idealizada es una simplificacin burda del modelo de fallas real para el software. Sin embargo la implicacin es clara: el software no se desgasta, pero s se deteriora

Curvas de falla para software

3. A pesar de que la industria tiene una tendencia hacia la construccin por componentes, la mayora del software an se construye a la medida.

Considrese la forma en que se disea y construye un hardware de control para un producto de cmputo. El ingeniero de diseo dibuja un esquema simple del sistema de circuitos digital, realiza algunos anlisis fundamentales para asegurarse de que el diseo realizar las funciones apropiadas y despus busca en los catlogos de componentes digitales cada circuito integrado de acuerdo con un nmero de parte, una funcin definida y validada, una interfaz bien definida y un conjunto estandarizado de directrices de integracin. Una vez seleccionado cada componente, puede solicitrsele para despus ensamblarlo. Cuando una disciplina de ingeniera evoluciona se crea una coleccin de diseos estndar de componentes. Un componente de software se debe disear e implementar de forma que pueda utilizarse en muchos programas diferentes. Los componentes reutilizables modernos encapsulan tanto los datos como el proceso que se aplica a stos, lo que permite al ingeniero de software crear aplicaciones nuevas a partir de partes reutilizables. Por ejemplo, las interfaces actuales con el usuario se construyen con componentes reutilizables que permiten la creacin de ventanas grficas, mens desplegables y una amplia variedad de mecanismos de interaccin. Las estructuras de datos y los detalles de procesamiento requeridos para construir la interfaz estn contenidos en una librera de componentes reutilizables para la construccin de la interfaz.

LA NATURALEZA CAMBIANTE DEL SOFTWARE En la actualidad existen siete grandes categoras del software de computadora que presentan retos continuos para los ingenieros de software. 1. 2. 3. 4. 5. 6. 7. Software de sistemas. Software de aplicacin. Software cientfico y de ingeniera. Software empotrado. Software de lnea de productos. Aplicaciones basadas en Web. Software de inteligencia artificial. 1. Software de sistemas. El software de sistemas es una coleccin de programas escritos para servir a otros programas. Algunos programas de sistemas (como los compiladores, editores y utileras para la administracin de archivos) procesan estructuras de informacin complejas pero determinadas. Otras aplicaciones de sistemas (por ejemplo, componentes del sistema operativo, controladores, software de red, procesadores para telecomunicaciones) procesan datos indeterminados. En cada caso, el rea de software de sistemas se caracteriza por una interaccin muy intensa con el hardware de la computadora; utilizacin por mltiples usuarios; operacin concurrente que requiere la gestin de itinerarios, de comparticin de recursos, y de procesos sofisticados; estructuras de datos complejas y mltiples interfaces externas.

2. Software de aplicacin.
Consiste en programas independientes que resuelven una necesidad de negocios especfica. Las aplicaciones en esta rea procesan datos empresariales o tcnicos de forma que facilitan las operaciones de negocios o la toma de decisiones tcnicas o de gestin. Adems del procesamiento de datos convencional, el software de aplicacin se utiliza para controlar las funciones de negocios en tiempo real (por ejemplo, el procesamiento de transacciones en los puntos de venta y el control de procesos de manufactura en tiempo real.)

3. Software cientfico y de ingeniera.

El software cientfico y de ingeniera, que se caracterizaba por algoritmos "devoradores de nmeros, abarca desde la astronoma hasta la vulcanologa, desde el anlisis de la tensin automotriz hasta la dinmica orbital de los transbordadores espaciales, y desde la biologa molecular hasta la manufactura automatizada. Sin embargo, las aplicaciones modernas dentro del rea cientfica y de ingeniera se alejan en la actualidad de los algoritmos numricos convencionales. El diseo asistido por computadora, la simulacin de sistemas y otras aplicaciones interactivas han comenzado a tomar caractersticas de software en tiempo real e incluso de software de sistemas. 4. Software empotrado. El software empotrado reside dentro de la memoria de slo lectura del sistema y con l se implementan y controlan caractersticas y funciones para el usuario final y el sistema mismo. El software incrustado puede desempear funciones limitadas y curiosas (como el control del teclado de un horno de microondas) o proporcionar capacidades de control y funcionamiento significativas (por ejemplo, las funciones digitales de un automvil, como el control de combustible, el despliegue de datos en el tablero, los sistemas de frenado, los celulares, etctera). 5. Software de lnea de productos. El software de lnea de productos, diseados para proporcionar una capacidad especfica y la utilizacin de muchos clientes diferentes, se puede enfocar en un nicho de mercado limitado (como en los productos para el control de inventarios) o dirigirse hacia los mercados masivos (por ejemplo, aplicaciones de procesadores de palabras, hojas de clculo, grficas por computadora, multimedia, entretenimiento, manejo de bases de datos, administracin de personal y finanzas en los negocios). 6. Aplicaciones basadas en Web. Las "WebApps" engloban un espectro amplio de aplicaciones. En su forma ms simple, las WebApps son apenas un poco ms que un conjunto de archivos de hipertexto ligados que presenta informacin mediante texto y algunas grficas. Sin embargo, a medida que el comercio electrnico y las aplicaciones B2B adquieren mayor importancia, las WebApps evolucionan hacia ambientes computacionales sofisticados que no slo proporcionan caractersticas, funcionales de cmputo y contenidos independientes al usuario final, sino que estn integradas con bases de datos corporativas y aplicaciones de negocios. 7. Software de inteligencia artificial. Este software utiliza algoritmos no numricos en la resolucin de problemas complejos que es imposible abordar por medio de un anlisis directo. Las aplicaciones dentro de esta rea incluyen la robtica, los sistemas expertos, el reconocimiento de patrones (imagen y voz), las redes neuronales artificiales, la comprobacin de teoremas y los juegos en computadora.

Ingeniera de software ii
CONDUCCIN DEL DISEO AL NIVEL DE COMPONENTES
El diseador debe transformar la informacin del anlisis y los modelos arquitectnicos en una representacin de diseo que proporcione suficiente detalle para guiar la actividad de construccin (codificacin y prueba).Los siguientes pasos representan un conjunto de tareas tpicas para el diseo al nivel de componentes, cuando se aplica un sistema orientado a objetos. PASO 1. Identificar todas las clases de diseo que corresponden al dominio del problema

Usando los modelos de anlisis y arquitectnicos, cada anlisis y componente arquitectnico est elaborado como se describi anteriormente. PASO 2. Identificar todas las clases de diseo que corresponden al dominio de la infraestructura Como ya se ha indicado, entre las clases y los componentes de esta categora se incluyen componentes de interfaz grfica de usuario, del sistema operativo, de administracin de objetos y datos, y otros. PASO 3. elaborar todas las clases de diseo que no se adquieran como componentes reutilizables. La elaboracin requiere que se describan de manera detallada todas las interfaces, los atributos y las operaciones necesarios para implementar la clase. Al realizar esta tarea debe tomarse en cuenta el diseo de la heurstica (por ejemplo, la cohesin y el acoplamiento de componentes). PASO 3a. Especificar los detalles del mensaje cuando las clases o los componentes colaboran. El modelo del anlisis emplea el diagrama de colaboracin para mostrar la manera en que las clases de anlisis colaboran entre si. A medida que avanza el diseo al nivel de componentes, a veces es til mostrar los detalles de estas colaboraciones al especificar la estructura de mensajes que se pasan entre los objetos de un sistema.

PASO 3b. Identificar las interfaces apropiadas para componentes. En el contexto del diseo al nivel de componentes, una interfaz UML es un grupo de operaciones externamente visible (es decir, pblicas). La interface no contiene estructura interna; no tiene atributos ni a sociaciones En esencia, las operaciones definidas para la clase de diseo estn ordenadas en una o ms clases abstractas. Cada operacin dentro de la clase abstracta (la interfaz) debe tener cohesin; es decir, debe mostrar procesamiento que se concentra en una funcin o subfuncin limitada.

 PASO 3c. Elaborar atributos y definir los tipos y las estructuras de datos necesarios para implementarlos. Las estructuras y los tipos de datos con que se describen atributos se definen dentro del contexto del lenguaje de programacin que habr de usarse para la implementacin. UML define el tipo de datos de un atributo empleando la siguiente sintaxis: nombre : tipo-expresin = valor-inicial {propiedad cadena} Si un atributo aparece varias veces en varias clases de diseo, y tiene una estructura relativamente compleja, es mejor crear una clase separada para acomodar el atributo. PASO 3d. Describir de manera detallada el flujo de procesamiento dentro de cada operacin. Esto se logra empleando un seudocdigo basado en un lenguaje de programacin o el diagrama de actividad UML. Cada componente de software se elabora mediante varias interacciones que aplican el concepto de refinamiento paso a paso. La primera iteracin define cada operacin como parte de la clase de diseo. En cada caso, la operacin debe estar caracterizada de manera que asegure una cohesin elevada, es decir, la operacin debe realizar una sola funcin o sustitucin definida. La siguiente iteracin hace poco ms que expandir el nombre de la operacin PASO 4. describe fuentes de datos persistentes (base de datos y archivos) e identificar las clases necesarias para manejarlas. Las bases de datos y los archivos suelen trascender la descripcin de el diseo de un componente individual. En casi todos los casos estos almacenes de datos persistentes suelen especificarse inicialmente como parte del diseo arquitectnico. Sin embargo, a medida que avanza la elaboracin del diseo, a veces resulta til proporcionar detalles adicionales de la estructura y organizacin de estas fuentes de datos persistentes. PASO 5. desarrollar y elaborar representaciones del comportamiento de una clase o un componente. Los diagramas de estado UML se usaron como parte del modelo de anlisis para representar el comportamiento del sistema que se observa externamente y el comportamiento ms localizado de clases individuales de anlisis. Durante el diseo al nivel de componentes, suele ser necesario modelar el comportamiento de una clase de diseo.

Al comportamiento dinmico de un objeto (la instanciacin de una clase de diseo mientras se ejecuta el programa) lo afectan eventos externos y el estado actual del objeto (modo o comportamiento). Para comprender el comportamiento dinmico de un objeto, el diseador debe examinar todos los casos de uso relevantes durante el periodo de vida de la clase de diseo. Estos casos de uso proporcionan informacin que ayuda al diseador a delinear los eventos que afectan al objeto y a los estados en que reside ste mientras pasa el tiempo y ocurren los eventos. La transicin entre estados se representan empleando una grfica de estado UML.

PASO 6. elaborar diagramas de despliegue para proporcionar detalles de la implementacin adicional. Los diagramas de despliegue se usaron como parte del diseo arquitectnico y se representan en forma de descriptor. As, se representan las principales funciones del sistema dentro del contexto del entorno de cmputo que las albergar. Durante el diseo al nivel de componentes pueden elaborarse diagramas de despliegue para representar la ubicacin de paquetes clave de componentes. Sin embargo, por lo general los componentes se representan individualmente dentro de un diagrama de componentes. La razn de esto es evitar la complejidad del diagrama. En algunos casos, los diagramas de despliegue se elaboran en forma de instancias. Esto significa que el hardware especfico y el o los entornos del sistema operativo que se usarn son especficos y que se indica la ubicacin de los paquetes de componentes dentro de este entorno. PASO 7. factorizar todas las representaciones del diseo al nivel de componentes y siempre deben considerarse alternativas. A lo largo del libro se ha destacado que el diseo es un proceso iterativo. El primer modelo al nivel de componentes que se cree no ser tan completo, consistente o exacto como la ensima iteracin que aplique al modelo. Es esencial usar la refactorizacin mientras se realiza el trabajo. Adems, un diseador no debe tener una visin estrecha. Siempre hay soluciones opcionales para el diseo, y los mejores diseadores toman en cuenta todas (o casi todas) antes de definir el modelo de diseo final. Desarrollan opciones y examinan cada un de manera cuidadosa, empleando los principios del diseo y los conceptos.

Ingeniera de software II Captulo 3 Diseo de la Interfaz de usuario Ingeniera de Software II

Contenido Diseo de la interfaz de usuario. Las reglas doradas. Anlisis y diseo de la interfaz de usuario. Anlisis de la interfaz. Etapas del diseo. Diseo de la interfaz de usuario

Qu es? Crea un modelo eficaz de comunicacin entre los seres humanos y la computadora. Siguiendo un conjunto de principios de diseo de la interfaz, el diseo identifica los objetos y acciones de sta y luego crea una plantilla de pantalla que constituye la base del prototipo de la interfaz de usuario. Diseo de la interfaz de usuario Quin lo hace? Un ingeniero de software disea la interfaz de usuario con la aplicacin de un proceso iterativo que sigue principios de diseo predefinido. Por qu es importante? Si el software es difcil de usar fuerza al usuario a cometer errores, o si frustra el esfuerzo para alcanzar las metas, entonces no le gustar, sin que importe el poder computacional que tenga. Para que un producto de software tenga xito, debe tener buena usabilidad: medicin cualitativa de la facilidad y eficiencia con la que un humano emplea las funciones y caractersticas que ofrece el producto de alta tecnologa. Los tecnlogos estudiaban la interaccin humana, surgieron dos aspectos dominantes: Identificacin de reglas doradas. Mecanismos de interaccin: llamados GUI (interfaz grfica de usuario) implementar en forma correcta las reglas doradas.

Dejar el control al usuario Definir modos de interaccin de manera que no se obligue al usuario a realizar acciones innecesarias o no deseadas. Dar una interaccin flexible. Permitir que la interaccin del usuario sea interrumpible y tambin reversible. Facilitar la interaccin a medida que aumenta la habilidad y permitir que aquella se personalice. Ocultar los tecnicismos internos al usuario ocasional. Disear la interaccin directa con objetos que aparezcan en la pantalla.

Reducir la necesidad de que el usuario memorice Reducir la demanda de memoria de corto plazo. Hacer que lo preestablecido sea significativo. Definir atajos que sean intuitivos. La distribucin visual de la interfaz debe basarse en una metfora del mundo real. Revelar informacin de manera progresiva.

Anlisis y diseo de la interfaz de usuario Cuando se analiza y disea la interfaz de usuario, entran en juego cuatro diferentes modelos: Un ingeniero (o el encargado del software) establece un modelo de usuario. Un ingeniero de software crea un modelo de diseo. El usuario final desarrolla una imagen mental que frecuentemente se nombra modelo de mental o percepcin del sistema. Los implementadores del sistema crean un modelo de implementacin. El papel del diseador de la interfaz es conciliar estas diferencias y obtener una representacin consistente de la interfaz.

Anlisis y modelos del diseo de la interfaz

Jeff Patton afirma lo siguiente: "La verdad es que los diseadores y desarrolladores piensan con frecuencia en los usuarios finales. Sin embargo, en ausencia de un modelo mental fuerte de usuarios especficos, los sustituimos con nosotros. Esto no es centrarse en el usuario, sino en uno mismo ". Para construir una interfaz de usuario eficaz, "todo diseo debe comenzar con la comprensin de los usuarios que se busca, lo que incluye los perfiles de edad, gnero, condiciones fsicas, educacin, antecedentes culturales o tnicos, motivacin, metas y personalidad ".

Anlisis y modelos del diseo de la interfaz El modelo mental del usuario (percepcin del sistema) es la imagen del sistema que los usuarios finales llevan en la cabeza. El modelo de implementacin combina la manifestacin externa del sistema basado en computadora (la vista y sensacin de la interfaz). Cuando ambos modelos coinciden, quienes utilizan el software por lo general se sienten cmodos con este y lo usan de manera eficaz. La clave del principio mas importante del diseo de la interfaz de usuario: " Conocer al usuario, conocer las tareas".

El proceso del anlisis y diseo de la interfaz Anlisis de la interfaz: Se centra en el perfil de los usuarios que interactan con el sistema. Se registra el nivel de habilidad, la comprensin del negocio y la receptividad general hacia el nuevo sistema, tambin se definen las diferentes categoras de usuarios. Diseo de la interfaz: es definir un conjunto de objetos y acciones de sta que permiten al usuario efectuar todas las tareas definidas en forma tal que cumpla cada meta de usabilidad definida para el sistema. Construccin de la interfaz: comienza por lo general con la creacin de un prototipo que permite evaluar los escenarios de uso. A medida que avanza el proceso de diseo, se emplea un grupo de herramientas de la interfaz de usuario para terminar de construirla. Validacin de la interfaz: La capacidad de la interfaz para implementar correctamente todas las tareas del usuario. El grado en que la interfaz es fcil de usar y de aprender. La aceptacin que tiene por parte del usuario como herramienta til en su trabajo. Anlisis de la interfaz Anlisis del usuario Anlisis y modelado de la tarea Anlisis del contenido de la pantalla Anlisis del ambiente de trabajo

Anlisis del usuario La nica manera en la que se logra hacer converger la imagen mental y el modelo de diseo es trabajando para entender a los usuarios y la forma en la que usarn el sistema. Para ello, se utiliza informacin procedente de una variedad amplia de fuentes: Entrevistas. Informacin de ventas. Informacin de mercadotecnia. Informacin de apoyo. Anlisis del usuario Los usuarios son profesionales capacitados, tcnicos, oficinistas o trabajadores de manufactura? Qu nivel educacin formal tiene el usuario promedio? Los usuarios son capaces de aprender mediante materiales escritos o han manifestado el deseo de recibir enseanza en el aula? Los usuarios son mecangrafos expertos o tienen fobia a los teclados? Cul es el rango de edades de la comunidad de usuarios? Los usuarios estarn representados sobre todo por un gnero? Cmo se compensa a los usuarios por el trabajo que realizan? Los usuarios trabajan en un horario normal de oficina o hasta terminar el trabajo que hacen? El software va a ser parte integral del trabajo de los usuarios o solo lo emplearn de manera ocasional?

Cul es el idioma principal de los usuarios?

Anlisis del contenido de la pantalla Para las aplicaciones modernas, el contenido de pantalla vara de reportes basados en caracteres o informacin especializa. Los objetos de datos de salida producidos por una aplicacin pueden ser: Generados por componentes en otras partes de la aplicacin. Adquiridos a partir de datos almacenados en una base accesible desde la aplicacin. Transmitidos desde sistemas externos a la aplicacin en cuestin. Durante esta etapa del anlisis de la interfaz, se toma en cuenta el formato y la esttica del contenido.

Las personas no realizan aisladas su trabajo. Estn influidas por la actividad que las rodea, las caractersticas fsicas del sitio de trabajo, el tipo de equipo que usan y las relaciones laborales que tienen con las dems personas. Si los productos que usted disea no se ajustan al ambiente, su uso ser difcil y frustrante. En ciertas aplicaciones se coloca la interfaz de usuario de un sistema en una ubicacin amigable (con iluminacin adecuada, buena altura de la pantalla, acceso fcil al teclado, etc.), pero en otras (como en una fbrica o en la cabina de un avin) la iluminacin es menos que buena, el ruido es notable, entre otros.

Diseo de Sistemas Diseo en el contexto de la ingeniera de software Diseo de sistemas Qu es? Ingeniera de software II

 Es el lugar en el que las reglas de la creatividad los requerimientos de los participantes, las necesidades del negocio y las consideraciones tcnicas se unen para formular un producto o sistema. El diseo crea una representacin del modelo del software, proporciona detalles sobre arquitectura del software, estructura de datos, interfaces y componentes que se necesitan para implementar el sistema. Quin lo hace? Ingenieros de software. Por qu es importante? Permite modelar el sistema o producto que se va a construir. Este modelo se evala respecto a la calidad y su mejora antes de generar cdigo; despus se efectan pruebas y se involucra a muchos usuarios finales. El diseo es el lugar en el que se establece la calidad del software. El diseo de software agrupa el conjunto de principios, conceptos y prcticas que llevan al desarrollo de un sistema o producto de alta calidad. El diseo es crucial para el xito de la ingeniera de software. Qu es el diseo? Es donde se est con un pie en dos mundos el de la tecnologa y el de las personas y los propsitos humanos que tratan de unificarse Mitch Kapor, 1990 (Creador de Lotus 1-2-3) Diseo en el contexto de la ingeniera de software
Los edificios bien diseados eran aquellos que tenan resistencia, funcionalidad y belleza. Lo mismo se aplica al buen software. Resistencia: un programa no debe tener ningn error que impida su funcionamiento. Funcionalidad: un programa debe ser apropiado para los fines que persigue. Belleza: la experiencia de usar un programa debe ser placentera. stos son los comienzos de una teora de diseo de software Vitruvio, romano crtico de arquitectura. Diseo en el contexto de la ingeniera de software El diseo de software comienza una vez que se han analizado y modelado los requerimientos. Cada uno de los elementos del modelo de requerimientos proporciona informacin necesaria para crear los cuatro modelos del diseo necesarios para la especificacin completa del diseo. La importancia del diseo del software se resume en una palabra: calidad. Es la nica manera de traducir con exactitud a un producto o sistema terminado los requerimientos de los participantes. Elementos del modelo de requerimientos

Investigacin MODELADO DEL ANLISIS. Elementos basados en el escenario. Elementos basados en clases Elementos orientados al flujo. Elementos del comportamiento. Resumen Libro: Pressman Roger, Ingeniera del software: Un enfoque prctico. Sptima edicin. (6- Dic) Transformacin del modelo de requerimientos al modelo de diseo

El proceso del diseo Lineamientos y atributos de la calidad del software

Debe implementar todos los requerimientos explcitos contenidos en el modelo de requerimientos y dar cabida a todos los requerimientos implcitos que desean los participantes Debe ser una gua legible y comprensible para quienes generan el cdigo y para los que lo prueban y dan a poyo posterior Lineamientos y atributos de la calidad del software Lineamientos de la calidad

Debe tener estilos arquitectnicos reconocibles. Debe ser modular. Debe contener distintas representaciones de datos, arquitectura, interfaces y componentes. Debe conducir a estructuras de datos apropiadas. Debe llevar a componentes que tengan caractersticas funcionales independientes. Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los componentes y el ambiente externo. Debe obtenerse mediante el empleo de un mtodo repetible motivado durante la informacin obtenida durante el anlisis. Debe representarse con una notacin que comunique con eficiencia su significado. Atributos de la calidad Funcionalidad: conjunto de caractersticas y capacidades del programa, funciones que se entregan y la seguridad general del sistema. Usabilidad: tomando en cuenta los factores humanos, esttica general, consistencia y documentacin. Confiabilidad: medicin de la frecuencia y gravedad de los errores, la exactitud de los resultados, tiempo en que ocurren los errores. Rendimiento: velocidad del procesamiento, tiempo de respuesta, uso de recursos, la eficiencia. Mantenabilidad: capacidad del programa para ser ampliable, adaptable y servicial, adems que pueda probarse, ser compatible y configurable.

La evolucin del diseo de software Los primeros trabajos de diseo se concentraban en criterios para el desarrollo de programas modulares. Los aspectos de procedimiento del diseo evolucionaron hacia una filosofa llamada programacin estructurada. Los enfoques mas nuevos propusieron un enfoque orientado a objetos para disear derivaciones. Sin importar el mtodo del diseo que se utilice, debe aplicarse un conjunto de conceptos bsicos al diseo en el nivel de datos, arquitectura, interfaz y componentes.

Conceptos de diseo Ingeniera de software II Conceptos de diseo

Abstraccin Arquitectura

Patrones Divisin de problemas Modularidad Ocultamiento de informacin Refinamiento Rediseo Conceptos de diseo orientado a objetos Clases de diseo Abstraccin

Cuando se considera una solucin modular para cualquier problema, es posible plantear muchos niveles de abstraccin. En el mas elevado se enuncia una solucin en trminos amplios con el uso del lenguaje del ambiente del problema. En los niveles mas bajos de abstraccin se da la descripcin mas detallada de la solucin. Cuando se desarrollan niveles de abstraccin distintos, se trabaja para crear abstracciones tanto de procedimiento (secuencia de instrucciones) como de datos (conjunto de estos). Abstraccin

Abstraccin de procedimiento: palabra abrir, en e caso de una puerta. Abrir implica una secuencia larga de pasos del procedimiento (caminar hacia la puerta, llegar y tomar el picaporte, girar ste y jalar la puerta, etc.)
Arquitectura

Abstraccin de datos: puerta, como cualquier objeto de datos, la abstraccin de datos para puerta agrupara un conjunto de atributos que describiran la puerta (tipo, mecanismo de apertura, pero, dimensiones, etc.)

La arquitectura de software manifiesta a la estructura general de ste y a las formas en las que sta da integridad conceptual a un sistema. En su forma mas sencilla, la arquitectura es la estructura de organizacin de los componentes de un programa (mdulos), la forma en la que stos interactan y la estructura de datos que utilizan. Propiedades del diseo de la arquitectura: Propiedades estructurales (componentes)

Propiedades extrafuncionales (desempeo, capacidad, etc.) Familias de sistemas relacionados (reutilizar bloques de construccin arquitectnica)

Patrones Es una mezcla con nombre propio de puntos en vista que contienen la esencia de una solucin demostrada para problema recurrente dentro de cierto contexto de necesidades en competencia. Patrn de diseo describe una estructura de diseo que resuelve un problema particular del diseo dentro de un contexto especfico y entre fuerzas que afectan la manera en la que se aplica y en la que se utiliza dicho patrn. Divisin de problemas Sugiere que cualquier problema complejo puede manejarse con facilidad si se divide en elementos susceptibles de resolver y optimizarse de manera independiente. Un problema es una caracterstica o comportamiento que se especifica en el modelo de los requerimientos para el software. Al separar un problema en sus piezas mas pequeas y por ello mas manejables, se requiere menos esfuerzo y tiempo para resolverlo. Es mas fcil resolver un problema complejo si se divide en elementos manejables. Modularidad Es la manifestacin ms comn de la divisin de problemas. El software se divide en componentes con nombres distintos y abordables por separado, en ocasiones llamados mdulos, que se integran para satisfacer los requerimientos del problema. La modularidad es el nico atributo del software que permite que un programa sea manejable en lo intelectual. Debe hacerse un diseo con mdulos, de manera que el desarrollo pueda planearse con mas facilidad, Que sea posible definir y desarrollar los incrementos del software. Que los cambios se realicen con mas facilidad. Que las pruebas y la depuracin se efecten con mayor eficiencia Que el mantenimiento a largo plazo se lleve a cabo sin efectos colaterales de importancia. Ocultamiento de informacin Deben especificarse y disearse mdulos, de forma que la informacin (algoritmos y datos) contenida en un mdulo sea inaccesible para los que no necesiten de ella. Refinamiento Es un proceso de elaboracin. Se comienza con un enunciado de la funcin, definida en un nivel de abstraccin alto. Es decir, el enunciado describe la funcin o informacin de manera conceptual, pero no dice nada de los trabajos internos de la funcin o de la estructura interna de la informacin.

La abstraccin y el refinamiento son conceptos complementarios. La primera permite especificar internamente el procedimiento y los datos, el refinamiento ayuda a revelar estos detalles a medida que avanza el diseo. Ambos modelos permiten crear un modelo completo del diseo conforme ste evoluciona. Rediseo

Tcnica de reorganizacin que simplifica el diseo de un componente sin cambiar su funcin o comportamiento. Es el proceso de cambiar un sistema de software en forma tal que no se altera el comportamiento externo del cdigo, pero si se mejora su estructura interna. Cuando se redisea el software, se examina el diseo existente en busca de redundancias, elementos de diseo no utilizados, algoritmos ineficientes o innecesarios, estructuras de datos mal construidas o inapropiadas y cualquier falla del diseo que pueda corregirse para obtener un diseo mejor.