INDICE

INTRODUCCIN La Arquitectura de software identifica los elementos mas importantes de un sistema, as como sus relaciones; nos da una visin global del sistema y tiene mucho que ver con el diseo de estructuras. Su importancia radica en que necesitamos arquitectura para entender el sistema, organizar su desarrollo, plantear la reutilizacin del software y hacerlo evolucionar. Las arquitecturas de software no responden solo a requisitos estructurales, sino que estn relacionadas con el rendimiento, uso, reutilizacin, restricciones econmicas y tecnolgicas e incluso las cuestiones estticas. Determinar los elementos que definen una arquitectura es una tarea difcil; por eso es que se utilizan las metodologas de

desarrollo, las cuales indican principios muy generales para identificar y disear una estructura. Dependiendo de la importancia del caso, se puede implementar una metodologa diferente. Por ejemplo, en aquellos que aminoran los riegos mas importantes y los que representan la funcionalidad bsica del software, la estructura base estar especificada por: * Diagramas que muestren subsistemas e interfaces entre los mismos. * Diagramas de componentes, clases, descripciones y conjuntos de caso de uso bsicos. Estas especificaciones nos sirven para aprobar la arquitectura con los clientes y asegurar que al implementarlo cumplir adecuadamente la funcionalidad bsica que se requiere. As, el software se desarrolla iterativamente hasta tenerlo funcionalmente completo. Otro mtodo es identificar el tipo de sistema a construir, estudiando aplicaciones del mismo tipo.

Arquitectura de Software Una arquitectura es el conjunto de decisiones significativas sobre la organizacin de un sistema de software que define los principios que guan el desarrollo, los componentes principales del sistema, sus responsabilidades y la forma en que se Interrelacionan.

Caractersticas de la Arquitectura de Software

Requerimientos No Funcionales Requerimientos No FuncionalesTienen que ver con las caractersticas que de una u otra forma puedan limitar el sistema. Describen una restriccin sobre el sistema que limita nuestra eleccin en la construccin de una solucin. Ing. Lisseth Agero Mirabal 7. Requerimientos No Funcionales ATRIBUTOS DE CALIDAD DEL SISTEMA ConfiabilidadDesempeo: Seguridad Tiempo de repuesta inmediato Ing. Lisseth Agero Mirabal 8. Requerimientos No Funcionales ATRIBUTOS DE CALIDAD DEL SISTEMA El sistema debe estar en capacidad de permitir en el futuroEscalabilidad: el desarrollo de nuevas funcionalidades, modificar o eliminar funcionalidades. Ing. Lisseth Agero Mirabal Requerimientos Funcionales requerimientos funcionales son los requerimientos que debe de cumlir el sistema en cuestion del proceso, digamos una biblioteca, un requerimiento funcional es que el sistema permita hacer prestamos de libros y un no funcional se refiere al rendimiento digamos que la consulta de libros disponibles se realice en menos de 2 segundos.

En general los funcionales cumplen las reglas del negocio y caracteristicas del negocio, y las no funcionales con el rendimiento de los procesos o del sistema, asi como las caracteristicas de hardware, estandares o incluso legales.

Arquitectura del Software: Requisitos no-funcionales Los requisitos no funcionales son aquellos requisitos que no aparecen en casos de uso. Estos requisitos, en lugar de definir lo que la aplicacin hace, definen cmo la aplicacin proporciona las funcionalidades requeridas.

Hay tres reas mbitos los requisitos no funcionales: Tcnicos: Estos son familiares para todos. Se limitan las opciones de diseo mediante la especificacin de algunas tecnologas que se deben utilizar. "Slo tenemos los desarrolladores de Java, por lo que debemos desarrollar en Java." "La base de datos existente se ejecuta en Windows XP." Estos requisitos son por lo general, no negociables. De negocio: Para los negocios, no hay razones tcnicas. Por ejemplo, "A fin de ampliar nuestra base de clientes potenciales, se debe interactuar con las herramientas de XYZ." Otro ejemplo es "El proveedor de nuestro middleware ha aumentado sus precios a niveles prohibitivos, por lo que nos estamos moviendo a una versin de cdigo abierto." La mayora de estos requerimientos tambin son no negociables. De calidad: definir los requisitos de una aplicacin en trminos de escalabilidad, disponibilidad, facilidad de cambio, la portabilidad, facilidad de uso,

por rendimiento... Una arquitectura de un sistema, aplicacin o proyecto debe tambin tener en cuenta los requisitos que no aparecen explcitamente en los casos de uso del sistema. Los arquitectos del software, por tanto, tienen la necesidad de entender los requisitos funcionales, para crear una plataforma que apoye dichos requisitos y satisfaga tambin los requisitos no funcionales.

Un requisito no funcional o atributo de calidad es, en la ingeniera de sistemas y la ingeniera de software, un requisito que especifica criterios que pueden usarse para juzgar la operacin de un sistema en lugar de sus comportamientos especficos, samir ya que stos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que ni describen informacin a guardar, ni funciones a realizar. Algunos ejemplos de requisitos no funcionales tpicos son los siguientes: rendimiento disponibilidad seguridad accesibilidad usabilidad estabilidad portabilidad costo operatividad interoperabilidad escalabilidad concurrencia mantenibilidad interfaz

La calidad del software es una preocupacin a la que se dedican muchos esfuerzos. Sin embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo producir software de la mejor calidad posible, que cumpla, y si puede supere las expectativas de los usuarios. Calidad de software Caractersticas propias del software aquellas que tu quieres controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan fsicamente, sino que se desarrolla. El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carcter fsico. La calidad del software se encuentra casi a la par de la calidad tradicional, ligeramente detrs debido a que la calidad tradicional tiene varias dcadas de historia, mientras que la calidad de software tiene entre 50 y 30 aos de haber surgido.

Principales caractersticas que hacen a un software de calidad. Mantenibilidad: el software debe ser diseado de tal manera, que permita ajustarlo a los cambios en los requerimientos del cliente. Esta caracterstica es crucial, debido al inevitable cambio del contexto en el que se desempea un software. Confiabilidad: incluye varias caractersticas adems de la confiabilidad, como la seguridad, control de fallos, etc. Eficiencia: tiene que ver con el uso eficiente de los recursos que necesita un sistema para su funcionamiento. Usabilidad: el software debiera ser utilizado sin un gran esfuerzo por los usuarios para los que fue diseado, documentado, etc.

caractersticas propiciadas por la arquitectura estndar iso 9126

ISO 9126 es un estndar internacional para la evaluacin del Software. Est supervisado por el proyecto SQuaRE, ISO 25000:2005, el cul sigue los mismos conceptos. El estndar est dividido en cuatro partes las cuales dirigen, respectivamente, lo siguiente: modelo de calidad, mtricas externas, mtricas internas y calidad en las mtricas de uso. El modelo de calidad establecido en la primera parte del estndar, ISO 9126-1. Dicho estndar ha sido desarrollado en un intento de identificar los atributos clave de calidad para el software. El estndar identifica 6 atributos clave de calidad: Funcionalidad El grado en que el software satisface las necesidades indicadas por los siguientes subatributos: Idoneidad Correccin Interoperabilidad Conformidad Seguridad Fiabilidad Cantidad de tiempo que el software est disponible para su uso. Est referido por los siguientes subatributos: Madurez Tolerancia a fallos Facilidad de recuperacin

Usabilidad Grado en que el software hace ptimo el uso de los recursos del sistema. Est indicado por los siguientes subatributos: Facilidad de comprensin Facilidad de aprendizaje Operatividad Eficiencia Grado en que el software hace ptimo el uso de los recursos del sistema. Est indicado por los siguientes subatributos: Tiempo de uso Recursos utilizados Mantenibilidad Facilidad con que una modificacin puede ser realizada. Est indicada por los siguientes subatributos: Facilidad de anlisis Facilidad de cambio Estabilidad Facilidad de prueba Portabilidad La facilidad con que el software puede ser llevado de un entorno a otro. Est referido por los siguientes subatributos: Facilidad de instalacin Facilidad de ajuste Facilidad de adaptacin al cambio El atributo Conformidad no est listada arriba ya que se aplica a todas las caractersticas. Ejemplos son conformidad a la legislacin referente a usabilidad y fiabilidad.

Un atributo es una entidad la cual puede ser verificada o medida en el producto software. Los atributos no estn definidos en el estndar, ya que varan entre diferentes productos software. Un producto software est definido en un sentido amplio como: los ejecutables, cdigo fuente, descripciones de arquitectura, y as. Como resultado, la nocin de usuario se ampla tanto a operadores como a programadores, los cuales son usuarios de componentes como son bibliotecas software. El estndar provee un entorno para que las organizaciones definan un modelo de calidad para el producto software. Haciendo esto as, sin embargo, se lleva a cada organizacin la tarea de especificar precisamente su propio modelo. Esto podra ser hecho, por ejemplo, especificando los objetivos para las mtricas de calidad las cuales evalan el grado de presencia de los atributos de calidad. Mtricas internas son aquellas que no dependen de la ejecucin del software (medidas estticas). Mtricas externas son aquellas aplicables al software en ejecucin. La calidad en las mtricas de uso estn slo disponibles cuando el producto final es usado en condiciones reales. Idealmente, la calidad interna determina la calidad externa y esta a su vez la calidad en el uso. Este estndar proviene desde el modelo establecido en 1977 por McCall y sus colegas, los cuales propusieron un modelo para especificar la calidad del software. El modelo de calidad McCall est organizado sobre tres tipos de Caractersticas de Calidad: Factores (especificar): Ellos describen la visin externa del software, como es visto por los usuarios. Criterios (construir): Ellos describen la visin interna del software, con es visto por el desarrollador.

Mtricas (controlar): Ellas son definidas y usadas para proveer una escala y mtodo para la medida. ISO 9126 distingue entre fallos y no conformidad, siendo un fallo el no cumplimiento de los requisitos previos, mientras que la no conformidad afecta a los requisitos especificados. Una distincin similar es hecha entre la validacin y la verificacin. tilidad de las normas ISO / IEC 9126 Este estndar est pensado para los desarrolladores, adquirentes, personal que asegure la calidad y evaluadores independientes, responsables de especificar y evaluar la calidad del producto software. Por tanto, puede servir para validar la completitud de una definicin de requisitos, identificar requisitos de calidad de software, objetivos de diseo y prueba, criterios de aseguramiento de la calidad, etc. La calidad de cualquier proceso del ciclo de vida del software (estndar ISO 12.207) influye en la calidad del producto software que, a su vez, contribuye a mejorar la calidad en el uso del producto. La calidad del software puede evaluarse midiendo los atributos internos (medidas estticas o productos intermedios) o atributos externos (comportamiento del cdigo cuando se ejecuta).

CONCLUSION

La arquitectura del software nos proporciona una visin global del sistema a construir. Los componentes del software incluyen mdulos de programas y varias representaciones de datos que son manipulados por el programa. La arquitectura marca decisiones de diseo tempranas y proporciona el mecanismo para evaluar los beneficios de las estructuras de sistema alternativas. No se puede medir la calidad del software de forma correcta debido a su naturaleza, la certificacin se da a los procesos, la correcta consecucin de los mismos garantizara un buen software. No se puede medir al software como tal, sino los atributos que la conforman, tales mtodos de medida deben ser exactos. El usuario final mide la calidad del software segn lo que tenga o no, es en ese sentido que la calidad del software depende de quien la juzgue. El hecho de que una empresa tenga certificacin en calidad de software no garantiza que su software sea de calidad.