una arquitectura de software para … · conceptual sobre arquitecturas de software y juegos ......
TRANSCRIPT
UNA ARQUITECTURA DE SOFTWARE PARA JUEGOS ~
GERENCIALES EN EL AMBITO DE LA GESTIÓN DE
TIC's1
, BASADA EN EL MÉTODO COPA2
GRUPO DE INVESTIGACIÓN: DAVINCIS PROYECTO DE INVESTIGACIÓN: ARQUITECTURAS DE sonwARE PARA JUEGOS GERENCIALES
INVESTIGADOR: FREDY REYES RONCANCI03
RESUMEN
Considerando la necesidad de disponer de Arquitecturas
de Software para sistemas de simulación gerencial auto
adaptativos4, que permitan desarrollar juegos aplicables
en contextos funcionales y corporativos, se presentan
algunas de las vistas de una Arquitectura de Software en
el dominio específico de la Gerencia de TIC's, resultantes
de un proceso exploratorio de estilos arquitectónicos,
que utiliza como marco de referencia el método COPA
(Arquitectura de Plataforma Orientada a Componentes).
Se contextualiza la propuesta con una aproximación
conceptual sobre Arquitecturas de Software y Juegos
gerenciales y se establecen en cada vista de la
arquitectura, una propuesta de identificación de
componentes y formas de representación de los mismos.
PALABRAS CLAVE
Juego Gerencial, Arquitectura de Software, ünea de Producto
de Software, Arquitectura de ünea de Producto de Software.
Fecha de recepción del artículo: 07 de mayo de 2009. Fecha de aceptación del artículo: 29 de mayo de 2009.
1 TIC"s - Tecnologías de Información y Comunicaciones
ABSTRACT
In accordance with the necessity of Software
Architectures far auto-adaptive business simulation
games, designed to develop games in organizational
and functional contexts, sorne ofthe views of Software
Architecture in a specific doma in of the Management of
ICT's are included, which is the result ofthe exploratory
process of architectural styles, using a COPA method
(Component-Oriented Platform Architecting). lt
contextualizes the proposal with a conceptual approach
on Software Architectures and business games and
sets a component identification and representation in
each perspective.
KEYWORDS
Management Games, Software Architecture, Software
Product Unes, Software Product lines Architecture.
2 Método de Arquitectura de Plataformas Orientadas a componentes(COmponent-Oriented Platform Architecting) 3 Ingeniero de Sistemas de la Universidad Nacional de Colombia, Magl"steren Ingeniería deSistemasyCOmputación de la Universidad de los Andes. Especialista en
Administración de Empresas de la Universidad del Rosario, Especia lista en Gerencia de Tecnología de la Escuela de Administración de Negocios EAN. candidato a Doctoren lngenieña de Sistemas y computación en la Universidad Nacional de Colombia.
4 Se refiere a la capacidad de un producto de software deadaptarseautónomamente ante las necesidades que se originen en su entorno funcional de operación.
6 AVANCES Investigación en Ingeniería - 2009 No. 10
INTRODUCCIÓN
La necesidad de disponer de productos de software
caracterizados con alta facilidad de adaptación a las
condiciones del entorno tanto operativo como funcional,
exige que su desarrollo esté orientado por diseños
arquitectónicos estructurados, que consideren la forma
de modelar los requisitos de alto nivel (perspectiva de
negocio) y sus correspondencias en el plano técnico
(perspectiva de implementación). Además de Facilitar
el logro de las características de funcionalidad y de
calidad esperadas en un producto de software (PS), las
Arquitecturas de software también posibilitan mejores
prácticas en el proceso de desarrollo, mantenimiento y administración del software, el manejo de la
complejidad derivada de la dinámica de los PS, y una
mejor administración de la evolución de los PS.
A continuación se presenta una propuesta de arquitectura
de software, en el dominio de los juegos gerenciales,
específicamente en el ámbito funcional de la gestión de
TIC's, y bajo la estructura propuesta por el método COPA.
No se pretende abordar el debate conceptual entre
Ingeniería de software y Arquitectura de Software; se
considera que las dos disciplinas se requieren
mutuamente, es más coexisten intrínsecamente.
Inicialmente se realiza una contextualización de los
conceptos de Arquitecturas de Software y Juegos
Gerenciales.
1. ARQUITECTURAS DE SOFTWARE
Corresponden a la forma de organización de un producto
de software; en particular, se identifican y relacionan
sus componentes, sus interacciones con el entorno, y los principios que determinan su diseño y evolución
(ANSI/IEEE, 2000). El cuadro 1 recopila algunas
definiciones formales sobre Arquitecturas de Software5,
a partir de las cuales se pueden sintetizar los principales
aspectos relacionados:
Vistas. cada una de las perspectivas desde las
cuales se manifiesta una Arquitectura de Software, la
cual esta íntimamente relacionada con actores
especificas.
Componentes. cada uno de los elementos que
conforman el PS, que pueden tener diferente
representación dependiendo de la perspectiva en la
cual se esté modelando la arquitectura. Por ejemplo
puede referirse como un objetivo funcional de negocio,
un módulo, un subsistema, un paquete, un servicio.
Relaciones. Cada una de las formas de interacción
entre los componentes.
Restricciones. Criterios, políticas, normas, que
delimitan el comportamiento de los componentes y las
relaciones entre ellos.
Atributos. Incluye aspectos tales como: configuración,
estilo, semántica necesarios para la descripción de los
componentes y sus relaciones.
Los principales modelos de referencia para la aplicación
práctica del concepto de Arquitectura de Software, que
se utilizaron para esbozar esta propuesta son la
Arquitectura Orientada por Modelos -MOA-, y la
Arquitectura Orientada a servicios -SOA- en el
convencimiento de que es necesario tender lazos
integradores entre ellos. MDA es un enfoque de
desarrollo de software, que propone que éste sea
generado directamente a partir de modelos abstractos
soportados en diferentes lenguajes específicos; se
parte de un modelo de negocio hasta llegar a un modelo
computacional de implementación, requiriéndose un
conjunto de transformaciones entre cada modelo,
buscando que éstas se puedan realizar de manera
automática6 • SOA es un estilo de arquitectura que
plantea que el desarrollo de un PS se base en la
identificación de unidades funcionales distinguibles e
independientes que desarrollan una tarea específica, la
cual se constituye en la manifestación de servicio que
presta a las demás7•
s Puede consultarse también (Crispen 94), (Clements 94-2), (Morlconl 94),(Kruchten 94), (Garlan 94), (FHayes-Roth 94), (Abowd 95), (Lene 90),( Rechtln 92), (Perry
92), (BHayes-Roth 95), (K.Jackson 95), (ATA 96) y otras, todas refarenciadas por el Software Engineering lnstitute (SEi) en http://www.sei.cmu.edu/ architecture/
definitions.html. 6 Pare conocer la propuesta de este modelo consúltese (OMG, 2003). 1 (Kontogiannis-2007) presenta una clasificación de las áreas relacionadas con la orientación a servicies y a sistemas orientados a servicies.
AVANCES Investigación en Ingeniería - 2009 No. 10 7
Cuadro 1. Algunas Definiciones de "Arquitectura de Software"
(Fuente: http://www.sei.cmu.edu/architecture/ definitions.html.}
Boehm, et al., 1995
Jackson M., 1995
Rational Unified Process. Kruchten, 1999
A software system architecture .comprises A collection of software and system components, connections, and
• constraints. A collection of system stakeholders'
• need statements. A rationale which demonstrates that the components, connections, and constraints define a system that, if implementad, would satisfy the collection of system stakeholders' need statements.
"The definition of a set of generic component types together with: -a description of the properties of each type, -the rules governing the way each component type may interact with each other type -the style of interactions allowed between components, and -the rules which govem how a system (or subsystem) may be composed from i nstances of the generic components. •
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by whlch the system ls composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization-these elements and their interfaces, theircollaborations, and thei r composition.
Reconociendo la importancia de las diferentes escuelas
desde las cuales se ha desarrollado el concepto de AS
(Arquitectura como etapa de ingeniería y diseño
orientada a objetos; Arquitectura estructural, basada en
un modelo estático de estilos, Lenguajes de descripción
de arquitecturas (ADLs} y vistas; Estructuralismo
arquitectónico radical; Arquitectura basada en patrones;
Arquitectura, procesal y Arquitectura basada en
escenarios) (REYNOSO, 2004), esta propuesta se nutre
de una combinación fundamentalmente de la escuela
clásica estructuralª y aquella más reciente basada en
escenarios9•
Las AS por sí mismas no garantizan la calidad del PS, se
hace necesaria su consideración dentro de una
perspectiva más amplia, como pueden ser las Líneas de
Producto deSoftware10; utilizando el mismo concepto de
las industrias tradicionales, aunque no con la intención
de elaborar en serie un mismo producto, sino en el
sentido de estructurar un proceso de desarrollo que
genere y re-utilice dinámicamente, componentes de
software. El SEi la define como un conjunto de sistemas
intensivos de software que comparten un conjunto
común y administrado de características que satisfacen
las necesidades específicas de un segmento de
mercado particular y que son desarrollados a partir de
un núcleo base de componentes y de una manera
predeterminada. (traducido a partir de la definición
presentada enhttp://www.sei.cmu.edu/productlines}.
La propuesta de arquitectura presentada se
fundamenta en la necesidad de disponer una
"Arquitectura de Líneas de Producto de Software para
Juegos Gerenciales"; y se ha seleccionado la
Arquitectura de Plataforma Orientada por Componentes
- COPA- como método de Análisis, con base en la
metodológica comparación de las características de
éste y otros métodos presentada por (Matinlassi-2004);
el cuadro 2 relaciona los métodos allí evaluados.
B La corriente dominante académicamente, con representantes como Mery Shaw, Paul Clements, David Garlen, Robert Allen, Gregory Abowd, John Ockerbloom. (REYNOSO, 2004).
9 Un movimiento con predominancia europea, con centro en Holanda (los arquitectos holandeses de la Universidad Técnica de Eindhoven, de la Universidad Brije, de le Universidad de Gronlngen y de Phlllps Reseerch: Mugurel lontta, Dleter Hemmer, Henk Obblnk, Hans de Bruln, Hans ven Vllet, Eelke Folmer, Jllles ven Gurp, Jan Bosch), aunque también se encuentren los codificadores en el SEi de métodos comoATAM (Architecture Tredeoff Anelysis Method), CBAM(CostBenefitAnelysis Method), QASAR (Quelttyettrlbute-orlented software erchltecture). (REYNOSO, 2004).
10 Concepto enmarcado en la propuesta de Fábricas de Software, la cual concibe los procesos de desarrollo de Software basados en la reutlllzaclón de arquitecturas, componentes y conocimiento. (Greenfield, 2004).
8 AVANCES Investigación en Ingeniería - 2009 No. 1 O
Cuadro 2. Algunos Métodos de Análisis de AS (Fuente: Matinlassi-2004)
COPA Component-Orientecl Plattorm Architecting
FAST ( FamilyOriented Abstraction, Specification, and Translation)
FORM ( FeatureOriented Reuse Method)
KobrA {componentbased application development
QADA (Quality-driven Architecture Design and quality Analysis
Método para familias de productos electrónicos intensivos en software. Es a su vez el componente de Arquitectura dentro del marco de trabajo arquitectónico "Negocio-ArquitecturaPro cesos-Orga n izac i ón- {BAPO) [Obbink-2000] surgió de la experiencia de Philips en telecomunicaciones, imágenes médicas, y de los consumidores de electrónica. Fue presentado por Henk Obblnk y sus colegas de Phlllps Investigación en Eindhoven, en el 2000.
Busca la consolidación de procesos de ingeniería de software que sean mas eficientes optimizando el manejo de múltiples tareas, optimizando los costos de producción y acortar los tiempos de comercialización. fue desarrollado porWeiss y Lai en AT & T.
Orientado a la forma de aplicar análisis de dominio en termino de los rasgos característicos para el desarrollo de los ámbitos funcionales de un producto de software. Generado en Pohang University of Science and Technology.
Método que enfatiza los principios estratégicos de una línea de Producto, buscando sencillez y escalabilidad. KobrA es un acrónimo alemán para (Komponentenbasierte Anwendungsentwicklung).
Brinda mayar importancia a los atributos de calidad, es decir, a las características no funcionales de los productos de software. es una metodología desarrollada en vn Technical Research Centre of Finland.
COPA propone cinco vistas para el modelamiento de la
arquitectura, que se mueven desde el plano comercial
(orientado al por qué) hasta el plano técnico {orientado
al cómo): (a). La Perspectiva del Cliente. Describe el
mundo del cliente. Recoge los elementos del Negocio
que representan "valor" para el cliente. {b). El Dominio
de la Aplicación. Describe las aplicaciones que son
importantes para el cliente (el cómo del cliente),
relacionando los objetos de conocimiento para los
cuales la aplicación brindará soporte operativo al
cliente. (c} El Diseño Funcional. Comprende los
requisitos específicos de la aplicación. (el qué del
Producto), permitiendo establecer una primera idea de
la complejidad y tamaño del mismo. {d}. El Diseño
Conceptual. Incluye los conceptos arquitectónicos del
sistema, identificando sus componentes y atributos de
diseño. (El cómo del Producto). (e) La Realización.
Describe las tecnologías necesarias para la
construcción del producto; se incluyen aspectos
relacionados con hardware, software de base (sistemas
operativos, sistemas base de persistencia, diseño
gráfico) y configuración para el despliegue y operación
de producto. (Obbink, 2000).
2. LOS JUEGOS GERENCIALES
Un Juego Gerencial (Business Game) es un tipo de
software educativo, a través del cual se representan de
manera simulada, las funciones y procesos reales de
una organización o un área funcional, con el objetivo de
que una persona o grupos de personas que asumen un
rol determinado, desarrollen y perfeccionen habilidades
necesarias para una efectiva toma de decisiones en
dichos entornos. Las funciones empresariales se
simulan como sistemas abiertos, dinámicos, socio
técnicos y complejos por medio de una transformación
progresiva de escenarios de gestión.
Esta propuesta considera los Juegos Gerenciales desde
diferentes perspectivas, ya que involucran características particulares:
Son Juegos de Estrategia. Por naturaleza todo
juego gerencial requiere el diseño e implementación de estrategias determinadas
para lograr la mayor efectividad posible en la
toma de decisiones del negocio o del área funcional asociada, como la Gerencia de TIC'S.
AVANCES Investigación en Ingeniería - 2009 No. 10 9
Son Juegos de Rol. Los Jugadores pueden
asumir diferentes papeles. En el caso de la
Gerencia de TIC'S tales roles pueden ser
Gerente de TIC'S, Gerente de Proyectos de
Software, Gerente de Servicios de TIC'S,
Arquitecto de Software e Ingeniero de Soporte
Técnico.
Son Micromundos. Un ambiente virtual que
permite la experimentación y la toma de
decisiones en contextos virtuales.
Son Objetos Virtuales de Aprendizaje OVA, ya
que contienen tanto información como un
contexto específico para el aprendizaje,
orientado al desarrollo de la habilidad de toma
de decisiones, además de elementos de
retroalimentación al jugador sobre la
pertinencia de sus decisiones, el grado de
habilidad alcanzado, el grado de mejora por
cada decisión, entre otros aspectos.
Según (Ramírez, 2003} los juegos gerenciales se
estructuran en torno a los siguientes elementos:
Una o varias Organizaciones. El espacio
organizacional (empresarial} en el cual se
circunscribe el juego. Las organizaciones a su
vez tienen componentes estratégicos {plan de
negocios} y ofrece los espacios funcionales de
rol para cada uno de los participantes en el
juego.
Equipos participantes. Puede ser un solo
jugador, varios jugadores individuales
compitiendo entre sí, o agrupaciones de
jugadores en equipos. En cualquier caso todos
asumen responsabilidades específicas y toman
decisiones según dichos roles.
Escenarios. Estructurado por un conjunto de
variables tanto del entorno como internas a las
organizaciones y un calendario para el
desarrollo de las decisiones. Partiendo de una
10 AVANCES Investigación en Ingeniería - 2009 No. 10
situación dada, los escenarios van
evolucionando según el propio impacto de las
decisiones de los jugadores.
Motores da simulación del juego. Cuando se
realizan simulaciones, los juegos deben utilizar
modelos abstractos, general mente
matemáticos, para representar los
comportamientos del mundo real. El motor del
juego es el que implementa este modelo y lo
administra, aplicando cada decisión y
determinando el impacto en los escenarios del
mismo, considerando incluso efectos de largo
plazo.
Reglas del juego. Relacionadas tanto como
con los roles que asumen los jugadores como
con aspectos de los escenarios. Define
aspectos como los límites del juego,
ti pos de acciones posibles, tipo y
acción de beneficios a obtener por los
jugadores.
3. ARQUITECTURA DE SOFTWARE
PARA UN JUEGO DE GESTIÓN DE TIC'S
Se propone una arquitectura utilizando el conjunto de
vistas definida por COPA, y descritas previamente. Sin
embargo, en cada caso ha sido necesario considerar
definiciones particulares complementarias, lo cual
constituye una implementación específica del método,
para el ámbito de los productos de software objeto de
modelación: losjuegosgerenciales.
3.1 Vista l. La Perspectiva del Cliente
El interés del cliente es un proceso educativo
relacionado con el desarrollo de la habilidad de toma de
decisiones (figura 1}, en el espacio de los conocimientos
y ámbitos de gestión característicos de las diferentes
funciones de la Gerencia de TIC' s.
Figura 1 Vista del Clienta (Fuente: El Autor).
...JL r0 Actires Procesos ArHs<M Conocurunto
llU ~'--- ·u ,--- -----------------, •••-nc11 ¡-R .-~ : l Habilicl.lddt Tomo 1 L.nFundonts dt :
1 Erm1:'!:~:rto ....Jrr..l dt O.cl51onH Gtstl~n dt 1lC1 I Gertnttde TICs i ~aci~· .....,¡ Crem:i>ndt ·w..wM• w.w,. :1
Gertntt dt SIRtmu l ~crtacaun 1 fsce1•im .~ Pbncxl6ndcTCs ·1 dt lnf.omu1clon _.._ - 1 .:
Gtrtmt clt lnfn. ttlnlCIJl'a dt TICS
l,..xlbn do lmp.x1os G.tioo et. Si1ttm• 1 de 145 °'cisiones dt Wor"*ión 1
~liondt Recursos de 1 H.y(t-.v• e Sotwme 1
U.Se. 1 li:k:cominluciotltt 1
C.wKtHfUJClón de C..limdll._ ln6or...-. 1 ftlncbnesde l(s Y~ 1
1 1 L--------------------1
Se incluyen los actores relacionados (en este caso son
también sujetos de aprendizaje: estudiante de gerencia,
el gerente de TIC's, el Gerente de Sistemas de
Información, el Gerente Funcional de áreas diferentes a
TIC's y el Gerente de Infraestructura de TIC's); los
procesos de interés para ellos (formación, capacitación y
entretenimiento), las áreas de conocimiento sobre las
cuales operan los procesos (en este caso son los
ámbitos de aprendizaje: la habilidad de toma de
decisiones y las funciones de la Gerencia de TIC's) y los
objetivos que se espera lograr con el uso del PS. En este caso, mejoramiento de la calidad de las decisiones
tomadas en cuanto pertinencia, oportunidad,
costo/beneficio, impacto, nivel de riesgo; mejor calidad
del proceso de toma de decisiones, balanceando
críticamente la toma sistemática con la toma intuitiva de
declslones11 y mejor comprensión de las funciones de la
gerencia de TIC's, principalmente, en relación con su
papel estratégico para el desarrollo de la organización.
En esta vista se puede utilizar simbología de manera
flexible, siempre y cuando se diferencien los
componentes anteriores.
3.2 Vista 2. Modelamiento del
Dominio de Aplicación
Se pueden considerar dos dominios de aplicación; uno
relacionado con la función organlzaclonal y otra con la
habilidad de toma de decisiones {la cual no se incluye).
La primera, Figura 2, corresponde al ámbito funcional de
la Gerencia de TIC's en una organización, la cual se
concibe como un sistema de conocimientos,
habilidades, estrategias, metodologías, técnicas y
procedimientos, que se integran en un proceso
dinámico, a través del cual se facilita a las diferentes
personas de la organización el tratamiento automático y
la transmisión de la información, para que ésta logre sus
objetivos y evolucione significativamente.
Los componentes en esta vista se modelan los
siguientes subsistemas, cada uno de los cuales incluye
un subconjunto de funciones relacionadas
directamente alrededor de un objetivo: (1) Diseño
estratégico de TIC's. Considera los procesos de
Monitoreo y Planeación, el Modelamlento de Procesos
de Negocio y el Diseño Estratégico de Servicios de TIC' s.
Se concibe en el marco de la gobernabilidad, buscando
el aprovechamiento estratégico de las TIC's en la
búsqueda, para la organización, de modelos de negocio
innovadores, de valor agregado que optimicen su
operación (ACIS, 2006). (2) Gestión de Sistemas de
Información. Comprende los procesos sistémicos de
planificación, especificación, negociación y
contratación de aplicaciones, diseño e Implementación,
prueba, implantación, mantenimiento, explotación y uso
de los Sistemas de Información de la Organización y de
la gestión de la Información de la organlzaclón. Incluye la
gestión de los proyectos de desarrollo y/o
implementación y mantenimiento de Sistemas de
información, la explotación productiva de los mismos y
11 En la cual la elección se hace con base en lo que la persona "siente• que es correcto. Supone el uso de estimaciones subjetivas, conjeturas y presentimientos, para decldlrentrevariasalternativasdeacci6n.(Jennings-2000).
AVANCES Investigación en Ingeniería - 2009 No. 10 11
12
DES
AR
RO
LLO
SOST
ENIB
LEY
TEC
NO
LOG
ÍA
AVANCES Investigación en Ingeniería - 2009 No. 10
AVANCES Investigación en Ingeniería - 2009 No. 10 13
DES
AR
RO
LLO
SOST
ENIB
LEY
TEC
NO
LOG
ÍA
Figura 4 Vista del Diseño Conceptual (Fuente: El Autor).
EscenarioFunciónJugador Juego
FunciónOrganizacional
Rol
EscenarioContexto
Indicador Función
Regla
Alternativade Decisión
Ronda
Habilidad
IndicadorHabilidad
Decisión
14
DES
AR
RO
LLO
SOST
ENIB
LEY
TEC
NO
LOG
ÍA
BIBLIOGRAFÍA
AVANCES Investigación en Ingeniería - 2009 No. 10