1_1 Introduccion

ARQUITECTURA DEL SOFTWARE

UNIVERSIDAD TECNICA DEL NORTE

FACULTAD DE INGENIERIA EN CIENCIAS APLICADAS

CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES

Ing. Pablo Landeta López

INTRODUCCION Y DEFINICIONES


Cómo desarrollamos sistemas?

• Se detecta la necesidad de iniciar un proyecto.- Varias restricciones son originadas en esta fase

• Se reúnen los requerimientos del usuario .- El centro de atención es la Funcionalidad.

• Se planea el proyecto.- Repartiendo la funcionalidad deseada el el tiempo y presupuesto disponibles.

• Se diseña la aplicación.- De acuerdo a la especificación técnica de los requerimientos funcionales

• Se desarrolla y se prueba el software.- La prioridad es cubrir la funcionalidad acordada.

• Se libera y se pone en operación al nuevo sistema.- Todos conocen por fin el nuevo sistema y..



Resultados típicos:

• Los usuarios: Sienten lento el sistema, lo encuentran difícil de usar, experimentan interrupciones en el servicio.

• Los operadores: Tienen dificultad para ponerlo en ejecución y para diagnosticar y detectar fallos. Se dan cuenta de que no soporta la carga real.

• Los programadores: Se encuentran con problemas al agregar nueva funcionalidad.

• El área de pruebas: encuentra un sistema difícil de probar

• Los gerentes y áreas de negocio: No sienten que el sistema esté obteniendo resultados con la eficiencia esperada.

• Los promotores: No sienten que el sistema se atractivo, encuentran rechazo por parte de los usuarios / clientes.

• Los directivos: No sienten que la inversión haya dado los resultados que esperaban.



Significado:

El sistema no tiene la calidad esperada

La razón:• Nunca se pudo atención en la calidad del sistema en las fases de

desarrollo.

• Muchas veces las expectativas de calidad no eran ni siquiera conocidas al comenzar el desarrollo.



La culpa?

El negocio dice: Esto es responsabilidad de sistemas … y con muchas razón

Sistemas dice: Nada de esto venía en los requerimientos!! … y también con mucha razón.



Problemas:

• Relacionados con requerimientos no funcionales: rendimiento, disponibilidad, confiabilidad, etc.

• No se puede identificar al responsable (culpable)

• No son defectos de programación, sino malas decisiones: protocolos, seguridad, escalabilidad, rendimiento, etc.

• Existe un brecha natural de comunicación entre las áreas de negocio y los desarrolladores.

• Hay decisiones que ninguno de ellos puede tomar de manera independiente.

Origen del problema:



Necesidad:

• Darle a la calidad del software la misma importancia que a la funcionalidad

• El análisis y diseño basados únicamente en la funcionalidad no nos permiten expresar correctamente las necesidades de calidad del software

Análisis y diseño tienen distinto enfoque:

Análisis de los requerimientos

Diseño del software

Contexto del problema

Contexto de la solución



Solución:

• La disciplina de la Arquitectura del software

• Funciona como enlace entre el Análisis y Diseño.

Contexto del problema

Contexto de la solución

• Introduce al proceso de desarrollo la atención hacia la calidad del software.

Análisis de requerimientos

Diseño de software

Arquitecturade software



Por qué la Arquitectura?:

• Analogía: Arquitectos, ingenieros, y constructores. Diversos perfiles, pero complementarios

• La Arquitectura de Software no es sobre objetos o páginas o pantallas o algoritmos.

• La Arquitectura de Software no es sobre como construir software, sino que software construir (o reutilizar o comprar).



Arquitectura en una construcción es una estructura física. Pero tenemos muchos atributos (forma en que se adapta al ambiente y se integra a otros edificios, el grado en que cumple su propósito y satisface al propietario, la estética, el efecto visual interno y externo). También son las miles de decisiones (grandes y pequeñas). Algunas se toman en la etapa inicial del diseño y tienen efecto en las demás acciones. Otras se toman más adelante

Es importante porque no es posible construir una casa sin un plano. Tampoco se empieza los planos con el dibujo de la plomería. Antes de los detalles es necesario tener un panorama general. Eso hace el diseño arquitectónico: da el panorama y asegura que sea el correcto.



En el Software Engineering Institute se agrupan muchas definicioneshttp://www.sei.cmu.edu/architecture/definitions.html

- lugar en el ciclo de vida - configuración o topología estática - vista del sistema con sus componentes principales - estructura global de control: protocolos, sincronización,

funcionalidad a elementos de diseño, distribución física, escalabilidad, performance.

- puente entre requerimiento y código

Ingeniería del software IEEE 610.12.1990: La aplicación de una estrategia sistemática, disciplinada y

cuantificable al desarrollo, aplicación y mantenimiento del software; esto es, la aplicación de la ingeniería al software.

Definición oficial: IEEE Std 1471-2000 La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución.



Al hablar de componentes de software puede ser un módulo de programa, una clase orientada a objetos, puede incluir bases de datos y middleware, etc.

Las propiedades de los componentes son las características necesarias para entender comp interactuan unos componentes con otros.

Las relaciones entre componentes pueden ser una invocación de procedimientos de un módulo a otro o protocolos de acceso a base de datos.

La arquitectura permite:

Analizar la efectividad del diseño pra cumplir los requerimientos establecidos

Considerar alternativas arquitectonicas en un etapa en la que hacer cambios de diseño es todavía relativamente fácil

Reducir los riesgos asociados en la construcción de software



La diferencia entre AS e IS: la noción clave de la AS es la organización (un concepto cualitativo o estructural), mientras que la IS tiene fundamentalmente que ver con una sistematicidad susceptible de cuantificarse.

El énfasis de la solución del ingeniero de software se encuentra en los aspectos técnicos. La del arquitecto en el contexto del negocio.La razón principal de la Arquitectura de Software reside en el que el análisis y diseño no son suficientes para resolver el problema. En la mayoría de los sistemas empresariales es muy importante tomar en cuenta los requerimientos no funcionales conocidos también como Atributos de Calidad.



Beneficios de la arquitectura del software:

• Aumenta la predictibilidad de la calidad del producto final• Abre la oportunidad de detectar riesgos en una fase temprana del

ciclo de desarrollo.• Las representaciones de la arquitectura del software fomentan una

comunicación eficiente y oportuna entre interesados y desarrolladores.

• La arquitectura resalta las primeras decisiones que tendrán un efecto profundo en todo el trabajo de ingeniería de software siguiente y en el éxito del sistema

• La arquitectura se constituye en un modelo pequeño y asequible sobre como esta estructurado el sistema.



Como se logra todo esto?

• Al reconocer que no es suficiente con identificar los requerimientos funcionales sino que también hay otras influencias que determinan el éxito de un sistema. La arquitectura las identifica y trabaja con ellas

• El diseño de la arquitectura comienza con el diseño de los datos y continua con la obtención de una o más representaciones de la estructura arquitectónica del sistema.

• Se analizan alternativas de estilos o patrones arquitectónicos para llegar a la estructura más adecuada para los requerimientos del usuario y para los atributos de calidad.• Seleccionada la alternativa se elabora la arquitectura usando un método de diseño.

• Se crea un modelo de la arquitectura que incluye la arquitectura de los datos y la estructura del programa. Se describen las relaciones entre componentes.



Influencias de la Arquitectura del software:

• Los Involucrados o interesados en el sistema (stakeholders)• La organización misma• El ambiente tecnológico• La experiencia de los arquitectos• El contexto gubernamental y legal

Influencia: Stakeholders

• La gente que ideó el proyecto• La que la va a financiar• La que la va a usar• La que recibirá los beneficios• La que lo va a diseñar• La que lo va a desarrollar• La que lo va a probar• La que lo va a operar• La que lo va a promocionar• La que lo va a dar soporte

técnico.



Influencia: la organización:

• Procesos y políticas del negocio• Infraestructura tecnológica• Tiempos y presupuestos• Recursos humanos y materiales• Nivel de experiencia del equipo de

desarrollo

Influencia: el ambiente tecnológico:• Tecnologías de moda• Hardware disponible• Patrones arquitectónicos• Disponibilidad de productos de

terceros• Tendencias de la industria• Expertos y consultores• Servicios de outsourcing existentes

Influencia: experiencia de arquitectos:• Con todo constante, dos

arquitectos trabajando por separado nunca diseñarían una arquitectura idéntica. Cada quien utilizaría las técnicas y herramientas que le han sido útiles en el pasado



Requerimientos funcionales: Lo que el sistema debe proveer. Estos definen que es lo que el usuario necesita y no el como lo hace. Es el conjunto de características y capacidades del programa.

Estos requerimientos se desprenden del Diagrama de Contexto del sistema a través de Procesos del negocio (persiste en el tiempo) y Casos de Uso (interacción particular del usuario)



Atributos de calidad (requerimientos no funcionales):

La funcionalidad puede ser la misma, pero las características de calidad no.

• Desempeño o rendimiento: Se mide con base a la velocidad de procesamiento, el tiempo de respuesta. El grado en que el sistema responde a un cierto evento es decir la eficiencia.

• Disponibilidad: grado de operabilidad del sistema. Recuperación en eventos.

• Seguridad: que no produce consecuencias fatales.

• Escalabilidad: propiedad de un sistema que indica su habilidad para reaccionar y adaptarse, o bien manejar el crecimiento continuo de trabajo de manera fluida, o para estar preparado para hacerse más grande sin perder calidad.



Atributos de calidad (requerimientos no funcionales):

• Usabilidad: que tan fácil es la operación del sistema, es decir se toma en cuenta factores humanos, la estética, la consistencia.

• Fiabilidad o Confiabilidad: Propiedad de un sistema tal que se puede confiar justificablemente en los servicios que este presta. Se evalúa con la medición de la frecuencia y gravedad de la fallas, exactitud de resultados, capacidad de recuperación.

• Mantenibilidad: la capacidad del programa para ser ampliable (extensibilidad), adaptable y servicial; además que pueda probarse, ser compatible y configurable.

No todo atributo de calidad de software se pondera por igual al diseñarlo. Una aplicación tal vez aborde a lo funcional con énfasis en la seguridad. Otra quizá busque el rendimiento enfocándose en la velocidad de procesamiento.



Drivers de arquitectura: Son los escenarios (funcionales + atributos de calidad) críticos y significativos que nos permiten modelar, comunicar y evaluar la arquitectura: generalmente estos son los requerimientos más prioritarios de los stakeholders.



Calidad

La calidad es un concepto complejo y de facetas múltiples que puede describirse desde cinco puntos de vista:

o Punto de vista trascendental: La calidad es algo que se reconoce de inmediato, pero que no es posible definir explícitamente.

o Punto de vista del usuario: concibe la calidad en términos de sus metas específicas

o Punto de vista del fabricante: la define en términos de las especificaciones originales del producto. Si las cumple tiene calidad.

o Punto de vista del producto: la calidad tiene que ver con las características inherentes (funciones y características) de un producto.

o Punto de vista del valor: Mide de acuerdo con lo que un cliente esta dispuesto a pagar por un producto.



Calidad

En el desarrollo de software la calidad del diseño incluye el grado en que el diseño cumple las funciones y características especificadas en el modelo de requerimientos. La calidad de la conformidad se centra en el grado en el que la implementación se apega al diseño y en el que el sistema resultante cumple sus metas de requerimientos y desempeño.

Se puede plantear una relación más intuitiva:Satisfacción del usuario = producto que funciona + buena calidad + entrega dentro del presupuesto y plazo

Si el usuario esta satisfecho nada más importa, es decir este punto de vista de la calidad afirma que si un producto de software beneficia mucho a los usuarios finales, estos podrían estar dispuestos a tolerar problemas ocasionales de confiabilidad y desempeño.



Calidad

Se puede definir a la calidad del software como un proceso eficaz que se aplica de manera que crea un producto útil que proporciona valor medible a quienes lo producen y a quienes lo utilizan.

Proceso eficaz: administración del proceso, prácticas de ingeniería del software, la administración del cambio y revisiones técnicas.

Producto útil: funciones y características de forma confiable y sin errores. Satisface los requerimientos establecidos

Agregar valor: la organización que elabora el software obtiene valor agregado porque el software de calidad requiere menos esfuerzo de mantenimiento, menos errores que corregir, menos asistencia. Para el usuario final significa mayores utilidades, más rentabilidad y mejor disponibilidad.



Factores de la Calidad ISO 9126

Este estandar se desarrollo con la intención de identificar los atributos clave del software. Identifica 6 atributos clave de calidad:

Funcionalidad: grado en que el software satisface las necesidades planteadas

Confiabilidad: Cantidad de tiempo que el software se encuentra disponible.

Usabilidad: Grado en que el software es fácil de usar

Eficiencia: Grado en que el software emplea óptimamente los recursos

Facilidad de mantenimiento: facilidad con la que pueden realizarse reparaciones al software (analizable, cambiable, estable, fácil para pruebas)

Portabilidad: Facilidad con la que un software puede llevarse de un ambiente a otro (adaptable, instalable, conformidad y sustituible)



Ejemplo: Factores de la Calidad que se persiguen en la interfaz

Para hacer una evaluación se necesita determinar atributos específicos y medibles de la interfaz:

Intuitiva: Grado en que la interfaz sigue patrones de uso esperados, de modo que hasta un novato lo pueda usar sin mucha capacitación.

Eficiencia: Grado en que es posible localizar o iniciar las operaciones y la información.

Robustez: Grado en que el software maneja entradas erróneas de datos o en el que se presenta interacción inapropiada por parte del usuario

Riqueza: Grado en que la interfaz provee un conjunto abundante de características.



Dilema de la calidad del software

Si produce un software de mala calidad, usted pierde porque nadie lo querrá comprar.

Si dedica un esfuerzo infinito (tiempo y dinero) para generar un elemento perfecto de software, entonces tomará tanto tiempo terminarlo y será tan caro que de igual manera terminará fuera del negocio.

En cualquier caso habrá perdido la ventana del mercado, o habrá agotado sus recursos.

Las personas tratan de situarse en es punto medio donde el producto es suficientemente bueno para para no ser rechazado de inmediato, pero tampoco un objeto perfeccionista.



Software lo suficientemente bueno

Es aceptable producir software lo suficientemente bueno?.. La pregunta debe ser que sí, de hecho las principales compañías de software lo hacen a diario. Crean software con errores detectados y lo distribuyen a una gran población de usuarios finales. Reconocen que algunas funciones de la versión 1.0 tal vez no sean de la calidad más alta y planean hacer mejoras en la versión 2.0.

El software lo suficientemente bueno contiene las funciones y características de alta calidad que desean los usuarios, pero al mismo tiempo contiene errores conocidos. El vendedor espera que la mayoría de usuarios finales perdone los errores gracias que están muy contentos con la funcionalidad de la aplicación.



Software lo suficientemente bueno

Esto puede funcionar para ciertos dominios de aplicación y para algunas compañías grandes de software.

Pero en una compañía pequeña hay que tener cuidado. Al entregar un producto bueno (pero defectuoso) corre el riesgo de causar un daño permanente re reputación a su compañía. Tal vez no llegue a entregar una versión 2.0 porque la empresa se puede derrumbar antes de lograrlo.

En casos como software automotriz o de telecomunicaciones, entregar software con errores conocidos se convierte en una negligencia y puede crear litigios legales o incluso puede ser un delito.



Costo de la calidad

No hay dudad que la calidad tiene un costo, pero la mala calidad también lo tiene.

El costo de la calidad puede dividirse en los costos asociados con la prevención, la evaluación y la falla.• Prevención: costo de actividades de administración para planear y

coordinar las actividades de control, costo de actividades técnicas agregadas para desarrollar modelos completos de los requerimientos y del diseño, costos de capacitación

• Evaluación: costo de efectuar revisiones técnicas, costo de recopilar datos y unidades de medida, costo de hacer pruebas y depurar

• De falla: costo por repeticiones, costos por efectos colaterales, costo de unidades de medida de calidad, costos por solución de quejas, devoluciones, sustitución de productos, garantía.



Riesgos de la mala calidad

Lo perjudicial de la aplicaciones mal diseñadas e implementadas no siempre se mide en dólares y tiempo.

Ejemplo: En noviembre del 2000, en un hospital de Panamá, 28 pacientes recibieron dosis masivas de rayos gama durante un tratamiento contra cáncer. Meses después 5 pacientes murieron por envenenamiento radiactivo 15 quedaron con complicaciones serias.

Que ocasionó la tragedia?: Un paquete de software desarrollado por una compañía estadounidense, que fue modificado por técnicos del hospital para calcular la dosis de radiación para cada paciente.Los tres médicos panameños que modificaron el software fueron acusados de asesinato en segundo grado. La empresa desarrolladora enfrentó litigios legales en dos países.



Calidad y seguridad

El software que no tiene calidad es fácil de penetrar por parte de intrusos, en consecuencia el software de mala calidad aumenta indirectamente el riesgo de seguridad con los costos y problemas que conlleva.

Para construir un sistema seguro hay que centrarse en la calidad, y eso debe comenzar durante el diseño.

Al eliminar las fallas de arquitectura (con lo que mejora la calidad del software) será más difícil que intrusos penetren en el software.



Lograr la calidad del software

La calidad del software no solo se ve, es el resultado de una buena administración del proyecto y de una correcta práctica de ingeniería de software. Se pueden considerar 4 actividades para lograr una alta calidad.

Métodos de la arquitectura del software: Se debe entender el problema que se quiere resolver. Para esto se debe lograr un buen diseño que esté de acuerdo con el problema.

Técnicas de administración de proyectos: usar estimaciones para verificar que las fechas pueden cumplirse, la planeación del riesgo es fundamental.

Control de calidad: revisión de modelos para garantizar consistencia, inspeccionar el código para descubrir y corregir errores antes de las pruebas, etc.

Aseguramiento de la calidad: funciones de auditoría y reportes para evaluar la eficacia de las acciones de control de calidad.



En conclusión la AS es:- Vista estructural de alto nivel- Define estilo o combinación de estilos para una solución- Se concentra en requerimientos no funcionales (los funcionales

requieren modelado y diseño de la aplicación)- Escencial para el éxito o fracaso de un proyecto

Lo hace: Un Ingeniero de software puede diseñar tanto los datos como la arquitectura pero en sistemas grandes y complejos es necesario un especialista. El Arquitecto del software selecciona un estilo arquitectónico a partir de los requerimientos obtenidos durante el análisis de los datos

Se ocupa de:- Diseño preliminar de alto nivel y su efectividad- Organización a alto nivel del sistema: descrición y análisis de

propiedades, de estructura y control global, protocolos de comunicación y sincronización, distribución física, componentes, etc.

- Aspectos del desarrollo, evolución y adaptación: composición, reutilización, escalabilidad, mantenimiento.

1_1 Introduccion

Education

Transcript of 1_1 Introduccion