Investigaciones y fuentes para : modelo de implementacion.pptx

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado.

Un diagrama de componentes representa cmo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes fsicos incluyen archivos, cabeceras, bibliotecas compartidas, mdulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.

Debido a que los diagramas de componentes son ms parecidos a los diagramas de casos de usos, stos son utilizados para modelar la vista esttica y dinmica de un sistema. Muestra la organizacin y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.

En l se situarn libreras, tablas, archivos, ejecutables y documentos que formen parte del sistema.

Uno de los usos principales es que puede servir para ver qu componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

Diagrama de despliegueElDiagrama de Desplieguees un tipo de diagrama delLenguaje Unificado de Modeladoque se utiliza para modelar la disposicin fsica de los artefactos software en nodos (usualmente plataforma dehardware).ElementosLos elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.Aspectos GeneralesLa mayora de las veces el modelado de la vista de despliegue implica modelar la topologa del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificacin hardware de propsito general, se ha diseado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.UsosAlgunos de los usos que se les da a los diagramas de despliegue son para modelar: Sistemas empotrados:Un sistema empotrado es una coleccin de hardware con una gran cantidad de software que interacta con el mundo fsico. Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribucin fsica de los componentes software del sistema a travs de nodos. Sistemas completamente distribuidos:En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores. Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro. El diseo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologa del sistema.

El desarrollo de software gil comprende un grupo de metodologas enfocadas esencialmente a implementar modelos de desarrollo que permitan disminuir los problemas y/o inconvenientes que suelen presentarse en modelos de desarrollo tradicionales o pesados.

Implementar un ciclo de pruebas de software que pueda abarcar de forma consistente todas sus actividades y se puedan integrar a modelos iterativos (Incrementales) giles deber tener diferentes caractersticas que dependern de las practicas giles utilizadas en el proceso de desarollo.

Inicialmente se deben tener en cuenta las siguientes reglas generales que permitirn empezar a crear un modelo de pruebas adaptado a metodologas giles:

1. En ciclos de desarrollo cortos las pruebas unitarias debern tener alta importancia, en la mayora de casos las practicas giles que se utilicen van a dirigir el diseo de cdigo orientado a las pruebas unitarias.

2. Las pruebas unitarias se debern ejecutar con frecuencia ya que permitiran evidenciar errores generados con cambios realizados en cdigo, estas actividades fortalecen la retroalimentacin entre los desarrolladores ya que se pueden detectar deficiencias comunes que ayuden a proponer mejoras generales en el proceso de desarrollo.

3. El equipo de pruebas deber realizar un anlisis en conjunto con los desarrolladores para identificar las pruebas necesarias que primordialmente estarn priorizadas por las funcionalidades identificadas por el cliente mediante criterios de aceptacin.

4. Las actividades de pruebas que generalmente llevan mas tiempo pueden estar asociadas a la documentacin de las mismas, el equipo de pruebas deber identificar oportunidades de mejora mediante las cuales estos tiempos puedan ser reducidos de forma considerable sin afectar el ciclo de pruebas.

5. En los modelos de desarrollo giles al igual que en los tradicionales el ciclo de pruebas debe estar creado de tal forma que cubra todo el ciclo de vida del proyecto, se deber priorizar en las fases en las cuales se realicen pruebas de integracin y/o regresin ya que en el desarrollo gil cualquier modificacin puede llegar a tener un gran impacto en el software, el equipo de pruebas puede proponer actividades orientadas a la automatizacin de pruebas con las cuales se puedan disminuir de forma considerable los tiempos de ejecucin.

6. Dependiendo las practicas giles utilizadas las pruebas sern diseadas antes de iniciar los procesos de implementacin de cdigo lo cual facilitara las actividades de pruebas para desarrolladores y testers.

- Teniendo en cuenta los anteriores puntos el ciclo de pruebas orientado a metodologas giles e integrado en el proceso de desarrollo deber tener las siguientes actividades:

Pruebas unitarias: Debern ser automatizadas dependiendo las practicas giles que se decidan utilizar.

Pruebas de sistema (Funcionales y NO funcionales) : Pruebas de sistema, exploratorias, usabilidad, fiabilidad, perfomance, seguridad.

Pruebas de aceptacin: Beta testing.

Pruebas de regresin: Enfocadas en los cambios realizados, para este tipo de pruebas ser fundamental la documentacin del sistema, en caso de que funcionalidades fundamentales del sistema sobre las cuales no se realicen cambios con frecuencia hagan parte de las pruebas de regresin se podra implementar actividades de automatizacin de pruebas que puedan apoyar este proceso en tiempos y rendimiento.

Investigaciones y fuentes para : modelo de implementacion.pptxfrancisco reyes