unidad iii: arquitectura de sistemas · especificación u otro documento formal c) una condición o...

Unidad III:Arquitectura de Sistemas

Milton J. NarváezUniversidad Don Bosco

11 de Septiembre de 2014

SaludoAvisos generalesUNIDAD III: ARQUITECTURA DE SISTEMASIntroducción3.1. Sistemas de uso intensivo de datos3.2. Sistemas distribuidos y de tiempo real

AGENDAAGENDA

3.3. Objetos distribuidos3.4. Arquitectura de sistemas distribuidos3.5. Requerimientos del software3.6. Modelado del análisis3.7. Diseño de software3.8. Verificación y validación3.9. Estrategias de prueba del software

De acuerdo al procesamiento de los datos los sistemas pueden clasificarse en tres categorías a saber:

INTRODUCCIONINTRODUCCION

Clasificación Descripción Ejemplo

Sistemas personales

•Son no distribuidos.•Están diseñados para ejecutarse sobre computadoras personales o

•Procesadores de texto.•Hojas de cálculo.•Sistemas gráficos.personales sobre computadoras personales o

estaciones de trabajo.•Sistemas gráficos.•Otros.

Sistemas incrustados

•Se ejecutan sobre un único procesador o sobre un grupo integrado de procesadores.

•Sistemas de control para aparatos domésticos.•Sistema de administración de instrumentos.

Sistemas distribuidos

•El software del sistema se ejecuta sobre un grupo poco integrado de procesadores cooperativos vinculados a una red.

•Sistemas bancarios ATM.•Sistemas de reservaciones.•Sistemas groupware.•Otros.

Contexto general de trabajoContexto general de trabajo

• Requerimientos del software• Modelado del análisisAnálisis

• Diseño del software (modelado)• Estructura y Arquitectura del SoftwareDiseño

• Fundamento de desarrollo• Gestión de la construcción

Desarrollo (Construcción)

• Verificación y validación• Estrategias de pruebas del softwareImplementación

• Mantenimiento fundamental• Procesos de mantenimiento• Técnicas de mantenimiento

Mantenimiento

Requerimientos del softwareRequerimientos del softwareDefinición de requerimientosDefinición de requerimientos

a) Una condición o necesidad de un usuario para resolver un problema oalcanzar un objetivo

b) Una condición o capacidad que debe estar presente en un sistema ocomponentes de sistema para satisfacer un contrato, estándar,

FASE DE ANÁLISISFASE DE ANÁLISIS

componentes de sistema para satisfacer un contrato, estándar,especificación u otro documento formal

c) Una condición o capacidad que el sistema debe cumplir.

Requerimientos del softwareRequerimientos del softwareDefinición de requerimientosDefinición de requerimientosCaracterísticas de los requerimientosCaracterísticas de los requerimientos

Completo

• Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.


Consistente

• Un requerimiento es consistente si no es contradictorio con otro requerimiento.

No ambiguo

• Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.

Requerimientos del softwareRequerimientos del softwareDefinición de requerimientosDefinición de requerimientosCaracterísticas de los requerimientosCaracterísticas de los requerimientos

Necesario

• Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.


Conciso

• Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.

Verificable

• Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.

Requerimientos del softwareRequerimientos del softwareDefinición de requerimientosDefinición de requerimientos

Dificultades para definirlos

a) Los requerimientos no son obvios y vienen de muchas fuentes.b) Son difíciles de expresar en palabras (el lenguaje es ambiguo).c) Existen muchos tipos de requerimientos y diferentes niveles de detalle.d) La cantidad de requerimientos en un proyecto puede ser difícil de manejar.


d) La cantidad de requerimientos en un proyecto puede ser difícil de manejar.e) Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes

o más estables que otros.f) Los requerimientos están relacionados unos con otros, y a su vez se relacionan

con otras partes del proceso.g) Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales

específicas.h) Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.i) Son difíciles de cuantificar, ya que cada conjunto de requerimientos es

particular para cada proyecto.

Requerimientos del softwareRequerimientos del softwareTipos de requerimientosTipos de requerimientos

Funcionales (F)

Son las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.


transformaciones que el sistema realiza sobre las entradas para producir salidas.

Estos pueden incluir:a) Conjuntos de características b) Capacidades c) Seguridad

Requerimientos del softwareRequerimientos del softwareTipos de requerimientosTipos de requerimientos

No funcionales: Tienen que ver con características que de una u otra forma puedan limitar el sistema. Se categorizan en:

Usabilidad (Usability)•estética •consistencia en la interfaz de usuario


•consistencia en la interfaz de usuario •ayuda en línea y sensible al contexto •asistentes y agentes •documentación de usuario •materiales de capacitación

Requerimientos de interfaces•un elementos externo con el cual un sistema debe interactuar •restricciones en formatos, sincronización u otros factores usados por una interacción

Requerimientos físicos•material •forma •tamaño •peso

Requerimientos del softwareRequerimientos del softwareProcesos de la ingeniería de requerimientosProcesos de la ingeniería de requerimientos

Importancia de la ingeniería de requerimiento

a) Permite gestionar las necesidades del proyecto en forma estructurada.b) Mejora la capacidad de predecir cronogramas de proyectos, así como

sus resultados.


sus resultados.c) Disminuye los costos y retrasos del proyecto.d) Mejora la calidad del software.e) Mejora la comunicación entre equipos.f) Evita rechazos de usuarios finales.


•Es un enfoque para extraer, analizar, especificar y validar los requerimientos de unproyecto.•Es el proceso que establece y mantiene acuerdos sobre los cambios derequerimientos, entre los clientes y el equipo del proyecto•Es la disciplina para desarrollar una especificación completa, consistente y noambigua, la cual servirá como base para acuerdos comunes entre todas las partes


ambigua, la cual servirá como base para acuerdos comunes entre todas las partesinvolucradas y en dónde se describen las funciones que realizará el sistema.

Propósito•Establecer y mantener un acuerdo con los clientes y otros afectados acerca de lo queel sistema debería hacer.•Proveer a los desarrolladores un mejor entendimiento de los requerimientos delsistema.•Definir los límites (delimitar) del sistema.•Proveer una base para la planificación del contenido técnico de las iteraciones.•Definir una interfaz de usuario para aquellas funcionalidades del sistema que loameriten.


Roles que intervienen en la IRRoles que intervienen en la IR

Expertos del negocio

Analistas y Programadores


Ingeniería de RequerimientosIngeniería de Requerimientos(roles)(roles)

Usuario final Personal de prueba


Ingeniería deIngeniería deRequerimientosRequerimientos

Analizar el problema


Entender las necesidades

Definir el sistema

Administrar el alcance del sistema

Refinar la definición del sistema

Administrar requerimientos

cambiantes

Pun

tos

de c

hequ

eo



•Capturar un vocabulario común•Desarrollar el plan de administración de requerimientos•Encontrar actores y casos de uso (solo actores)•Desarrollar la visión




Definir el sistema




cambiantes

Pun

tos

de c

hequ

eo



•Capturar un vocabulario común•Desarrollar la visión•Obtener peticiones de los afectados•Encontrar actores y casos de uso (casos de uso iniciales)•Administrar dependencias




Definir el sistema




cambiantes

Pun

tos

de c

hequ

eo

•Administrar dependencias



•Sincronizar al equipo del proyecto en su entendimiento del sistema. •Realizar un análisis de alto nivel de los resultados de la recolección de las peticiones de los afectados. •Refinar la Visión para incluir las características a incluir en el sistema,




Definir el sistema




cambiantes

Pun

tos

de c

hequ

eo

junto con los atributos apropiados. •Refinar el modelo de casos de uso para que incluya los casos de uso bosquejados. •Documentar con mayor formalidad los resultados en modelos y documentos.•Capturar un vocabulario común•Desarrollar la visión•Administrar dependencias•Encontrar actores y casos de uso (refinado)






Definir el sistema




cambiantes

Pun

tos

de c

hequ

eo •Priorizar los casos de uso•Desarrollar la visión•Administrar dependencias






Definir el sistema




cambiantes

Pun

tos

de c

hequ

eo •Detallar un caso de uso•Detallar los requerimientos de software•Construir un prototipo de la interfaz de usuario (para aquellos casos de uso que lo requieran)






Definir el sistema




cambiantes

Pun

tos

de c

hequ

eo

•Estructurar el modelo de casos de uso•Administrar dependencias•Revisar requerimientos


Puntos de chequeo



Pun

tos

de c

hequ

eo

Puntos de chequeo¿Están incluidas todas las funciones requeridas por el cliente? (completa ) ¿Existen conflictos en los requerimientos? (consistencia ) ¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua ) ¿Está cada requerimiento claramente representado? (entendible ) ¿Pueden los requerimientos ser implementados con la tecnología y el presupuesto disponible? (factible )¿Está la Especificación escrita en un lenguaje apropiado? (clara ) ¿Existe facilidad para hacer cambios en los requerimientos? (modificable ) ¿Está claramente definido el origen de cada requerimiento? (rastreable ) ¿Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable )

Requerimientos del softwareRequerimientos del softwareTécnicas de Levantamiento de RequerimientosTécnicas de Levantamiento de Requerimientos

Técnica Descripción

Casos de Uso

� Describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el punto devista del usuario.

� Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno.� Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la

implementación.� Comparación con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado.� Se emplean para reunir información proveniente de personas o de grupos� Consiste en una serie de preguntas relacionadas con varios aspectos de un sistema.


Entrevistas y Cuestionarios

� Consiste en una serie de preguntas relacionadas con varios aspectos de un sistema.� Es aplicada directamente por el analista

� Es deseable que se aplique presencialmente cuando es una entrevista� En caso de cuestionario lo ideal es enviarlo y poner fechas de cumplimiento para recibir la

información

Lluvia de ideas

� Aplazar el juicio y no realizar críticas, hasta que no agoten las ideas, ya que actuaría como uninhibidor.

� Cuantas más ideas se sugieren, mejores resultados se conseguirán: "la cantidad produce la calidad".� La producción de ideas en grupos puede ser más efectiva que la individual.� Las ideas de una persona, serán asociadas de manera distinta por cada miembro, y hará que

aparezcan otras por contacto.

Taller de requerimientos

� El taller de requerimientos provee un marco de trabajo que permite poner en práctica otras técnicas,tales como: lluvia de ideas, “storyboarding”, representación de roles, revisión de requerimientosexistentes

Consolidación de resultados

� Se efectúa luego de finalizar el taller� El facilitador (junto con los analistas del sistema) emplean algún tiempo extra para sintetizar los

hallazgos y organizar la información en un formato más presentable� Se documentan los requerimientos derivados en los documentos respectivos (de acuerdo con la

metodología y estándares que se estén utilizando)� Valide los requerimientos que estrago con el cliente.


Control de versiones

a) Prevenir cambios no autorizados.b) Guardar revisiones de los documentos de requerimientos.c) Recuperar versiones previas de los documentos.


c) Recuperar versiones previas de los documentos.d) Administrar una estrategia de “líneas base”e) Prevenir la modificación simultánea a los requerimientos.f) En vista que las peticiones de cambios provienen de muchas fuentes,

las mismas deben ser enrutadas en un solo proceso. Esto se hace conla finalidad de evitar problemas y conseguir estabilidad en losrequerimientos.


Control de versiones


Modelo de AnálisisModelo de AnálisisClases de modelos de la Ingeniería de SoftwareClases de modelos de la Ingeniería de Software

Modelo Descripción

Modelos de análisis

Representan los requisitos del cliente al presentar elsoftware en tres dominios diferentes: el dominio de la


Modelos de análisissoftware en tres dominios diferentes: el dominio de lainformación, el dominio funcional y el dominio delcomportamiento.

Modelo de diseño

Representan características del software que ayudan alos profesionales a construir de manera efectiva: laarquitectura, la interfaz del usuario y el detalle al nivel decomponentes.

Modelo de AnálisisModelo de AnálisisPrincipios del modelado del análisisPrincipios del modelado del análisisPrincipio Descripción

El principio de información de un problema debe representarse y entenderse.

El dominio de información lo forman los datos que fluyen hacia el sistema (a partir de losusuarios finales, otros sistemas o dispositivos externos), los datos que fluyen desde elsistema (a través de la interfaz del usuario, interfaces de red, reportes gráficos y otrosmedios) y los almacenamientos de datos que se recopilan y reorganizan los objetosconsistentes de información (es decir, los datos que se mantienen en forma permanente).

Se deben definir las funciones que ejecuta el software.

Las funciones del software proporcionan un beneficio directo a los usuarios finales ytambién aporta soporte interno a aquellas características visibles para el usuario.


Se debe representar el comportamiento del software (como una consecuencia de eventos externos).

Al comportamiento del software de computadora lo guía su interacción con el ambienteexterno. La entrada que proporcionan los usuarios finales, los datos de control queaportan un sistema externo o los datos de monitoreo que se recolectan a través de unared ocasionan que el software se comporte de una manera específica.

Los modelos que presentan información, función y comportamiento deben partirse de forma que descubran el detalle de una manera estratificada (o jerárquica).

El modelado del análisis es el primer paso en la resolución de problemas en la ingenieríade software. Esto permite al profesional entender mejor el problema y establecer una basepara la solución (diseño). Los problemas complejos son difíciles de resolver por completo.Por esta razón, se utiliza una estrategia de “divide y vencerás”. Un problema grande ycomplejo se divide en sub problemas hasta que cada sub problema es relativamente fácilde entender. Este concepto se llama partición y es una estrategia clave en el modeladodel análisis.

La tarea del análisis debe moverse de la información esencial hacia el detalle de implementación.

El modelado del análisis comienza con la descripción del problema desde la perspectivadel usuario final. La esencia del problema se describe sin ninguna consideración de laforma en que se implementará la solución.

Modelo de AnálisisModelo de AnálisisConjunto de tareas genéricas para el modelado del a nálisisConjunto de tareas genéricas para el modelado del a nálisis

•Revisar los requisitos del negocio, las características/necesidades del usuario, las salidas visibles para el usuario, las restricciones del negocio, y otros requisitos técnicos que se hayan determinado durante las actividades de comunicación con el cliente y de planeación.•Expandir y refinar los escenarios del usuario:

Definir a todos los actores.Representar la forma en que los actores interactúan con el software.


Representar la forma en que los actores interactúan con el software.Extraer funciones y características a partir de los escenarios del usuario.Revisar los escenarios del usuario para verificar que estén completos y su exactitud.

•Modelar el dominio de la información:Representar todos los objetos importantes de información.Definir los atributos para cada objeto de información.Representar las relaciones entre los objetos de información.

•Modelar el dominio funcional:Mostrar la forma en que las funciones modifican los objetos de datos.Refinar las funciones para proporcionar los detalles de la elaboración.Escribir una narración del procesamiento que describa cada función y sub función.Revisar los modelos funcionales.

Modelo de AnálisisModelo de AnálisisConjunto de tareas genéricas para el modelado del a nálisisConjunto de tareas genéricas para el modelado del a nálisis

•Modelar el dominio del comportamiento.Identificar los eventos externos que ocasionan cambios en el comportamiento dentro del sistema.Identificar los estados que representan cada forma de comportamiento observable desde el exterior.


desde el exterior.Presentar el modo en el que un evento lleva al sistema a combinar de un estado a otro.Revisar los modelos de comportamiento.

•Analizar y modelar la interface del usuario:Dirigir el análisis de tarea.Crear prototipos de la imagen en pantalla.

•Revisar todos los modelos en cuanto a que estén completos, su consistencia y las omisiones.

Modelo de AnálisisModelo de AnálisisElementos basados en escenariosElementos basados en escenarios

Análisis de los casos de usoEl objetivo de esta actividad, que sólo se realiza en el caso de Análisis Orientado a Objetos,es identificar las clases cuyos objetos son necesarios para realizar un caso de uso y describirsu comportamiento mediante la interacción de dichos objetos.


Modelo de AnálisisModelo de AnálisisElementos basados en clasesElementos basados en clases

Identificación de las clases asociadas a los casos de uso

En esta tarea se comienzan a identificar los objetos necesarios para realizar el caso de uso, basándose en laespecificación que tenemos del mismo.

A partir del estudio del caso de uso, se extrae una lista de objetos candidatos a ser clases. Es posible que,inicialmente, no se disponga de la información necesaria para identificar todas las clases, por lo que se hace


inicialmente, no se disponga de la información necesaria para identificar todas las clases, por lo que se haceuna primera aproximación que sé ira refinando posteriormente, durante esta actividad y en la fase deModelamiento de Tecnología. Además, algunos de los objetos representan mejor la información del sistemasi se les identifica como atributos en vez de como clases. Para poder diferenciarlas, es necesario estudiar elcomportamiento de esos objetos en el diagrama de interacción y además se debe tener en cuenta una seriede reglas, como puede ser el suprimir palabras no pertinentes, con significados vagos o sinónimos.

Las clases que se identifican en esta tarea pueden ser: - Clases de Entidad (representan la información manipulada en el caso de uso).- Clases de interface de Usuario (se utilizan para describir la interacción entre el sistema y sus actores, suelen representar abstracciones de ventanas, interfaces de comunicación, formularios, etc.).- Clases de Control (son responsables de la coordinación, secuencia de transacciones y control de los objetos relacionados con un caso de uso).

Modelo de AnálisisModelo de AnálisisElementos orientados a flujosElementos orientados a flujos

El modelado de datos orientado a flujo es una de las notaciones de análisis utilizadas con mayor amplitud en la actualidad.

El diagrama de flujo de datos (DFD) permite al ingeniero del software desarrollar los modelos del ámbito de información y del ámbito funcional al mismo tiempo.


Aunque el DFD y los diagramas de información relacionados no son una parte formal de UML, pueden utilizarse para complementar los diagramas de UML y proporcionar un conocimiento adicional de los requisitos y el flujo del sistema.

DFD de nivel contextual para HogarSeguro.


Ahora tenemos que expandir el DFD de nivel 0 o de nivel a un modelo de nivel 1.


DFD de nivel 1 para HogarSeguro.


Se debe tener en cuenta que entre los niveles 0 y 1 se ha mantenido la continuidad del flujo de información.


DFD de nivel 2 que refina el proceso monitorizar sensores

Modelo de AnálisisModelo de AnálisisElementos de comportamientoElementos de comportamiento

Diagrama de Estado


Diagrama de estado para la función de seguridad de HogarSeguro.


Diagramas de secuencia


Ejemplo de un Diagrama de secuencia.


Herramientas de software para el modelado del análisis generalizado en UML

Herramienta Desarrollador

ArgoUML Argouml.tigris.org


Power Designer www.sybase.com

Rational Rose www.rational.com

UML Studio www.pragsoft.com

Visio www.microsoft.com

Diseño del softwareDiseño del softwareConceptos de diseñoConceptos de diseño

a) Abstracciónb) Refinamientoc) Modularidad

FASE DE DISEÑOFASE DE DISEÑO

c) Modularidadd) Arquitectura de softwaree) Jerarquía de controlf) División estructuralg) Estructura de datosh) Ocultación de informacióni) Procedimiento de software

Nos ocuparemos de la representación de la información, su persistencia, larecepción y transmisión de los datos, y los medios que nos sirven paratransmitirla y comunicarla.

Entenderemos arquitectura como la estructura que tienen el conjunto decomponentes que forman un sistema, así como la relación entre los

Sistemas de uso intensivo de datosSistemas de uso intensivo de datos


componentes que forman un sistema, así como la relación entre losmismos. Es decir una visión estructural de alto nivel (pocos detalles) delsistema.

La ArquitecturaArquitectura deldel SoftwareSoftware es el diseño de más alto nivel de laestructura de un sistema.

Una Arquitectura de Software, también denominada Arquitectura lógica,consiste en un conjunto de patrones y abstracciones coherentes queproporcionan el marco de referencia necesario para guiar la construccióndel software para un sistema de información.

La arquitectura de software, tiene que ver con el diseño y laimplementación de estructuras de software de alto nivel. Es el resultado deensamblar un cierto número de elementos arquitectónicos de formaadecuada para satisfacer la mayor funcionalidad y requerimientos dedesempeño de un sistema, así como requerimientos no funcionales, comola confiabilidad, escalabilidad, portabilidad, y disponibilidad (Kruchten,



la confiabilidad, escalabilidad, portabilidad, y disponibilidad (Kruchten,Philippe).

Arquitectura de sistemas distribuidosArquitectura de sistemas distribuidosCaracterísticas de los sistemas distribuidos Características de los sistemas distribuidos

• Un sistema distribuido permite compartir los recursos de hardware y software como los discos, impresoras, archivos, compiladores, entro otros, asociados a diversas computadores de una red.

Compartición de recursos


• La apertura de un sistema es el grado al cual se puede extender agregándole nuevos recursos no propietarios. Los sistemas distribuidos son sistemas abiertos que normalmente incluyen hardware y software de diferentes compañías.

Apertura

• En un sistema distribuido, varios procesos operan al mismo tiempo en diferentes computadoras de la red. Estos procesos pueden (aunque no es necesario) comunicarse con otros durante su operación normal.

Concurrencia

Arquitectura de sistemas distribuidosArquitectura de sistemas distribuidosCaracterísticas de los sistemas distribuidos Características de los sistemas distribuidos

• Al menos en principio, los sistemas distribuidos son escalables en el sentido de que las capacidades del sistema se pueden incrementar agregando nuevos recursos para cubrir las nuevas demandas de dichos sistemas.

Escalabilidad


• La disponibilidad de varias computadoras y el potencial para replicar significa que los sistemas distribuidos pueden tolerar algunas fallas de hardware y software.

Tolerancia a fallas

• La transparencia es esconder al usuario la naturaleza distribuida del sistema. Una meta del diseño del sistema es que los usuarios tengan acceso transparente a los recursos y no tengan necesidad de conocer algo sobre la distribución del sistema.

Transparencia

Arquitectura de sistemas distribuidosArquitectura de sistemas distribuidosDesventajas de los sistemas distribuidos Desventajas de los sistemas distribuidos

• Son más complejos que los centralizados. Esto hace más difícil comprender las propiedades emergentes y probar estos sistemas.Complejidad

• El sistema se puede acceder desde varias computadoras diferentes


• El sistema se puede acceder desde varias computadoras diferentes y el tráfico sobre la red debe estar sujeto a inspecciones. Esto hace más difícil administrar la seguridad en un sistema distribuido.

Seguridad

• Las diversas computadoras de un sistema pueden ser de diferentes tipos o ejecutar diferentes versiones del sistema operativo. Las fallas en una máquina se pueden propagar a otras máquinas con consecuencias inesperadas. Esto significa que se requiere más esfuerzo para administrar y mantener en operación al sistema.

Manejabilidad

• Como es conocido por todos los usuarios de Web, los sistemas distribuidos son impredecibles en su respuesta. Ésta depende de la carga total del sistema, de su organización y de la carga de la red. Puesto que todo esto cambia con mucha rapidez, el tiempo que se lleva responder a una petición del usuario cambia dramáticamente de una petición a otra.

Impredecibilidad

Arquitectura de sistemas distribuidosArquitectura de sistemas distribuidosModelo de arquitectura de sistemas distribuidosModelo de arquitectura de sistemas distribuidosArquitecturas multiprocesador Arquitecturas multiprocesador


Arquitectura de sistemas distribuidosArquitectura de sistemas distribuidosModelo de arquitectura de sistemas distribuidosModelo de arquitectura de sistemas distribuidosArquitecturas clienteArquitecturas cliente--servidorservidor


Arquitectura de sistemas distribuidosArquitectura de sistemas distribuidosModelo de arquitectura de sistemas distribuidosModelo de arquitectura de sistemas distribuidosArquitecturas de objetos distribuidosArquitecturas de objetos distribuidos


Diseño del softwareDiseño del softwareDiseño y calidad del softwareDiseño y calidad del software

Características que sirven como guía para la evaluación de u n buendiseño

a) El diseño deberá implementar todos los requisitos explícitos delmodelo de análisis, y deberán ajustarse a todos los requisitos


modelo de análisis, y deberán ajustarse a todos los requisitosimplícitos que desea el cliente;

b) El diseño deberá ser una guía legible y comprensible para aquellosque generan código y para aquellos que comprueban yconsecuentemente, dan soporte al software;

c) El diseño deberá proporcionar una imagen completa del software,enfrentándose a los dominios de comportamiento, funcionales y dedatos desde una perspectiva de implementación.

Diseño del softwareDiseño del softwareDiseño y calidad del softwareDiseño y calidad del software

Calidad del Calidad del softwaresoftware

Principios básicosTecnológico (técnicas)

Administrativo (funciones)Ergonómico (interfaz)

Adopción de políticas


Evaluación o controlIndicadores

Criterios de mediciónMétricas de calidad

Procesos de controlDefinir el software que va a ser controladoSeleccionar una medida que pueda ser aplicada al objeto de controlCrear o determinar los métodos de valoración de los indicadoresDefinir las regulaciones organizativas para realizar el control

Criterios de calidad1. Factores de Calidad2. Métricas de Calidad

Diseño del softwareDiseño del softwareDiseño y calidad del softwareDiseño y calidad del softwareFactores de calidadFactores de calidad

Características operacionalesCaracterísticas operacionales

Característica Descripción

Es el grado en que un programa satisface sus especificaciones y


CorrecciónEs el grado en que un programa satisface sus especificaciones y consigue los objetivos pedidos por el cliente. Este factor tiene una pregunta asociada: ¿Hace lo que quiero?

ConfiabilidadEs el grado en que se puede esperar que un programa lleve a cabo sus funciones esperadas con la precisión requerida. La pregunta asociada a este factor sería: ¿Lo hace de forma fiable todo el tiempo?

EficienciaLa cantidad de recursos de computadoras y de código requeridos por un programa para llevar a cabo sus funciones. La pregunta asociada a este factor sería: ¿Se ejecutará en mi hardware lo mejor que pueda?


Capacidad de soportar cambiosCapacidad de soportar cambios

Concepto Descripción

Facilidad de MantenimientoEs el esfuerzo requerido para localizar y arreglar un error en un programa. La pregunta asociada a este factor sería:


Facilidad de Mantenimiento un programa. La pregunta asociada a este factor sería: ¿Puedo corregirlo?

FlexibilidadEs el esfuerzo requerido para modificar un programa operativo. La pregunta asociada a este factor sería: ¿Puedo cambiarlo?

Facilidad de PruebaEs el esfuerzo requerido para probar un programa de forma que se asegure que realiza su función requerida. La pregunta asociada a este factor sería: ¿Puedo probarlo?


Adaptabilidad de nuevos entornosAdaptabilidad de nuevos entornos

Concepto Descripción


PortabilidadEs el esfuerzo requerido para transferir el programa desde un hardware y/o un entorno de sistema de software a otro. Este factor tiene una pregunta asociada: ¿Podré usarlo en otra máquina?

ReusabilidadEs el grado en que un programa (o partes de este) se pueden reusar en otras aplicaciones. Este factor tiene una pregunta asociada: ¿Podré reusar alguna parte del software?

Facilidad de Interoperación

Es el esfuerzo requerido para acoplar un sistema a otro. Este factor tiene una pregunta asociada: ¿Podré hacerlo interactuar con otro sistema?

Diseño del softwareDiseño del softwareDiseño y calidad del softwareDiseño y calidad del softwareMétricas de calidadMétricas de calidad


Diseño del softwareDiseño del softwareDiseño y calidad del softwareDiseño y calidad del softwarePlanificación y estándares de la garantía de calida d de softwarePlanificación y estándares de la garantía de calida d de software

Tareas que se deben llevar a cabo en un plan de gestión de la calidad del software:a) Revisión del diseño del sistema.b) Revisión de requerimientos de software.


b) Revisión de requerimientos de software.c) Revisión del diseño preliminar.d) Revisión del diseño detallado (a nivel módulos).e) Revisión del plan de prueba de integración.f) Revisión del código.g) Revisión de los procedimientos.h) Auditorías de los estándares de documentación.i) Auditorías del control de configuración.j) Auditorías de prueba.k) Recolección, evaluación y análisis de los datos de defectos.l) Certificación de herramientas.m) Mantenimiento de registros

Verificación y validaciónVerificación y validación

Con la verificación y validación del software persigue encontrar los fallos y asumirla existencia de errores. No se trata de corroborar que todo está bien, sino deencontrar los errores, pese a que dichas actividades no son muy atractivas derealizar. El éxito en estas actividades es encontrar los errores.

ProcesoProceso dede verificaciónverificación deldel softwaresoftware

FASE DE IMPLEMENTACIÓNFASE DE IMPLEMENTACIÓN

ProcesoProceso dede verificaciónverificación deldel softwaresoftware

Es el proceso de determinar si los productos resultantes de una fase del Ciclo deVida del Software (CVS) cumplen los requisitos establecidos en la fase anterior. Elproducto resultante es completo, consistente y correcto para comenzar la siguientefase.

Verificación y validaciónVerificación y validaciónProceso de verificación del softwareProceso de verificación del software


Verificación y validaciónVerificación y validaciónProceso de validación del softwareProceso de validación del software

Es el proceso de prueba del software para asegurar que cumple su especificación.Este proceso asegura que el software fabricado se comporta como se espera y deacuerdo a las expectativas del cliente. El desarrollador quiere demostrar que elsoftware funciona.


Verificación y validaciónVerificación y validaciónProceso de validación del softwareProceso de validación del softwareProceso de verificación y validación independienteProceso de verificación y validación independiente


Verificación y validaciónVerificación y validaciónEstándares y normas en los proceso de verificación y validaciónEstándares y normas en los proceso de verificación y validación

Estándar ISO/IEC 15504 Norma IEEE 1012

El estándar ISO/IEC 15504 establece unmarco para métodos de evaluación y mejorade los procesos de desarrollo y mantenimientode sistemas y productos de software.

El IEEE 1012-2004 es un proceso estándarque define la Verificación y validación deprocesos en términos de actividadesespecíficas y tareas afines. La norma define


de sistemas y productos de software.Comprende la evaluación de procesos, mejorade procesos y determinación de capacidad.

El estándar ISO/IEC 15504 está alineado conel estándar ISO/IEC 12207 que define losprocesos del ciclo de vida del desarrollo,mantenimiento y operación de los sistemas desoftware y presenta equivalencia ycompatibilidad con CMMI (Capability MaturityModel Integration – Modelo de Integración dela Capacidad de Madurez).

específicas y tareas afines. La norma definetambién el contenido del plan de Verificación yvalidación del software, incluyendo un ejemploy sus formatos.

La Norma IEEE 1012 se aplica a todas lasaplicaciones de software. Al realizar laVerificación y validación del software esimportante examinar las interacciones queeste tiene con el sistema. La Verificación yvalidación del software determina la correcciónde software y otros atributos (por ejemplo,integridad, exactitud, la coherencia ycomprobabilidad).

Estrategias de prueba del softwareEstrategias de prueba del software

La prueba del software es un elemento crítico para la garantía de lacalidad del software. El objetivo de la etapa de pruebas es garantizar lacalidad del producto desarrollado.

Además, esta etapa implica:


Además, esta etapa implica:a) Verificar la interacción de componentes.b) Verificar la integración adecuada de los componentes.c) Verificar que todos los requisitos se han implementado correctamente.d) Identificar y asegurar que los defectos encontrados se han corregido

antes de entregar el software al cliente.e) Diseñar pruebas que sistemáticamente saquen a la luz diferentes

clases de errores, haciéndolo con la menor cantidad de tiempo yesfuerzo.

Estrategias de prueba del softwareEstrategias de prueba del software

La prueba no es una actividad sencilla, no es una etapa del proyecto enla cual se asegura la calidad, sino que la prueba debe ocurrir durantetodo el ciclo de vida: podemos probar la funcionalidad de los primerosprototipos; probar la estabilidad, cobertura y rendimiento de laarquitectura; probar el producto final, etc. Lo que conduce al principal


arquitectura; probar el producto final, etc. Lo que conduce al principalbeneficio de la prueba: proporcionar feedback mientras hay todavíatiempo y recursos para hacer algo.

Cualquier proceso de ingeniería puede ser probado de una de dosformas:a) Se pueden llevar a cabo pruebas que demuestren que cada función es

completamente operativa (prueba de caja negra).b) Se pueden desarrollar pruebas que aseguren que la operación interna

se ajusta a las especificaciones y que todos los componentes internosse han comprobado de forma adecuada (prueba de caja blanca).

Estrategias de prueba del softwareEstrategias de prueba del softwareTipos de pruebasTipos de pruebas

Prueba Descripción

Pruebas de unidad La prueba de unidad se centra en el módulo (técnicas de prueba de cajablanca).

Prueba de integración El objetivo es coger los módulos probados en la prueba de unidad y construiruna estructura de programa que esté de acuerdo con lo que dicta el diseño.


Prueba del sistema Verifica que cada elemento encaja de forma adecuada y que se alcanza lafuncionalidad y el rendimiento del sistema total.Prueba de validaciónPrueba de recuperaciónPrueba de seguridadPrueba de resistenciaPrueba de rendimientoPrueba de instalación

Pruebas de regresión Las pruebas de regresión son una estrategia de prueba en la cual laspruebas que se han ejecutado anteriormente se vuelven a realizar en lanueva versión modificada, para asegurar la calidad después de añadir lanueva funcionalidad.

Estrategias de prueba del softwareEstrategias de prueba del softwareEstrategias de pruebas del softwareEstrategias de pruebas del software

Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba enuna serie de pasos bien planificados que llevan a la construcción correcta del software.

Etapas de pruebas Productos de pruebas

Planificación de las pruebas.Diseño de las pruebas.

Plan de Pruebas.Casos de Prueba.


Diseño de las pruebas.Implementación de las pruebas.Ejecución de las pruebas.Evaluación de las pruebas.

Casos de Prueba.Informe de evaluación de Pruebas.Modelo de Pruebas, que incluye Clases de Prueba, Entorno de Configuración de Pruebas, Componentes de Prueba y los Datos de prueba.

“La historia ha demostrado que las personas son “La historia ha demostrado que las personas son “La historia ha demostrado que las personas son “La historia ha demostrado que las personas son exitosas no porque son brillantes, sino por su exitosas no porque son brillantes, sino por su

persistencia y deseo”.persistencia y deseo”.John C. Maxwell, “Prepara tu mañana de éxito”.John C. Maxwell, “Prepara tu mañana de éxito”.

Milton J. NarváezUniversidad Don Bosco

11 de Septiembre de 2014

unidad iii: arquitectura de sistemas · especificación u otro documento formal c) una condición o...

Documents