lenguaje descriptor y patrones de arquitectura
DESCRIPTION
Evidencia de Aprendizaje unidad 2TRANSCRIPT
Diseño y Arquitectura de Software
Fecha: 12/10/2012
Evidencia de aprendizaje. Lenguaje descriptor y patrones de arquitectura de software
Facilitadora: Miriam Salazar
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/Windows-
Apache-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 instalación de la
aplicación.
Código fuente
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