Dise単o y Arquitectura de Software
Evidencia de aprendizaje. Lenguaje descriptor y patrones de arquitectura de software
Facilitadora: Miriam Salazar
Fecha: 12/10/2012
Para demostrar tu conocimiento acerca de los tipos de patrones arquitectónicos, tú diseñarás una propuesta de arquitectura que sirva para solucionar un problema; para ello considerarás que el patrocinador (la empresa que solicitó la solución) es una tienda de conveniencia, tú analizarás sus requerimientos de software y lo contrastarás con las herramientas de diferentes tipos de sistema, siendo capaz de elaborar una propuesta.
Como parte de la evaluación de esta unidad, es necesario realizar en forma gráfica la arquitectura de una tienda de conveniencia aplicando y justificando el uso del patrón específico.
1. Justifica el uso del patrón. 2.
Realiza la representación de la arquitectura propuesta. Para hacer esta
presentación, usarás herramientas de diseño gráfico de arquitectura y, en base a los ejemplos mostrados en la unidad, hacer un diagrama con la arquitectura propuesta.
PROPUESTA
Esta actividad tiene como finalidad realizar una propuesta para la solución de un problema de una tienda de convivencia. Debemos de identificar la arquitectura más conveniente para la gestión de funcionamiento de un software que se implementara en ella. Se necesita la utilización de una arquitectura de software para
la
identificación de los elementos claves del sistema en desarrollo.
Mi propuesta propuesta persigue los siguientes propositos fundamentales: Proporcionar una comprensión arquitectónica global del sistema, mediante el uso de vistas arquitectónicas, de modo que se muestre los aspectos más significativos del sistema. Proporcionar
soporte
para
toma
de
decisiones
arquitectónicamente
significativas que deban ser tomadas en el desarrollo del sistema.
Organizar el desarrollo del sistema. Fomentar la reutilización. Hacer evolucionar el sistema.
Alcance
El enfoque se extiende a todo el Sistema de la tienda de convivencia, a todos los integrantes del proyecto encargados de desarrollarlo ya que el mismo influye en la toma de desiciones arquitectónicas, y a todos los implicados en el desarrollo del sistema como: clientes, para que comprendan con suficiente detalle qué se esta haciendo y cómo, de modo que facilite su participación.
REPRESENTACIÓN ARQUITECTÓNICA
A partir del estudio de los estilos arquitectónicos realizado en los temas anteriores y de las características particulares del sistema a desarrollar, y como parte de las decisiones arquitectónicas para definir la propuesta de arquitectura he decidido utilizar para el Sistema de la tienda de convivencia una Arquitectura Orientada a Servicios.
La razón del por qué se tomó esta decisión es por las siguientes razones: Porque las Arquitecturas Orientadas a Servicios permiten optimizar más
rápidamente a las condiciones que modifican el negocio, con esto se promueve y se permite la reutilización, la aplicación de tecnologías existentes en lugar de volver a consumir tiempo y costos de una nueva creación. Un Sistema de software de la tienda de convivencia está formado por un
conjunto de procesos que se ejecutan y que son reutilizables, entre ello podemos mencionar el de contabilidad, propaganda, ventas, compras, inventarios, etc. Por otra parte el Sistema en gestión, necesitará intercambiar gran cantidad de
información e interactuar con otros módulos del mismo.
Es un estilo arquitectónico que se basa fundamentalmente en estándares de
desarrollo de los servicios web como: XML, WSDL y SOAP, garantizando la operatividad entre distintos servicios y aplicaciones que colaboran con la agilidad del negocio. Tiene la ventaja de ser un modelo arquitectural con flexibilidad para la definición, implementación, sustitución, evolución de los servicios y las funcionalidades que contiene.
Las Arquitecturas Orientadas a Servicios se distinguen por exponer la lógica del negocio mediante servicios web que deben poder ser accedidos por todas aquellas aplicaciones que necesiten de ellos. La vía más utilizada hoy en día para acceder a estos servicios es a través de un registro UDDI, mediante el cual las aplicaciones pueden publicar y descubrir dichos servicios para su invocación.
Arquitectura en Capas
El sistema propuesto estará estructurado en subsistemas o módulos definidos de forma vertical que colaboran entre sí mediante interfaces y una estructuración por niveles lógicos (capas) de forma horizontal posibilitando así el intercambio de datos, l
servirse el nivel superior del inferior y este a su vez brinda sus servicios a su inmediato superior, donde la capa de servicios compartidos expondrá los procesos de negocio mediante servicios web.
La estructuración del sistema en capas viene dada por las ventajas que propicia como son: la flexibilidad, escalabilidad, reutilización, capacidad de mantenimiento, entre otras. Esta propuesta esta estructurada en una Arquitectura de tres capas, siendo esta arquitectura la más usada que otras de la misma clase.
Arquitectura en Capas de la Propuesta SOA
Capa de Presentación
Esta capa es la encargada de gestionar los datos de entrada y salida mediante las interfaces de usuario, que van a permitir la interacción del sistema con los usuarios potenciales. En otras palabras, maneja el contexto del usuario e interactúa con la capa de negocio donde está implementada toda la lógica de la aplicación.
A partir de los Requisitos no Funcionales de los usuarios y de las facilidades que brinda el diseño arquitectónico propuesto, la capa de presentación del Sistema de la tienda de convivencia puede ser desarrollada en cualquier ambiente, tanto Web como Desktop. Finalmente se decidió desarrollar la capa de presentación sobre la Web haciendo uso del software comercial y libre. De esta forma se busca abaratar la solución mediante el uso de clientes ligeros, los cuales no ejecutan demasiadas labores de procesamiento para la ejecución de la aplicación misma.
Entre las ventajas de las aplicaciones basadas en la web se pueden mencionar: Compatibilidad multiplataforma Actualizaciones al sistema son más rápidas y fáciles, pues basta con realizar
los cambios sobre el servidor donde este corriendo la aplicación. Acceso inmediato online. Facilidad de prueba. Menores requerimientos de memoria local. Precio ya que consumen menor cantidad de recursos. Múltiples usuarios concurrentes.
Por otra parte, si bien es cierto que la arquitectura cliente servidor de la web ha ofrecido muchas ventajas, también es cierto que carece de la riqueza gráfica de las aplicaciones de escritorio que cuentan con controles inteligentes.
Patrones El patrón arquitectónico propuesto a usar es el siguiente: Modelo – Vista – Controlador (MVC). Se trata de realizar un diseño que desacople la vista del modelo, con la finalidad de mejorar la reusabilidad. De esta forma las modificaciones en las vistas impactan en menor medida en la lógica de negocio o de datos.
Elementos del patrón
Modelo Vista Controlador
1. El controlador principal recibe una petición del navegador. La configuración del servidor Apache permite dirigir todas las peticiones al controlador principal. 2. El controlador principal averigua la validez de los datos enviados y dirige la petición al controlador correspondiente. 3. El controlador correspondiente trata esta petición. Para ello, puede necesitar los datos de la base de datos y entonces tiene que referirse al modelo. 4. El modelo accede a la base de datos, para insertar, suprimir, actualizar o recuperar los datos. 5. El modelo recibe los datos de la base. 6. El modelo transmite al controlador el resultado del acceso a la base de datos. 7. Según el resultado recibido, el controlador escoge la vista a mostrar al cliente (navegador) y le proporciona los elementos dinámicos. 8. El navegador recibe la vista escogida.
Capa de Servicios
Una característica peculiar de las arquitecturas en capas es que las capas inferiores brinden las funcionalidades que necesitan las capas inmediatamente superiores, y a la vez estas, solo puedan acceder a las funcionalidades proporcionadas por las capas inmediatamente inferiores. Visto de esta manera, la capa de servicios es la encargada proporcionar las funcionalidades que necesita la capa de presentación. Además es la responsable de gestionar toda la lógica de negocio de la aplicación y a la vez representa el contenedor lógico donde se ubican los servicios compartidos.
Las transacciones y operaciones de negocio serán realizadas por los servicios web que son los encargados de exponer toda la funcionalidad del sistema.
Para el desarrollo de cada servicio web se utilizarán los estándares y herramientas disponibles de la industria de desarrollo de software, entre ellos podemos mencionar a XML como formato estándar para los datos,
SOAP como protocolo para el
intercambio de datos, WSDL para la descripción de la interfaz de los servicios web, WS-Security para la autenticación de los actores y la confidencialidad y por último UDDI para publicar la información de los servicios web,
Las Arquitecturas Orientadas a Servicios se distinguen por exponer la lógica del negocio mediante servicios web que deben poder ser accedidos por todas aquellas aplicaciones que necesiten de ellos.
Es necesaria la instalación JUDDI
para gestionar los servicios web. Es una
implementación libre de la especificación UDDI para java en cuestiones de servicios web. Entre sus principales características están: que es open source, independiente de plataforma, brinda soporte para JDK 1.3.1 hasta JDK 1.5, puede usarse con cualquier base de datos relacional que soporte Structured Query Language (SQL) estándar como: MySQL, DB2, Sybase, JDataStore, HSQLDB. Es desplegable en cualquier servidor de aplicación de java que soporte la especificación Servlet 2.3 como: Jakarta Tomcat, JOnAS, WebSphere, WebLogic, Borland Enterprise Server, JRun. Es de fácil integración con sistemas de autenticación existentes. Soporta configuración desplegable de clúster de registros de JUDDI. (Apache, 2007).
Vista interna de un servicio web
Los servicios web proporcionados por la capa de servicios, que expondrán toda la funcionalidad del sistema, serán también desarrollados en capas. A partir esta organización estructural en capas se propone la utilización de un framework por cada una de ellas, pues contienen funcionalidades bien definidas para un determinado dominio de la aplicación, un conjunto de componentes implementados e interfaces, que se pueden utilizar, redefinir y crear nuevos. De modo que se puedan crear los componentes necesarios por cada capa del servicio web. Capa de Persistencia
La capa de Persistencia es la encargada de gestionar el almacenamiento de los datos en el sistema gestor de base de datos. Siendo los componentes de acceso a datos una parte fundamental en el desarrollo del sistema.
Sistema Gestor de Base de Datos (SGBD)
El Módulo, como todo Software de Gestión, necesita un mecanismo de información, donde almacenar los datos necesarios para realizar las distintas operaciones. La estructuración del sistema en Capas permite que se abstraiga la lógica de negocio del almacenamiento de los datos, la capa de acceso a datos contiene toda la lógica de acceso, ya sea consultas y procedimientos almacenados, dejando a la Base de Datos como simple almacén de datos sin ninguna lógica.
Finalmente para terminar con la representación de la arquitectura el artefacto Documento Descripción de la Arquitectura se apoyará también en las 4+1 vistas, que responden a la tendencia: “Arquitectura como etapa de ingeniería y diseño orientada a objetos”. Siendo estas: la Vista de Caso de Uso, Vista Lógica, Vista de Procesos, Vista de Implementación, Vista de Despliegue. Para la modelación de estas vistas se utilizara UML como herramienta de modelado.
Requerimientos de Hardware
Se necesitaran Estaciones de Trabajo que cuenten con tarjetas de red, memoria RAM de 1 GB , Sistema UPS Standby, interactivo de Tripp Lite; ofrece protección completa para computadoras de escritorio, estación y así evitar la perdida de información por la interrupción de energía.
Servidor para la instalación de los servicios, aplicaciones WEB, así mismo las Bases de Datos que contienen toda la información de la tienda. Con las siguientes características:
Tener periféricos Mouse y Teclado.
Microprocesador con 1Mb de cache L2, 3 GB de memoria RAM.
160 GB de espacio libre en disco.
Tarjeta de red.
Sistema UPS Standby, interactivo de Tripp Lite; ofrece protección completa para computadoras de escritorio, estación y así evitar la perdida de información por la interrupción de energía.
Requerimientos de Software Estaciones de Trabajo
Sistema Operativo: Windows 7 o superior, Debian, Ubuntu. Navegador Web: Internet Explorer 9.0 o superior, Mozilla Firefox 2.0 o superior. Servidores
Gestor de Base de Datos: PostgreSQL 8.2, Servidor Web: Apache Tomcat 6.0.13, Debian, Ubuntu. Servidor de Aplicaciones: Apache 2.2.4, Máquina Virtual de Java: Java Development Kit (JDK) versión 1.7. Servidor Web: Apache Tomcat 6.0.13
Redes
La red existente en las instalaciones debe de soportar la transacción de paquetes de información de al menos unas 10 máquinas a la vez. Para hacer más fiable la aplicación debe de estar protegida contra fallos de corriente y de conectividad, para lo que se deberá parametrizar los tiempos para realizar copias de seguridad. Implementar las transacciones de paquetes en la red con el protocolo TCP/IP que permite la recuperación de los datos.
Para la implementación de nuestro software solicitaremos la adquisición del DBMS MySQL es muy utilizado en aplicaciones web, en plataformas (Linux/WindowsApache-MySQL-PHP/Perl/Python), su popularidad como aplicación web está muy ligada a PHP, que a menudo aparece en combinación con MySQL. Por un lado se compraría la versión con licencia para el manejo principal de la base de datos.
Seguridad
Los servicios ofrecidos por el sistema no podrán ser ejecutados por sistemas no autorizados, de manera que exista un sistema de autenticación para los servicios web que sea transparente al usuario de las aplicaciones. Tanto la comunicación entre los componentes de la plataforma como el manejo de datos del sistema deberán encontrarse cifrados mediante algoritmos de encriptación, específicamente el manejo de la seguridad de claves de acceso de usuarios.
La seguridad del sistema es
muy importante y para es aspecto aplicaremos el
protocolo EAP-MD5, este protocolo utiliza nombre de usuario y contraseña para autenticación. La contraseña es transmitida de forma cifrada a través del algoritmo MD5. El inconveniente de este tipo de seguridad es que no suministra un nivel de protección alto pues puede sufrir ataques de "diccionario", es decir, un atacante puede enviar varías cifradas hasta encontrar una válida. No hay modo de autentificar el servidor, y no genera claves WEP dinámicas.
Portabilidad, escalabilidad, integralidad El sistema deberá poder ser utilizado desde cualquier plataforma de software
(Sistema Operativo). El sistema deberá hacer un uso racional de los recursos de hardware de la
máquina, sobre todo en las PC clientes. La documentación de la arquitectura deberá ser reutilizable para poder
documentarla como una familia de productos. Se desarrollará cada pieza del sistema en forma de componentes (elementos)
con el fin de re-utilizarlos para futuras versiones del sistema. El sistema deberá exponer toda su funcionalidad mediante servicios web que
se registrarán en el directorio UDDI, garantizando así la integración de cualquier otro sistema o servicio.
Los servicios web serán desarrollados cumpliendo con los estándares definidos por la W3C y OASIS como: XML como formato estándar para los datos que se vayan a intercambiar, SOAP como protocolo para el intercambio de datos, WSDL para la descripción de la interfaz pública de los servicios web, WS-Security para la autenticación de los actores y la confidencialidad de los mensajes enviados y finalmente la UDDI para publicar la información de los servicios web y comprobar qué servicios web están disponibles, la influencia de estos RNF recaen directamente sobre la capa de negocios la cuál presta estos servicios directamente.
El sistema podrá ser escalado fácilmente de forma vertical mejorando los
requerimientos de hardware de los servidores, por ejemplo: aumentando la memoria RAM, cambiando el microprocesador por otro de mayor rendimiento, etcétera, y horizontalmente mediante balances de carga a través de clústeres de servidores en la medida que crezca la demanda. Metodología propuesta
Modelo Scrum
Scrum es un proceso ágil y liviano que sirve para administrar y controlar el desarrollo de software. El desarrollo se realiza en forma iterativa e incremental (una iteración es un ciclo corto de construcción repetitivo). Cada ciclo o iteración termina con una pieza de software ejecutable que incorpora nueva funcionalidad. Las iteraciones en general tienen una duración entre 2 y 4 semanas. En Scrum, el equipo se focaliza en una única cosa: construir software de calidad.
Como estos modelos de desarrollo establecen el orden en que se ejecutarán esas actividades, creo que la metodología más conveniente es: .Una metodología ágil por las ventajas de desarrollar el proyecto en forma más rápida y efectiva.
Para este caso creo que la más conveniente es la Metodología Scrum, es una metodología que se adapta a nuestras necesidades, el equipo de trabajo puede reunirse en periodos cortos de tiempo para presentar los avances y resultados del proyecto. Nuestras reuniones de trabajo con el cliente será cada semana. Para ello a él se le presentaran los avances y en base a los resultados propondrá los nuevos requerimientos o retroalimentación al proyecto.
Desarrollo del sistema
1.- Debemos definir un enfoque metodológico,
Se realiza un breve análisis de la metodología que será empleada por el grupo encargado para el desarrollo del Sistema Informático, precisando los motivos por los cuales se desean obtener los resultados esperados de su aplicación.
Organización del grupo encargado del desarrollo del sistema: Selección del personal encargado para el desarrollo, asignándole sus respectivas labores y actividades bien definidas, por lo que desde el primer día se realiza una reunión para estableces objetivos, responsabilidades y metas particulares y generales.
Estructura del equipo de desarrollo
a. Personal requerido Un líder de proyecto además de ser jefe de proyecto del departamento de sistemas. Tres desarrolladores Personal para soporte hardware y software de la empresa EL encargado de la empresa para definición de requerimientos
De acuerdo a los roles antes mencionados y los cargos asignados por la empresa, se necesitan:
Scrum Master: Jefe de proyecto del departamento de sistemas Product Owner: Director de administración de la tienda de convivencia.
Stakeholders:
Personas
que
pueda
establecer
requerimientos claros que ayuden al desarrollo del sistema. Cabe aclarar que este grupo de personas estará representado por el Product Owner Team: Es el grupo de desarrolladores que, según las especificaciones del proyecto estará constituido por 3 personas a las que se les supone buen conocimiento, tanto del problema como de la herramienta a utilizar.
Se debe de establecer un tiempo de desarrollo del proyecto, por ejemplo el proyecto es de tres meses. Por tal motivo de diseña un diagrama de Gant para establecer los tiempo destinados a cada una de las etapas de desarrollo del proyecto. Este diagrama debe de plasmar los tiempos para poder llevar esta metodología
por
ejemplo:
Primero se tiene que empezar por definir qué es lo más importante del proyecto.
Armar las historias anteriormente realizadas.
Se definen los roles de cada participante del proyecto.
También se definen las fechas de las reuniones tanto diarias.
Así mismo definir las reuniones quincenales para revisar el estado del proyecto.
Especificación del programa
Se conoce también como definición del problema o análisis del programa. En este paso se determinan la información inicial para la elaboración del programa. Es donde se determina qué es lo que debe resolverse con el computador, de qué presupuestos se debe partir... en definitiva, el planteamiento del problema.
Se requieren cinco tareas: 1. Determinación de objetivos del programa.
Debe definirse claramente los
problemas particulares que deberán ser resueltos o las tareas que hay que realizar, esto nos permitirá saber qué es lo que se pretende solucionar y nos proporcionará información útil para el planeamiento de la solución. 2. Determinación de la salida deseada.
Los datos seleccionados deben ser
arreglados en una forma ordenada para producir información. Esta salida podría ser una salida de impresión o de presentación en el monitor. 3. Determinación de los datos de entrada. Una vez identificada la salida que se desea, se pueden determinar los datos de entrada y la fuente de estos datos. Los datos deben ser recolectados y analizados. 4. Determinación de los requerimientos de procesamiento. Aquí se definen las tareas de procesamiento que deben desempeñarse para que los datos de entrada se conviertan en una salida. 5. Documentación de las especificaciones del programa. Es importante disponer de documentación permanente. Deben registrarse todos los datos necesarios para el procesamiento requerido. Esto conduce al siguiente paso del diseño del programa.
Diseño del programa
Es diseñar cualquier sistema nuevo o las aplicaciones que se requieren para satisfacer las necesidades. Esta actividad se debe dividir en:
- Operaciones de entrada/salida - Cálculos - Lógica/ comparación - Almacenamiento/ consulta
En este paso se genera una solución con técnicas de programación como diseño descendente de programas, pseudocódigos, diagramas de flujo de programas y estructuras lógicas.
Codificación del programa
Es la generación real del programa con un lenguaje de programación. En esta etapa se hace uso de la lógica que desarrolló en el paso del diseño del programa para efectivamente generar un programa. Se debe seleccionar el lenguaje apropiado para resolver el problema.
Prueba y depuración del programa
Depurar es correr el programa en una computadora y corregir las partes que no funcionan. En esta fase se comprueba el funcionamiento de cada programa y esto se hace con datos reales o ficticios. Cuando los programas están depurados, se prueban. Cuando los programas se depuran, se pueden encontrar los siguientes errores: a) Errores de sintaxis o de compilación. Es una violación de las reglas del lenguaje de programación. Son más fáciles de corregir, ya que son detectados por el compilador (posible error de escritura), el cual dará información sobre el lugar donde está y la naturaleza de cada uno de ellos mediante un mensaje de error. b) Errores de Ejecución. Se deben generalmente a operaciones no permitidas como dividir por cero, leer un dato no numérico en una variable
numérica, exceder un rango de valores permitidos, etc. Se detectan porque se produce una parada anormal del programa durante su ejecución. c) Errores de Lógica. Corresponden a la obtención de resultados que no son correctos y la única manera de detectarlos es realizando suficientes pruebas del programa. Son los más difíciles de corregir, no sólo por la dificultad de detectarlos, sino porque se deben a la propia concepción y diseño del programa. d) Errores de Especificación. Es el peor tipo de error y el más difícil de corregir. Se deben a mal diseño del programa posiblemente por mala comunicación usuario programador y se detectan cuando ya se ha concluido el diseño e instalación del programa, lo cual puede implicar repetir gran parte del trabajo realizado. e) Prueba. Consiste en verificar la funcionalidad del programa a través de varios métodos para detectar errores posibles.
Documentación del programa
Consiste en describir por escrito a nivel técnico los procedimientos relacionados con el programa y su modo de uso. También se debe documentar el programa para que sea más entendible por ejemplo:
A los usuarios se les elabora un manual de referencia para que aprendan a utilizar el programa. Esto se hace a través de capacitaciones y revisión de la documentación del manual de usuario. El manual del usuario no está escrito a nivel técnico sino al de los distintos usuarios previstos y explica en detalle cómo usar el programa
A los programadores a través del manual del analista para que recuerden aspectos de la elaboración del programa o en caso que otras personas puedan actualizarlo o modificarlo (darle mantenimiento) y no son necesariamente las personas que lo diseñaron. Es por ello, que la documentación debe contener algoritmos y flujogramas
de los diferentes módulos que lo constituyen y las relaciones que se establecen entre ellos.
Mantenimiento del programa
Es el paso final del desarrollo del software. Alrededor del 25% del costo total del ciclo de vida de un programa se destina al mantenimiento. El propósito del mantenimiento es garantizar que los programas en uso estén libres de errores de operación y sean eficientes y efectivos.
Establecer los productos a entregar
Debemos tener preparados los avances del trabajo, es decir prototipos. Cada cierto tiempo (que debe establecerse en el equipo de trabajo) se hará revisión de un sistema funcional para su evaluación (tomando en cuenta el diseño de diagrama de Gant).
El producto final a entregar está compuesto por el código fuente del sistema, instaladores de la aplicación y manuales. El producto deberá cumplir los requerimientos iníciales para las áreas de interés.
Al finalizar el proyecto, es necesario hacer entrega de:
Documentación de la arquitectura y patrones usados.
Documentación de la metodología usada.
Manuales de usuario.
Manual operativo.
Manual
de
aplicación.
Código fuente
instalación
de
la
SCRUM es un proceso de desarrollo de software iterativo e incremental utilizado comúnmente en entornos de desarrollo ágiles de software, esta metodología ayuda a que trabajemos todos juntos, en la misma dirección, con un objetivo claro y preciso para lograr una entrega de un sistema de información de Calidad en poco tiempo. SCRUM también
nos permite seguir de forma clara el avance de las tareas a
realizar, de forma que el responsable del proyecto y cliente puedan ver día a día cómo progresa el trabajo.
CONCLUSIONES
Como vimos en esta propuesta dicha de otra forma… investigación, para solucionar un problema de una tienda de convivencia, y desarrollar la construcción de un producto de software, fue necesario desarrollar una serie de actividades, todo ello partiendo desde la visión del proyecto que el cliente desea resolver hasta el producto final. Para ello se tuvieron que analizar algunas cuestiones de requerimientos tanto de software y hardware, conocer las diferentes arquitecturas y patrones arquitectónicos de software.
Es importante recalcar que para desarrollar este tipo de trabajos se requiere de tiempo, conocimientos y sobre todo experiencia para la creación de software de calidad.
Fuentes:
http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios http://laurel.datsi.fi.upm.es/~ssoo/DAW/Trabajos/2008-2009/001/func_es http://juanktecnosoftware.blogspot.mx/2012/06/arquitectura-orientada-servicios-soa.html http://scrum.org.mx/?page_id=20 http://es.wikipedia.org/wiki/Scrum http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios