REPBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DEL PODER POPULAR PARA LA EDUCACIN UNIVERSITARIA UNIVERSIDAD POLITCNICA TERRITORIAL DEL ESTADO

ARAGUA "FEDERICO BRITO FIGUEROA" SEDE MARACAY

INGENIERIA DEL SOFTWARE

PROFESORA: Fatima De Almeida

Jess Gonzlez Jos Lamont Liseth Rumbos Eric Amaro Maracay, Mayo 2013

INTEGRANTES: C.I. V-17.155.623 C.I. V-12.853.866 C.I. V-19.245.959 C.I. V-12.146.742

INTRODUCCIN

El Software representa la vida interna de un computador, el manejo y aprovechamiento del mismo y todas las ventajas que se brindan el mundo de las computadoras, depende del software, facilitando a los usuarios el desarrollo de programas que contribuyen con tareas diarias tanto personales como generales, empresariales y organizacionales el software en sus diferentes tipos es el elemento esencial como interfaz entre usuario computador, su historia desde un principio se muestra con poca atencin pero con el paso del tiempo se ha tornado importante para los programadores y creadores de sistemas tanto de aplicacin como operativos, todo lo que se ve digitalizado en un computador representa el software clasificado de alguna forma, las herramientas del men inicio y todas aquellas que se despliegan al encendido del CPU, el desarrollo de esta herramienta ha permitido innovar en cuanto a la robtica he inteligencia artificial facilitando el trabajo en determinadas reas laborales y agilizando las mismas por ejemplo en la fabricacin de vehculos mediante software de programacin se disean estructuras robticas inmensas y fuertes que realizan tareas que al brazo humano le tomaran mas tiempo.

A travs de la historia de la ingeniera del software ha evolucionado un conjunto de conceptos fundamentales de diseo de software, aunque el grado de inters en cada concepto ha variado con los aos, han pasado la prueba del tiempo ofreciendo cada uno al ingeniero de software fundamentos sobre el cual pueden aplicarse mtodos de diseo ms elaborados.

El diseo de Software juega un papel importante en el desarrollo de software lo cual permite al ingeniero de software producir varios modelos del sistema o producto de que se va a construir el mismo que forman una

especie de plan de la solucin de la aplicacin. Estos modelos pueden evaluarse en relacin con su calidad y mejorarse antes de generar cdigo, de realizar pruebas y de que los usuarios finales se vean involucrados a gran escala.

El diseo es el sitio en el que se establece la calidad del software. Diseo es definido como: El proceso de definicin de la arquitectura, componentes, interfaces y otras caractersticas de un sistema o componente que resulta de este proceso.

Ingeniera de software

Es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento de software, y al estudio de estos enfoques, es decir, la aplicacin de la ingeniera al software. Se pueden citar otras definiciones enunciadas por prestigiosos autores:

Ingeniera de software es el estudio de los principios y metodologas para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)

Ingeniera de software es la aplicacin prctica del conocimiento cientfico al diseo y construccin de programas de computadora y a la documentacin asociada requerida para desarrollar, operar y mantenerlos. Se conoce tambin como desarrollo de software o produccin de software (Bohem, 1976).

Ingeniera de software trata del establecimiento de los principios y mtodos de la ingeniera a fin de obtener software de modo rentable, que sea fiable y trabaje en mquinas reales (Bauer, 1972). Algunos autores consideran que "desarrollo de software" es un trmino

ms apropiado que "ingeniera de software" para el proceso de crear software. Personas como Pete McBreen (autor de "Software Craftmanship") cree que el trmino IS implica niveles de rigor y prueba de procesos que no son apropiados para todo tipo de desarrollo de software. Indistintamente se utilizan los trminos "ingeniera de software" o "ingeniera del software". En Hispanoamrica el trmino usado normalmente es el primero de ellos.

La creacin del software es un proceso intrnsecamente creativo y la ingeniera del software trata de sistematizar este proceso con el fin de acotar el riesgo del fracaso en la consecucin del objetivo creativo por medio de diversas tcnicas que se han demostrado adecuadas en base a la experiencia previa. Principios bsicos de la Ingeniera de Software En los primeros das de la informtica, la programacin se vea como un arte. Existan pocos mtodos formales, y pocas personas los u saban. El programador aprenda normalmente su oficio mediante prueba y error. Hoy, la distribucin de costos en el desarrollo de sistemas informticos ha cambiado drsticamente. El software, en lugar del hardware, es normalmente el elemento principal del costo. Los problemas existentes en el desarrollo de software no va a desaparecer rpidamente. Las soluciones que se van elaborando tienden a asistir prcticamente al desarrollador de software, y mejorar la calidad del software. Mediante la combinacin de mtodos completos para todas las fases de desarrollo de software, mejores herramientas para automatizar estos mtodos, bloques de construccin ms potentes para la implementacin del software, mejores tcnicas para la garanta de calidad del software y una filosofa predominante para la coordinacin, control y gestin, puede conseguirse una disciplina para el desarrollo del software: Ingeniera del software.

Una definicin: El establecimiento y uso de principios de ingeniera robustos, orientados a obtener software econmico que sea fiable y funcione de manera eficiente sobre mquinas reales. (Fritz Bauer) La ingeniera de software cubre tres elementos claves:

Mtodos Herramientas, y Procedimientos

Los mtodos indican cmo construir tcnicamente el software. Estos mtodos abarcan tareas que incluyen: planificacin y estimacin de proyectos, anlisis de los requisitos del sistema y del software, diseo de estructuras de datos, arquitectura de programas y procedimientos

algortmicos, codificacin, prueba y mantenimiento. Suministran un soporte automtico o semiautomtico para los mtodos. Cuando se integran las herramientas de forma que la informacin creada por una herramienta pueda ser usada por otra, se establece un sistema de soporte llamada Ingeniera de Software Asistida por Computadora (CASE). Los procedimientos son el pegamento que junta los mtodos y las herramientas, y facilita un desarrollo racional y oportuno. Definen la secuencia en la que se aplican los mtodos, las entregas (documentos, informes, formas, etc.) que se requieren, los controles para asegurar la calidad y coordinar los cambios, y las directrices que ayudan a los gestores de software a evaluar el progreso.

La complejidad de los problemas No todos los sistemas de software son complejos. En particular las aplicaciones que son especificadas, construidas, mantenidas, y usadas por la misma persona, no pueden considerarse problemas complejos. Estos sistemas tienden a tener propsitos limitados y un ciclo de vida muy corto. Estas aplicaciones generalmente son ms tediosas que difcil de desarrollar, y en consecuencia aprender cmo se disean no es de nuestro inters. Las aplicaciones de mayor envergadura (las que presentan

comportamiento variado, mantienen la integridad de cientos de transacciones de registro de informacin, control de trfico, etc.), son esencialmente complejas. Esta complejidad es, en general, imposible de ser comprendida en su totalidad por una sola persona. Por esto se deben considerar formas disciplinadas para manejar la complejidad. La complejidad del software es una propiedad esencial, no una cuestin accidental (Brooks). En general la complejidad deriva de cuatro elementos :

La complejidad del dominio del problema, La dificultad para administrar el proceso de desarrollo, La posible flexibilidad del software, y Los problemas de caracterizar el comportamiento de sistemas discretos.

La complejidad del dominio del problema Los problemas que se intenta resolver en software frecuentemente involucran elementos de complejidad, tales como requerimientos que

compiten entre s, o contradictorios. A la complejidad propia del problema hay que agregarle las que surgen de requerimientos no funcionales, tales como usabilidad, performance, costo, continuidad en el tiempo, y confiabilidad. Otro aspecto de la complejidad surge por el problema de comunicacin entre los usuarios y los desarrolladores: los usuarios generalmente encuentran muy difcil dar en forma precisa sus necesidades de manera que los desarrolladores puedan entenderlas. En algunos casos extremos los usuarios pueden tener slo una vaga idea de lo que desean. Los usuarios y desarrolladores tienen diferentes perspectivas de la naturaleza de la solucin. En realidad, an si los usuarios tienen perfecto conocimiento de sus necesidades, los desarrolladores tienen pocos instrumentos para capturar en forma precisa estos requerimientos. La manera comn de expresar los requerimientos es con texto, acompaados por algunos diagramas. Estos documentos son difciles de comprender, son abiertos a interpretacin variada, y frecuentemente contienen elementos que son de diseo en vez de requerimientos esenciales. Otra complicacin adicional es que los requerimientos de un sistema frecuentemente cambian durante su desarrollo. La dificultad de administrar el proceso de desarrollo Hoy en da es habitual encontrar sistemas cuyo tamao se mide en cientos de miles, y an millones, de lneas de cdigo. Ninguna persona puede entender tales sistemas en forma completa. Si estos sistemas son descompuestos de alguna manera significativa, nos podemos encontrar con cientos o miles de mdulos separados.

Esto hace que se utilicen grupos de desarrollo, e idealmente tan pequeo como sea posible. Ms desarrolladores significa ms complejidad de comunicacin y de aqu ms dificultad de coordinacin, y en particular si el grupo est geogrficamente disperso. Con un grupo de desarrollo, la clave del desafo de administracin es siempre mantener una unidad e integridad de diseo. En la industria del software existen muy pocos estndares para la construccin de cdigo. Cada desarrollador puede construir de manera diferente una solucin para un mismo problema.

En aplicaciones grandes, puede haber cientos y an miles de variables as como tambin ms de un hilo de control. El conjunto completo de estas variables, sus valores actuales, las direcciones actuales y las pilas de llamada de cada proceso dentro del sistema constituyen el estado presente de la aplicacin. El software es ejecutado sobre computadoras digitales, y por lo tanto constituyen un sistema con estados discretos. Los sistemas discretos tienen una cantidad finita de estados posibles, en grandes sistemas estos tienen una explosin combinatoria haciendo este nmero muy grande. Los sistemas tienden a ser diseados con una separacin de intereses, para que el comportamiento de una parte del sistema tenga un impacto mnimo sobre el comportamiento de otra. Sin embargo cada evento externo al sistema tiene el potencial de colocar a este en un nuevo estado, y de esta manera el pasaje de estado a estado no es siempre determinstico. En algunas circunstancias, un evento externo puede corromper el estado de un sistema, porque sus diseadores fallaron al tomar en cuenta ciertas interacciones entre eventos. En sistemas discretos todos los eventos externos pueden afectar cualquier parte del estado interno del sistema. Esta es la motivacin primaria para un testeo vigoroso del sistema, pero excepto

para sistemas triviales, el testeo exhaustivo es imposible. Debido a que no se cuenta con herramientas matemticas o la capacidad intelectual para modelar el comportamiento completo de grandes sistemas, deben

establecerse niveles aceptables para asegurar su validez. Los cinco atributos de un sistema Complejo Hay cinco atributos comunes a todo sistema complejo (Simon, Ando, y Courtois) : Frecuentemente, la complejidad toma la forma de una jerarqua, por lo cual un sistema complejo est compuesto de subsistemas

interrelacionados que tienen a la vez sus propios subsistemas, hasta que algn nivel menor de componentes elementales es alcanzado. La estructura jerrquica es un factor importante que permite entender, describir, y ver un sistema y sus partes. La eleccin de qu componentes en un sistema son primitivas es relativamente arbitrario y depende del observador del sistema. Las vinculaciones internas de las componentes son generalmente ms fuertes que las vinculaciones entre los componentes. Esto tiende a separar la dinmica de alta frecuencia de las componentes - involucrando la estructura interna de las componentes - de la dinmica de baja frecuencia involucrando la interaccin entre las componentes. Esta diferencia entre interaccin interna y externa de las componentes proveen una clara diferenciacin de intereses entre las diferentes partes del sistema, haciendo posible estudiar cada parte en forma aislada.

Los sistemas jerrquicos estn generalmente compuestos de solamente pocas clases de subsistemas diferentes en varias combinaciones y rdenes. Los sistemas complejos tienen patrones comunes. Estos patrones pueden requerir el reuso de pequeas o grandes componentes. Un sistema complejo que trabaja, invariablemente ha evolucionado de un sistema simple que trabajaba... Un sistema complejo diseado de la nada nunca trabajar, y no puede ser `emparchado' para hacer que trabaje. Se debe empezar nuevamente, comenzando con un sistema simple que trabaje. Diseo de software La evolucin del diseo de software, como parte del proceso de desarrollo de software, es un proceso continuo que se ha ido produciendo durante las ltimas tres dcadas. Los primeros trabajos sobre diseo se centraron sobre los criterios para el desarrollo de programas modulares y los mtodos para mejorar la arquitectura del software de una manera descendente. Los aspectos procedimentales de la definicin del diseo evolucionaron hacia una filosofa denominada programacin estructurada. Posteriores trabajos propusieron mtodos para la traduccin del flujo de datos o de la estructura de los datos, en una definicin de diseo. Nuevos enfoques para el diseo proponen un mtodo orientado a objetos para la obtencin del diseo. Cada metodologa de diseo de software introduce heursticas y notaciones propias, as como una visin algo particular de lo que caracteriza a la calidad del diseo. Sin embargo, todas las metodologas tienen varias caractersticas comunes :

Un mecanismo para la traduccin de la representacin del campo de informacin en una representacin de diseo ;

Una notacin para representar los componentes funcionales y sus interfaces ;

Heursticas para el refinamiento y la particin, y Criterios para la valoracin de la calidad.

Diseo puede definirse como : Proceso iterativo de tomar un modelo lgico de un sistema junto con un conjunto de objetivos fuertemente establecidos para este sistema y producir las especificaciones de un sistema fsico que satisfaga estos objetivos. (Gane - Sarson). Actividad por la cual un relevamiento de datos y funciones de un sistema (modelo esencial) se traduce en un plan de implementacin. El modelo es volcado en una tecnologa determinada. ...el proceso de aplicar distintas tcnicas y principios con el propsito de definir un dispositivo, proceso o sistema con los suficientes detalles como para permitir su realizacin fsica. (E. Taylor)

Objetivos del Diseo El objetivo ms importante es:

entregar las funciones requeridas por el usuario (Satisfaga una especificacin funcional dada).

Pero adems para lograr esto deben considerarse los aspectos de :

Rendimiento: cun rpido permitir el diseo realizar el trabajo dado un recurso particular de hardware. Es decir que contemple las limitaciones del medio donde ser implementado el sistema, y alcance los requerimientos de performance y uso de recursos.

Control: proteccin contra errores humanos, mquinas defectuosas, o daos intencionales.

Cambiabilidad: facilidad con la cual el diseo permite modificar el sistema. Generalmente estos tres factores trabajan unos contra otros : un

sistema con muchos controles tender a degradar su rendimiento, un sistema diseado para un alto rendimiento solo podr ser cambiado con dificultad, etc.. Adems deber

Satisfacer criterios de diseo sobre la forma interna y externa del producto obtenido.

Satisfacer restricciones sobre el proceso de diseo en s mismo, tales como su tiempo o costo, o las herramientas disponibles para hacer el diseo. Una vez establecidos los requisitos del sistema, el diseo es la

primera de tres actividades tcnicas (diseo, codificacin y prueba). Cada actividad transforma la informacin de forma que finalmente se obtiene un software para computadora validado. Importancia del diseo de software

La importancia del diseo del software se puede sentar con una nica palabra: calidad. El diseo es el proceso en el que se asienta la calidad del desarrollo del software. El diseo produce las representaciones del software de las que puede evaluarse su calidad. La importancia del Diseo del Software se puede definir en una sola palabra Calidad, dentro del diseo es donde se fomenta la calidad del Proyecto. El Diseo es la nica manera de materializar con precisin los requerimientos del cliente.

El Diseo del Software es un proceso y un modelado a la vez. El proceso de Diseo es un conjunto de pasos repetitivos que permiten al diseador describir todos los aspectos del Sistema a construir. A lo largo del diseo se evala la calidad del desarrollo del proyecto con un conjunto de revisiones tcnicas: El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y debe acumular todos los requisitos implcitos que desea el cliente. Debe ser una gua que puedan leer y entender los que construyan el cdigo y los que prueban y mantienen el Software. El Diseo debe proporcionar una completa idea de lo que es el Software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementacin. Para evaluar la calidad de una presentacin del diseo, se deben establecer y en la fase de mantenimiento. Sin diseo nos arriesgamos a construir un sistema inestable, un sistema que falle cuando se realicen pequeos cambios, un sistema que pueda se difcil de probar, un sistema cuya calidad no pueda ser evaluada hasta ms adelante en el proceso de

ingeniera de software, cuando quede poco tiempo y se haya gastado ya mucho dinero. Modelos y filosofas de desarrollo de software La ingeniera de software dispone de varios modelos, paradigmas y filosofas de desarrollo, en los cuales se apoya para la construccin del software, entre ellos se puede citar:

Modelo en cascada o Clsico (modelo tradicional) Modelo de prototipos Modelo en espiral Desarrollo por etapas Desarrollo iterativo y creciente o Iterativo e Incremental RAD (Rapid Application Development) Desarrollo concurrente Proceso Unificado RUP (Proceso Unificado de Rational)

Modelo en cascada Tambin llamado desarrollo en cascada, es el enfoque metodolgico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior. Un ejemplo de una metodologa de desarrollo en cascada es: 1. Anlisis de requisitos. 2. Diseo del Sistema. 3. Diseo del Programa. 4. Codificacin.

5. Pruebas. 6. Implantacin. 7. Mantenimiento. De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria sigue siendo el paradigma ms seguido al da. Modelo de prototipos, En Ingeniera de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos. El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final. Este diseo conduce a la construccin de un prototipo, el cual es evaluado por el cliente para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La interaccin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo. Etapas

Plan rpido

Modelado, diseo rpido Construccin del Prototipo Desarrollo, entrega y retroalimentacin Comunicacin Entrega del desarrollo final

Modelo en espiral Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteracin representa un conjunto de actividades. Las actividades no estn fijadas a ninguna prioridad, sino que las siguientes se eligen en funcin del anlisis de riesgo, comenzando por el bucle interior. Tareas Para cada ciclo habr cuatro actividades: 1. Determinar Objetivos. 2. Anlisis del riesgo. 3. Planificacin. 4. Desarrollar y probar.

Desarrollo por etapas Modelo de desarrollo de software por etapas

Es similar al Modelo de prototipos ya que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultneamente con las diferentes versiones del cdigo. Pueden distinguirse las siguientes fases:

Especificacin conceptual Anlisis de requisitos Diseo inicial Diseo detallado, codificacin, depuracin y liberacin

Estas diferentes fases se van repitiendo en cada etapa del diseo Modelo Desarrollo iterativo y creciente (o incremental) Es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada. Para apoyar el desarrollo de proyectos por medio de este modelo se han creado frameworks (entornos de trabajo), de los cuales los dos ms famosos son el Rational Unified Process y el Dynamic Systems Development Method. El desarrollo incremental e iterativo es tambin una parte esencial de un tipo de programacin conocido como Extreme Programming y los dems frameworks de desarrollo rpido de software. Modelo de desarrollo rpido de aplicaciones o RAD Es un proceso de desarrollo de software, desarrollado inicialmente por James Maslow en 1980. El mtodo comprende el desarrollo interactivo, la construccin de prototipos y el uso de utilidades CASE (Computer Aided

Software Engineering). Tradicionalmente, el desarrollo rpido de aplicaciones tiende a englobar tambin la usabilidad, utilidad y la rapidez de ejecucin. Hoy en da se suele utilizar para referirnos al desarrollo rpido de interfaces grficas de usuario tales como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas ms conocidas son Visual Studio, Lazarus, Gambas, Delphi,Foxpro, Anjuta, Game Maker, Velneo o Clarion. En el rea de la autora multimedia, software como Neosoft Neoboo y MediaChance Multimedia Builder proveen plataformas de desarrollo rpido de aplicaciones, dentro de ciertos lmites. Modelo de Proceso Unificado Es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, el Proceso Unificado de Rational, tambin es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto. El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denomin, en su versin espaola, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos tambin por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no estn

afiliados a Rational utilizan el trmino Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational Modelo Proceso Unificado de Rational Rational Unified Process en ingls, habitualmente resumido como RUP es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, diseo, implementacin y documentacin de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Tambin se conoce por este nombre al software, tambin desarrollado por Rational, que incluye informacin entrelazada de diversos artefactos y descripciones de las diversas actividades. Est incluido en el Rational Method Composer (RMC), que permite la personalizacin de acuerdo con las necesidades. Originalmente se dise un proceso genrico y de dominio pblico, el Proceso Unificado, y una especificacin ms detallada, el Rational Unified Process, que se vendiera como producto independiente... Metodologa Un objetivo de dcadas ha sido el encontrar procesos y metodologas, que sean sistemticas, predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad del producto software.

Etapas del proceso La ingeniera de software requiere llevar a cabo numerosas tareas agrupadas en etapas, al conjunto de estas etapas se le denomina ciclo de vida. Las etapas comunes a casi todos los modelos de ciclo de vida son las siguientes: Anlisis de requisitos Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere habilidad y experiencia para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del anlisis de requisitos con el cliente se plasma en el documento ERS, Especificacin de Requisitos del Sistema, cuya estructura puede venir definida por varios estndares, tales como CMMI. Asimismo, se define un diagrama de Entidad/Relacin, en el que se plasman las principales entidades que participarn en el desarrollo del software. La captura, anlisis y especificacin de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque an no est formalizada, ya se habla de la Ingeniera de requisitos. La IEEE Std. 830-1998 normaliza la creacin de las especificaciones de requisitos de software (Software Requirements Specification). No siempre en la etapa de "anlisis de requisitos" las distintas metodologas de desarrollo llevan asociado un estudio de viabilidad y/o estimacin de costes. El ms conocido de los modelos de estimacin de coste del software es el modelo COCOMO

Especificacin La especificacin de requisitos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del xito de un proyecto de software radicar en la identificacin de las necesidades del negocio (definidas por la alta direccin), as como la interaccin con los usuarios funcionales para la recoleccin, clasificacin, identificacin, priorizacin y especificacin de los requisitos del software. Entre las tcnicas utilizadas para la especificacin de requisitos se encuentran:

Caso de uso, Historias de usuario, Siendo los primeros ms rigurosas y formales, los segundas ms

giles e informales. Arquitectura La integracin de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto. El arquitecto de software es la persona que aade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnolgicas. La arquitectura de sistemas en general, es una actividad de planeacin, ya sea a nivel de infraestructura de red y hardware, o de software.

La arquitectura de software consiste en el diseo de componentes de una aplicacin (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseo arquitectnico debe permitir visualizar la interaccin entre las entidades del negocio y adems poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseo arquitectnico describe en general el cmo se construir una aplicacin de software. Para ello se documenta utilizando diagramas, por ejemplo:

Diagramas de clases Diagramas de base de datos Diagrama de despliegue Diagrama de secuencia Siendo los dos primeros los mnimos necesarios para describir la

arquitectura de un proyecto que iniciar a ser codificado. Depende del alcance del proyecto, complejidad y necesidades, el arquitecto elige qu diagramas elaborar. Las herramientas para el diseo y modelado de software se denominan CASE, (Computer Aided Software Engineering) entre las cuales se encuentran:

Enterprise Architect Microsoft Visio for Enterprise Architects

Programacin Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera de software, pero no necesariamente es la que demanda mayor trabajo y ni la ms complicada. La complejidad y la duracin de esta etapa est ntimamente relacionada al o a los lenguajes de programacin utilizados, as como al diseo previamente realizado.

Prueba Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificacin del problema. Una tcnica de prueba es probar por separado cada mdulo del software, y luego probarlo de forma integral, para as llegar al objetivo. Se considera una buena prctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la program, idealmente un rea de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un rea de pruebas, la primera es que est compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evala que la documentacin entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como estn descritas. El segundo enfoque es tener un rea de pruebas conformada por programadores con experiencia, personas que saben sin mayores

indicaciones en qu condiciones puede fallar una aplicacin y que pueden poner atencin en detalles que personal inexperto no considerara. Documentacin Todo lo concerniente a la documentacin del propio desarrollo del software y de la gestin del proyecto, pasando por modelaciones (UML),diagramas de casos de uso, pruebas, manuales de usuario, manuales tcnicos, etc; todo con el propsito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema. Mantenimiento Fase dedicada a mantener y mejorar el software para corregir errores descubiertos e incorporar nuevos requisitos. Esto puede llevar ms tiempo

incluso que el desarrollo del software inicial. Alrededor de 2/3 del tiempo de ciclo de vida de un proyecto est dedicado a su mantenimiento. Una pequea parte de este trabajo consiste eliminar errores (bugs); siendo que la mayor parte reside en extender el sistema para incorporarle nuevas funcionalidades y hacer frente a su evolucin.

Atributo de la calidad del software

En los tiempos actuales el sello de calidad en la fabricacin de cualquier producto cobra una importancia relevante para determinar si un producto es mejor o peor que otro. En el desarrollo de sistemas interactivos este factor no pasa desapercibido hasta el punto que actualmente la usabilidad es considerada como un atributo de calidad en el desarrollo del software que es recogido en diversas clasificaciones de atributos de calidad. La percepcin cada vez mayor de la importancia de la usabilidad se afirma que ste es uno de los atributos de calidad que se consideran ms crticos en el proceso de desarrollo de software. Y dadas las ventajas que puede proporcionar debera ocupar un lugar relevante como factor de calidad estratgico.

Caractersticas de la calidad interna y externa del software descritas en el estndar. En la figura anterior observamos que la usabilidad es un atributo para garantizar la calidad de una aplicacin que se encuentra al mismo nivel que la propia funcionalidad del mismo.

Si bien los desarrolladores desearan conocer qu atributos incorporar en el cdigo para reducir el "esfuerzo requerido para su uso", o sea "para proporcionar usabilidad", la presencia o ausencia de atributos predefinidos no puede asegurar dicha caracterstica, igual que no hay manera fiable para predecir el comportamiento de los usuarios con el producto final.

Mantenibilidad de Software El IEEE1 (19990) define mantenibilidad como: La facilidad con la que un sistema o componente software puede ser modificado para corregir fallos, mejorar su funcionamiento u otros atributos o adaptarse a cambios en el entorno.

Dicho esto, podemos deducir que un software bien desarrollado debe tener la flexibilidad necesaria para adaptarse al futuro y que el mantenimiento deba hacerse de manera rpida y efectiva, afectando lo menos posible las labores de la entidad que lo utilice.

Por lo tanto, se deben corregir errores de manera rpida y efectiva, se le pueden agregar funciones nuevas al programa, deberamos con facilidad mejorar el uso del software a travs del tiempo, incrementar el rendimiento, resolver problemas actuales de vulnerabilidades o que puedan surgir en el futuro, y finalmente deberamos poder hacer cambios para que sea compatible con los nuevos sistemas operativos que varan a travs del tiempo.

Atributos de la Usabilidad

La compleja relacin que existe entre la usabilidad y los criterios de calidad que la definen conlleva la descomposicin de la usabilidad en una serie de aspectos que la caracterizan.

Tras una minuciosa revisin de la literatura relacionada encontramos que dicha descomposicin vara en funcin del punto de vista desde el que se enfoca, y confluye en un conjunto confuso de trminos relativos a la usabilidad.

Facilidad de Aprendizaje: Principio que hace referencia a la necesidad de minimizar el tiempo necesario que se requiere desde el no conocimiento de una aplicacin a su uso productivo.

Sintetizabilidad: El usuario tiene que poder evaluar el efecto de operaciones anteriores en el estado actual. Es decir, cuando una operacin cambia algn aspecto del estado anterior es importante que el cambio sea captado por el usuario.

Familiaridad: Los nuevos usuarios de un sistema poseen una amplia experiencia interactiva con otros sistemas. Esta experiencia se obtiene mediante la interaccin en el mundo real y la interaccin con otros sistemas informticos. La familiaridad de un sistema es la correlacin que existe entre los conocimientos que posee el usuario y los conocimientos requeridos para la interaccin en un sistema nuevo.

Consistencia: Este es un concepto clave en la usabilidad de un sistema informtico, pues consideraremos que un sistema es consistente si todos los mecanismos que se utilizan son siempre usados de la misma manera, siempre que se utilicen y sea cual sea el momento en el que se haga.

Flexibilidad: Esta caracterstica hace referencia a la multiplicidad de maneras en el que el usuario y el sistema intercambian informacin. Aportaremos flexibilidad a un sistema proporcionando control al usuario, posibilidad de migracin de tareas, capacidad de sustitucin y adaptabilidad (posteriormente se analizan estas caractersticas con ms detalle).

Robustez: La robustez de una interaccin cubre las caractersticas necesarias que permiten al usuario poder cumplir sus objetivos y el asesoramiento necesario para ello.

Recuperabilidad: Grado de facilidad que una aplicacin permite al usuario para corregir una accin una vez est reconocido un error.

Tiempo de Respuesta: Se define generalmente como el tiempo que necesita el sistema para expresar los cambios de estado del usuario. Esta caracterstica es de difcil parametrizacin debido a la enorme diversidad de velocidades computacionales de los distintos dispositivos y velocidades de transmisin de datos. A pesar de estas connotaciones tecnolgicas, es importante hacer consideraciones acerca de intentar que los tiempos de respuesta sean soportables para el usuario.

Adecuacin de tareas: Los servicios que el sistema proporciona deben soportar todas las tareas del usuario, que deben estar adaptadas al modelo mental de ste y no al del desarrollador.

Disminucin de la carga cognitiva: Los aspectos cognitivos de la interaccin referenciados en el apartado de los factores humano nos proporcionan la necesidad que tienen los usuarios de confiar ms en los reconocimientos que en los recuerdos (no tienen que recordar abreviaciones y cdigos muy complicados).

Este aspecto condicionar enormemente la disposicin y el diseo de los distintos elementos interactivos que aparecern en la interfaz.

La Norma ISO/IEC 9126

El estndar ISO 9126, ahora englobado en el proyecto SQuaRE para el desarrollo de la norma ISO 25000, establece un modelo de calidad en el que se recogen las investigaciones de multitud de modelos de calidad propuestos por los investigadores durante los ltimos 30 aos para la caracterizacin de la calidad del producto software. Este estndar propone un modelo de calidad que se divide en tres vistas: interior, exterior y en uso.

Estas vistas estn compuestas por caractersticas, que se dividen en sub-caractersticas, y que estas a su vez se componen de atributos.

Los atributos obtienen sus valores tras realizar mediciones sobre el software. Estas mediciones dan como resultado una serie de mtricas que se pueden clasificar en tres categoras segn sea su naturaleza:

Mtricas bsicas, que se obtienen directamente de analizar el cdigo o la ejecucin del software.

Mtricas de agregacin, que consisten en la composicin de una mtrica a partir de un conjunto definido de mtricas bsicas, generalmente mediante una suma ponderada.

Mtricas derivadas, que son una funcin matemtica que utiliza como entrada el valor de otras mtricas.

El modelo establece diez caractersticas, seis que son comunes a las vistas interna y externa y cuatro que son propias de la vista en uso. Las caractersticas que definen las vistas interna y externa, se muestran a continuacin en la Figura 1 y son:

Figura 1. Caractersticas de la Calidad segn la ISO/IEC 9126.

Funcionalidad, capacidad del software de proveer los servicios necesarios para cumplir con los requisitos funcionales.

Fiabilidad, capacidad del software de mantener las prestaciones requeridas del sistema, durante un tiempo establecido y bajo un conjunto de condiciones definidas.

Usabilidad, esfuerzo requerido por el usuario para utilizar el producto satisfactoriamente.

Eficiencia, relacin entre las prestaciones del software y los requisitos necesarios para su utilizacin.

Mantenibilidad, esfuerzo necesario para adaptarse a las nuevas especificaciones y requisitos del software. Portabilidad, capacidad del software ser transferido de un entorno a otro.

Mientras que las caractersticas propias de la vista en uso, se muestran a continuacin en la Figura 2:

Figura 2. Caractersticas de la vista en uso.

Efectividad, capacidad del software de facilitar al usuario alcanzar objetivos con precisin y completitud.

Productividad, capacidad del software de permitir a los usuarios gastar la cantidad apropiada de recursos en relacin a la efectividad obtenida.

Seguridad, capacidad del software para cumplir con los niveles de riesgo permitidos tanto para posibles daos fsicos como para posibles riesgos de datos.

Satisfaccin, capacidad del software de cumplir con las expectativas de los usuarios en un contexto determinado.

A continuacin se detallan las sub-caractersticas correspondientes a la mantenibilidad.

Analizabilidad, facilidad para analizar el software en busca de deficiencias e identificar sus componentes y artefactos. Capacidad de cambio, capacidad de permitir cambios en el software.

Estabilidad, capacidad de evitar efectos inesperados tras realizar modificaciones en el software.

Capacidad de pruebas, capacidad para validar los cambios en el software. Adherencia a las normas, cumplimiento de los estndares y convenciones de mantenibilidad. Hace referencia a todas las anteriores.

Pero si bien el modelo indica que estas subcaractersticas a su vez se subdividen en atributos, no se especifica cules son esos atributos, ya que

se entiende que estos son entidades dependientes del producto software y variarn segn vare la naturaleza del software analizado: lenguaje, paradigma de programacin, complejidad tecnolgica, etc.

Arquitectura Del Software

En un mundo cada vez ms globalizado, donde cada da desaparecen las barreras comerciales y culturales, la calidad aparece como una necesidad, pues la calidad permite competir con mayores posibilidades de xito. A pesar de que la programacin de sistemas no haba sido concebida desde la perspectiva de la calidad, la calidad en productos de software ha tenido un auge importante en la sociedad informatizada de hoy (Azuma, 1999). La Calidad de Software para Pressman (2002) es la concordancia con los requisitos funcionales y de rendimiento establecidos con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo software desarrollado de forma profesional. No obstante la ISO/IEC (Intenational Standart Organitation u Organizacin Internacional de Estndares en espaol) define a la calidad de software como la totalidad de rasgos y atributos de un producto de software que le apoyan en su capacidad de satisfacer sus necesidades explcitas o implcitas (ISO/IEC 9126, 1998).

Lo ms interesante en estas dos definiciones de la Calidad de Software, es la necesidad de que un software de calidad debe satisfacer los requerimientos dados por el usuario. Ahora bien, la IEEE, citado por (Barbacci et al, 1995) afirma que la calidad de un software es el grado en el cual el software posee una combinacin deseada de factores.

Actualmente en la literatura (Bass et al., 1998; Kazman et al., 2001; Hofmeister et al., 2000; Lane, 1990; Buschman et al., 1996; Booch et al., 1999; Abowd, 1995), es posible encontrar numerosas definiciones del trmino Arquitectura de Software, cada una con planteamientos diversos. Se hace evidente que su conceptualizacin sigue todava en discusin, puesto que no es posible referirse a un diccionario en busca de un significado, y tampoco existe un estndar que pueda ser tomado como marco de referencia.

Sin embargo, al hacer un anlisis detallado de cada uno de los conceptos disponibles, resulta interesante la existencia de ideas comunes entre los mismos, sin observarse planteamientos contradictorios, sino ms bien complementarios. La intencin primordial del anlisis no es concluir ni proponer un concepto que englobe todas las ideas planteadas hasta el momento, sino establecer aquellos elementos que no deben perderse de vista al momento de introducirse en el contexto de las arquitecturas de software, y por ende, en un ambiente de evaluacin de arquitectura de software.

La necesidad del manejo de la arquitectura de un sistema de software nace con los sistemas de mediana o gran envergadura, que se proponen como solucin para un problema determinado. En la medida que los sistemas de software crecen en complejidad, bien sea por nmero de requerimientos o por el impacto de los mismos, se hace necesario establecer medios para el manejo de esta complejidad (Hofmeister et al., 1996). En general, la tcnica es descomponer el sistema en piezas que agrupan aspectos especficos del mismo, producto de un proceso de abstraccin (Bass et al.,1998) y que al organizarse de cierta manera constituyen la base de la solucin de un problema en particular.

De aqu que la mayora de los autores (Bass et al., 1998; Kazman et al., 1998; Hofmeister et al., 1995; Lane, 1990; Buschman et al., 1996; Booch et al., 1999; Abowd, 1995) coinciden en que una arquitectura de software define la estructura del sistema. Esta estructura se constituye de componentes -mdulos o piezas de cdigo que nacen de la nocin de abstraccin, cumpliendo funciones especficas, e interactuando entre s con un comportamiento definido (Bass et al., 1998; Hayes-Roth, 1995; Hofmeister et al., 2000; Buschman et al., 1996; Booch et al., 1999; Abowd, 95). Los componentes se organizan de acuerdo a ciertos criterios, que representan decisiones de diseo. En este sentido, hay autores que plantean que la arquitectura de software incluye justificaciones referentes a la organizacin y el tipo de componentes, garantizando que la configuracin resultante satisface los requerimientos del sistema (Boehm et al., 1995).

De esta manera, la arquitectura de software puede ser vista como la estructura del sistema en funcin de la definicin de los componentes y sus interacciones (Bass et al., 1998). La prctica ha demostrado que resulta importante extender el concepto considerando los requerimientos y restricciones del sistema (Boehm et al., 1995; Lane, 1990), junto a un argumento que justifique que la estructura definida satisface los

requerimientos, dndole un sentido ms amplio a la definicin del trmino. La arquitectura de software puede considerarse entonces como el puente entre los requerimientos del sistema y la implementacin (Hofmeister et al., 2000). Las actividades que culminan en la definicin de la arquitectura pueden ubicarse en las fases tempranas del ciclo de desarrollo del sistema: luego del anlisis de los requerimientos y el anlisis de riesgos, y justo antes del diseo detallado.

Desde esta perspectiva, la arquitectura constituye un artefacto de la actividad de diseo (Hofmeister et al., 2000), que servir de medio de

comunicacin entre los miembros del equipo de desarrollo, los clientes y usuarios finales, dado que contempla los aspectos que interesan a cada uno (Kazman et al., 2001). Adems, pasa a ser la base del diseo del sistema a desarrollar, razn por la cual en la literatura la arquitectura es considerada como plan de diseo del sistema (Hofmeister et al., 2000), debido a que es usada como gua para el resto de las tareas del desarrollo.

De igual manera, sern de particular importancia las propiedades no funcionales del sistema de software, pues influyen notoriamente en la calidad del mismo. Estas propiedades tienen un gran impacto en el desarrollo y mantenimiento del sistema, su operabilidad y el uso que ste haga de los recursos (Buschman et al., 1996). Entre las propiedades no funcionales ms importantes se encuentran: modificabilidad, eficiencia, mantenibilidad, interoperabilidad, confiabilidad, reusabilidad y facilidad de ejecucin de pruebas (Kazman et al., 2001). Bass et al. (1998) proponen que el trmino requerimiento no funcional es disfuncional, debido a que implica que tal requerimiento no existe, o que es una especie de requerimiento que puede ser especificado independientemente del comportamiento del sistema. En este sentido, Bass indica que debe hacerse referencia a atributos de calidad, en lugar de propiedades no funcionales.

Puede observarse que al hablar de arquitectura de software, se hace alusin a la especificacin de la estructura del sistema, entendida como la organizacin de componentes y relaciones entre ellos; los requerimientos que debe satisfacer el sistema y las restricciones a las que est sujeto, as como las propiedades no funcionales del sistema y su impacto sobre la calidad del mismo; las reglas y decisiones de diseo que gobiernan esta estructura y los argumentos que justifican las decisiones tomadas.

Habiendo aclarado el alcance que puede tomar el trmino arquitectura de software, resulta de gran inters introducir formalmente otros trminos que resultan pilares fundamentales dentro del contexto de arquitectura, dado que en torno a ellos gira gran parte del estudio que hasta el momento se ha realizado sobre el tema. Tal es el caso de los componentes, los conectores y las relaciones.

Patrn de Diseo

Los patrones de diseo son el esqueleto de las soluciones a problemas comunes en el desarrollo de software. En otras palabras, brindan una solucin ya probada y documentada a problemas de desarrollo de software que estn sujetos a contextos similares. Debemos tener presente los siguientes elementos de un patrn: su nombre, el problema (cuando aplicar un patrn), la solucin (descripcin abstracta del problema) y las consecuencias (costos y beneficios).

Existen varios patrones de diseo popularmente conocidos, los cuales se clasifican como se muestra a continuacin:

Patrones Creacionales: Inicializacin y configuracin de objetos. Patrones Estructurales: Separan la interfaz de la implementacin. Se ocupan de cmo las clases y objetos se agrupan, para formar estructuras ms grandes.

Patrones de Comportamiento: Ms que describir objetos o clases, describen la comunicacin entre ellos.

Veamos un poco en qu consisten los distintos tipos de patrones, cules son sus fines y qu beneficios nos aportan.

Patrones Creacionales Fbrica Abstracta (Abstract Factory) El problema a solucionar por este patrn es el de crear diferentes familias de objetos, como por ejemplo la creacin de interfaces grficas de distintos tipos (ventana, men, botn, etc.).

Mtodo de Fabricacin (Factory Method) Parte del principio de que las subclases determinan la clase a implementar.
public class ConcreteCreator extends Creator { protected Product FactoryMethod() { return new ConcreteProduct(); } } public interface Product{} public class ConcreteProduct implements Product{} public class Client { public static void main(String args[]) { Creator UnCreator; UnCreator = new ConcreteCreator(); UnCreator.AnOperations(); } }

Prototipado ( Prototype ) Se basa en la clonacin de ejemplares copindolos de un prototipo. Singleton Restringe la instanciacin de una clase o valor de un tipo a un solo objeto.
public sealed { private private private { class Singleton static volatile Singleton instance; static object syncRoot = new Object(); Singleton()

System.Windows.Forms.MessageBox.Show("Nuevo Singleton"); } public static Singleton GetInstance { get { if (instance == null) { lock(syncRoot) { if (instance == null) instance = new Singleton(); } } return instance; } } }

MVC ( Model View Controler ) Este patrn plantea la separacin del problema en tres capas: la capa model, que representa la realidad; la capa controler, que conoce los mtodos y atributos del modelo, recibe y realiza lo que el usuario quiere hacer; y la capa vista, que muestra un aspecto del modelo y es utilizada por la capa anterior para interaccionar con el usuario.

Patrones Estructurales Adaptador (Adapter): Convierte una interfaz en otra. Puente (Bridge): Desacopla una abstraccin de su implementacin permitiendo modificarlas independientemente. Objeto Compuesto (Composite): Utilizado para construir objetos complejos a partir de otros ms simples, utilizando para ello la composicin recursiva y una estructura de rbol. Envoltorio (Decorator): Permite aadir dinmicamente funcionalidad a una clase existente, evitando heredar sucesivas clases para incorporar la nueva funcionalidad.

Fachada (Facade): Permite simplificar la interfaz para un subsistema. Peso Ligero (Flyweight): Elimina la redundancia o la reduce cuando tenemos gran cantidad de objetos con informacin idntica. Apoderado (Proxy): Un objeto se aproxima a otro.

Patrones de Comportamiento

Cadena de responsabilidad (Chain of responsibility): La base es permitir que ms de un objeto tenga la posibilidad de atender una peticin.

Orden (Command): Encapsula una peticin como un objeto dando la posibilidad de deshacer la peticin.

Intrprete (Interpreter): Intrprete de lenguaje para una gramtica simple y sencilla.

Iterador (Iterator): Define una interfaz que declara los mtodos necesarios para acceder secuencialmente a una coleccin de objetos sin exponer su estructura interna.

Mediador (Mediator): Coordina las relaciones entre sus asociados. Permite la interaccin de varios objetos, sin generar acoples fuertes en esas relaciones.

Recuerdo (Memento): Almacena el estado de un objeto y lo restaura posteriormente.

Observador (Observer): Notificaciones de cambios de estado de un objeto.

Estrategia de diseo: orientado a funciones

Un mdulo o funcin es una parte lgicamente separable de un programa. Es una unidad discreta e identificable respecto a la compilacin y carga. Ej: macro, funcin, procedimiento, package.

Criterios

utilizados

para

seleccionar

mdulos

que

soporten

abstracciones bien definidas y solucionables/modificables separadamente: Acoplamiento Cohesin

Acoplamiento Dos mdulos son independientes si cada uno puede funcionar completamente sin la presencia del otro. La independencia entre mdulos es deseable:

Los mdulos se pueden modificar separadamente. Se pueden implementar y testear independientemente. El costo de programacin decrece. En un sistema no existe la independencia entre todos los mdulos. Los mdulos deben cooperar entre s. Cuanto ms conexiones hay entre dos mdulos, ms dependientes son uno del otro.

El acoplamiento entre mdulos queda definido por la fuerza de conexin entre dichos mdulos.

En general: cuanto ms necesitamos conocer de un mdulo A para comprender un mdulo B, mayor es la conexin de A a B. Los mdulos fuertemente acoplados estn unidos por fuertes conexiones. Los mdulos dbilmente acoplados estn dbilmente conectados.

La complejidad y oscuridad de las interfaces de un mdulo (i.e. el tipo de conexin) incrementan el acoplamiento. Minimizar la cantidad de interfaces por mdulo. Minimizar la complejidad de cada interfaz.

El acoplamiento disminuye si:

Slo las entradas definidas en un mdulo son utilizadas por otros. La informacin se pasa exclusivamente a travs de parmetros.

El acoplamiento se incrementa si:

Se utilizan interfaces indirectas y oscuras. Se usan directamente operaciones y atributos internos al mdulo. Se utilizan variables compartidas

Cohesin

El acoplamiento caracteriza el vnculo intermodular. Se reduce minimizando las relaciones entre los elementos de los distintos mdulos. Otra forma de lograr un efecto similar es maximizando las relaciones entre los elementos del mismo mdulo.

La cohesin considera esta relacin. La cohesin caracteriza el vnculo intramodular. Con la cohesin intentamos capturar cuan

cercanamente estn relacionados los elementos de un mdulo entre s. Es deseable menor acoplamiento y mayor cohesin

La cohesin de un mdulo representa cuan fuertemente vinculados estn los elementos de un mdulo. Da una idea de si los distintos elementos de un mdulo tienen caractersticas comunes.

Objetivo: Alta cohesin. La cohesin y el acoplamiento estn correlacionados. Usualmente, a mayor cohesin de los mdulos, menor acoplamiento entre los mdulos. Pero la correlacin no es perfecta.

Estrategia de diseo: orientada a estructuras de datos:

El

diseo

orientado

estructura

de

datos

transforma

una

representacin de la estructura de datos en una representacin del software. La metodologa de desarrollo del sistema de Jackson parte de que la paralelizacin de la estructura de datos de entrada y salida (informe) asegurar un diseo de calidad. Puede aplicarse con xito a aplicaciones que tengan una estructura jerrquica, bien definida de la informacin.

Aplicaciones en sistemas de informacin comerciales. La entrada y salida tiene distinta estructura (Por ejemplo, archivos de entrada, informes de salida); el uso de una base de datos jerrquico es frecuente.

Aplicaciones de sistema. La estructura de datos para los sistemas operativos comprende muchas tablas, archivos y listas que tienen una estructura bien definida

El diseo orientado a la estructura de datos puede ser adecuado para aplicaciones del dominio de la ingeniera y de la ciencia, enseanza asistida por computadoras resolucin de problemas combinatorios y muchas otras reas.

En general, es ms difcil de aprender y ms complicado de aplicar que las tcnicas orientadas al flujo de datos. Sin embargo, la escuela de diseo orientado a la estructura de datos ofrece un enfoque ms rico y, potencialmente, ms poderoso para el software.

Cada mtodo orientado a la estructura de datos tiene su propio conjunto de reglas. Sin embargo, deben realizarse siempre las siguientes tareas de diseo:

1. Evaluar las caractersticas de la estructura de datos. 2. Representar los datos en trminos de formas elementales, tales como secuencia, seleccin y repeticin. 3. Transformar la representacin de la estructura de datos en una jerarqua de control para el software. 4. Refinar la jerarqua de software usando los criterios definidos como parte de un mtodo. 5. Desarrollar finalmente una descripcin procedimental del software.

Diseo de software orientado a aspectos

Son muchos los intereses que un equipo de desarrollo de software debe fijar su atencin: entender el problema, entender su entorno, gestin del proyecto, equipo de desarrollo, aspectos tcnicos, entre otros. Los intereses referidos a aspectos tcnicos como seguridad, persistencia, presentacin, manejo de errores, etc. Han dado origen al paradigma orientado a aspectos. El enfoque orientado a aspectos define un mecanismo que ayuda a resolver problemas de codificacin en los requisitos, los cuales son un cdigo disperso (scattered) y diseminado (tangled), que no se resuelven fcilmente usando el enfoque orientado a objetos. Este mecanismo se enfoca principalmente en la separacin de intereses (separation of concerns) de un sistema para obtener una mejor modularizacin,

Ivar Jaconson, un lder del pensamiento en el mundo del software donde ha hecho varias contribuciones decisivas, no poda faltar en el revolucionario camino del enfoque orientado a aspectos. En este sentido, Jacobson y su compaero de trabajo Pan-Wei Ng (en Ivar Jacobson Consulting - IJC) publicaron, en el ao 2005, el libro titulado Aspect-Oriented Software Development with Use Cases donde describen la extensin del Proceso Unificado para desarrollar software con aspectos. En este artculo se

proporciona una breve descripcin de cada fase del desarrollo de software orientado a aspectos propuesto por los autores. Esta descripcin le permitir familiarizarse con trminos claves de este enfoque, invitndolo a adquirir el libro para una completa comprensin ya que ilustra un caso prctico de aplicacin.

El desarrollo de software orientado a aspectos (DSOA) se enfoca en crear una mejor abstraccin modular del sistema. Incluye las siguientes fases:

Captura de requisitos Anlisis Diseo Implementacin Pruebas

La primera fase trata la separacin de intereses tanto los funcionales como los no funcionales; los requisitos funcionales son modelados con casos de uso que representan la funcin bsica del sistema y los requisitos no funcionales se representan con casos de uso de infraestructura. En el anlisis y el diseo los casos de uso se representan en una estructura de composicin que se identifica con el estereotipo <<use case slice>> y agrupa elementos de modelo que colaboran para lograr los requisitos del sistema tanto funcionales como no funcionales. En la implementacin se genera el cdigo de las clases y aspectos. Por ltimo en las pruebas se disean las pruebas tanto para los casos de uso de la aplicacin como para los casos de uso slice.

Captura de requisitos En esta fase se identifican dos categoras de casos de uso: de aplicacin y de infraestructura. Los casos de uso de aplicacin describen las

funcionalidades bsicas del sistema. Los casos de uso de infraestructura describen cmo el sistema agrega cualidades como facilidad de uso, confiabilidad, de rendimiento y de soporte para cada paso de un caso de uso de aplicacin.

La primera actividad consiste en entender los intereses de los stakeholders. El resultado es obtener una lista de caractersticas del sistema la cual incluye requisitos funcionales y no funcionales. A continuacin, se capturan los casos de uso de la aplicacin. Esta actividad consiste en identificar actores y casos de usos a partir de los requisitos funcionales de la lista de caractersticas, y describir los casos de uso en las especificaciones de casos de uso contemplando posibles extensiones. La descripcin de los casos de uso ayudar a identificar intereses de corte transversal.

En la ltima actividad se capturan los casos de uso de infraestructura como extensiones modulares a los casos de uso de aplicacin. Para ello, se revisa nuevamente la lista de caractersticas del sistema para identificar a los requisitos no funcionales que afectan a algn paso de los casos de uso de aplicacin, los cules sern tratados como casos de uso de transaccin (usecase transaction) si se tratan de requisitos de infraestructura para el sistema.

Esta actividad termina con la descripcin de estos tipos de casos de uso en una especificacin contemplando tambin sus flujos alternativos.

Anlisis Durante el anlisis se identifica la estructura de los elementos del anlisis en trminos de capas, paquetes y clases (boundary, control y entity). Tambin se identifican las estructuras de caso de uso conformados por paquetes estereotipados con <<use-case slice>> y <<non-uc-specific

slice>>. Los paquetes use-case slice y non-uc-specific slice son unidades modulares especficas y no especficas respectivamente que permiten organizar mucho mejor el sistema.

Un use-case slice contiene elementos necesarios para un caso de uso especfico: una colaboracin, que describe la realizacin de un caso de uso; una o ms clases especficas, que son requeridas para la realizacin del caso de uso; y extensiones de clase especficas para un cierto aspecto.

Un non-uc-specific slice contiene clases del dominio del problema que se usan en muchos casos de uso.

Diseo

Aqu se incluyen actividades relacionadas a refinar las dos estructuras identificadas en el anlisis incluyendo detalles del ambiente de

implementacin. Mientras que la estructura del modelo de anlisis es independiente de la plataforma (lenguajes de programacin y tecnologa), el modelo de diseo es especfico a una plataforma que ser utilizado en la implementacin.

El proceso de refinamiento consiste en refinar las clases con detalles de implementacin y refinar los casos de uso slice incluyendo aspectos y las extensiones de clases.

Implementacin En esta etapa se genera el cdigo de las clases con un lenguaje de implementacin como JAVA. Asimismo, se codifican los aspectos en un lenguaje orientado a aspectos como AspectJ.

Pruebas Las pruebas se llevan a cabo desde los requisitos hasta la codificacin. Se disean pruebas para cada caso de uso y caso de uso slice. Por otro lado, se crean casos de prueba slice que se puedan remover al completar las pruebas.

CONCLUSIN

Muchas notaciones y lenguajes existen para representar el diseo de artefactos de software. Algunos describen un diseo estructural organizado, otros representan el inicio del software. Estas notaciones son generalmente usadas durante un diseo natural y se pueden usar durante ambos casos. Una representan notaciones que son usadas en el contexto de especficos mtodos en las estrategias de diseo y mtodos de sub reas, pero estas categoras son categorizadas en notaciones para describir la estructura esttica y la dinmicas vistas.

Existen varias estrategias en el desarrollo del software que permiten mejorar el diseo de procesos, a diferencia con las estrategias generales, mtodos que son especficos en generar estrategias y proveen notacin

para ser usados en Mtodos y descripcin del proceso. Los mtodos utilizados son medias que permiten transferir conocimiento y como un framework que permiten testear la ingeniera del software.

Las estrategias generales son usadas en el diseo de procesos son divididos y refinados permitiendo lograr una alta extraccin de datos y informacin para esto utilizando heursticas usando para esto patentes y patentes de lenguajes

Los atributos de calidad generales del software son escalabilidad, seguridad, desempeo, y fiabilidad. Los requerimientos de los atributos de calidad son parte de los requerimientos no funcionales de una aplicacin, la cual captura las mltiples facetas de cmo los requerimientos funcionales de una aplicacin son logrados. Para que tenga sentido los requerimientos de atributos de calidad deben ser especficos de cmo una aplicacin debe lograr una necesidad dada.

En el diseo de software no se debe reinventar la rueda en varias de nuestras aplicaciones. Hay mucho trabajo ya realizado, testeado y aceptado que en un entorno similar a nuestro problema ya aporta una solucin satisfactoria. Para qu vamos a inventar un ladrillo si ya otro lo hizo y el mismo ya fue usado en la edificacin de millones de estructuras con xito?

BIBLIOGRAFIA

.- http://msdn.microsoft.com/es-es/library/bb972240.aspx .- http://iso25000.com/index.php/iso-iec-9126.html .- http://software.guisho.com/calidad-del-software .- http://www.grihohcitools.udl.cat/mpiua/usabilidad/atributos.html .- http://www.basilv.com/psd/blog/2006/the-importance-of-maintainablesoftware .- http://software.ac.uk/resources/guides/developing-maintainable-software .- http://informatic2you.wordpress.com/2013/02/13/mantenibilidad-desoftware/ .- http://www.grihohcitools.udl.cat/mpiua/usabilidad/calidad.html .- http://aurarivera4.blogspot.com/2010/12/atributos-de-calidad.html