Apuntes de Curso Arquitecto de Ambientes Virtuales de Aprendizaje
Apuntes de Curso Arquitecto de Ambientes Virtuales de Aprendizaje
Apuntes de Curso Arquitecto de Ambientes Virtuales de Aprendizaje
Nivel 01
Lección 01
Arquitectura de software
La arquitectura de software es similar al plano de una casa, así como este define su
tamaño, distribución y relación entre espacios, el de software establece la estructura del
sistema, sus componentes, incluso sus propiedades de hardware. Para que logres una
buena arquitectura de software:
1. Requerimientos
2. Diseño
3. Documentación
4. Evaluación
5. Implementación
Proyecto de administración
Proceso de administración
Ingeniería
Compatibilidad
En esta estructura puedes observar que las cuatro principales áreas se complementan
para un funcionamiento óptimo, siendo el área de Compatibilidad la que se encarga de
llevar el control, para que el trabajo no se desvía de los objetivos del negocio.
Desarrollo
Implementación
Control
Mantenimiento de tecnologías de la información en forma de software
Lección 02
Ambientes virtuales de aprendizaje
El desarrollo de acciones educativas puede llevarse a cabo sin que los profesores o
alumnos coincidan en el mismo lugar.
Todo ambiente virtual de aprendizaje debe contar con las siguientes cuatro
características:
El ambiente AVA que implemente estas características, garantiza el éxito del objetivo
para el que fue creado y el logro de metas futuras.
Tipos de AVA
E-learning. Consiste en la educación y capacitación a través de internet; se
sustenta en herramientas informáticas, para ofrecer materiales que permitan al
alumno el aprendizaje individual.
Sistema de gestión de aprendizaje (LMS). Es la infraestructura que
ofrece y gestiona contenidos de instrucción, sigue un proceso hacia el
logro de objetivos y presenta datos para supervisar el proceso de
aprendizaje.
Curso online masivo abierto (MOOC). Son cursos en línea dirigidos a un
amplio número de participantes a nivel global, es de acceso libre y no
necesitas tener conocimientos previos del tema para tomar los cursos.
S-learning. Es un nuevo tipo de AVA, que hace uso de las redes sociales para
interactuar con las personas; es un sistema abierto que se va construyendo
cada que un nuevo usuario se agrega. Este tipo de ambientes facilita la
comunicación, ya que se comparten temas de interés general.
Etapa sensomotora
Etapa preoperacional
Etapa de operaciones concretas
Etapa de operaciones formales
Principios de diseño
El primer nivel establece una solución en términos generales, con lenguaje simple al
bajar el nivel de abstracción, va aumentando el detalle del modelo, hasta llegar al
código fuente, el nivel intermedio permite tener dos tipos importantes de abstracción:
Para hacer un buen desarrollo de software como principio, debes tomar en cuenta
todas las etapas, los conceptos anteriores y aplicarlos en el sistema.
Lección 03
Requerimientos de negocios
A nivel superior, deben explicar las reglas y procedimientos del negocio, por
ejemplo, debe contar con cuatro diferentes tipos de usuarios con una interfaz
para cada uno, debe tener la capacidad de contener usuarios de todas
partes del mundo y el contenido debe estar en el idioma oficial e inglés.
A nivel medio, deben describir las acciones que el usuario puede realizar en
el sistema, por ejemplo, el administrador es el único que puede dar de alta el
contenido y el usuario normal solo lo puede visualizar, la interfaz de usuario
normal no debe exceder de tres páginas de navegación, la interfaz debe
realizarse en software libre, enfocado tanto a pc como a dispositivos móviles.
A nivel inferior, los requerimientos deben describir situaciones o elementos
detallados que se necesitan para el sistema. Por ejemplo, se debe realizar la
base de datos en un lenguaje no relacional.
Los requerimientos del nivel superior se valen de las reglas del negocio, como
pueden ser políticas, estándares de calidad, prácticas o procedimientos para
especificar la visión y alcance del proyecto, todos los requerimientos deben estar
sujetos a estas reglas, dictan la funcionalidad del sistema, no especifican detalles
técnicos, solo ayudan a definir la lógica global de cada servicio con objetivos, por
ejemplo, incrementar ingresos, globalizar las tiendas y conseguir nuevos mercados.
Reconocer cuáles son los requerimientos del usuario entre las propuestas de la
mesa directiva y las necesidades del proyecto.
Para desarrollar un sistema que le sea útil al cliente, se deben tomar en cuenta los
requerimientos que este debe cumplir.
Para ellos debes revisar las necesidades funcionales que deberás satisfacer con el
sistema de software, considera tus dos fuentes principales para detectarlas.
Funcionales. Que son las acciones que debe hacer el sistema, es decir, los
casos de uso del sistema, criterios que son adecuados para su propósito.
No funcionales, Que definen cómo debe ser el sistema, especifican cómo
evaluar la operación de las funcionalidades del servicio.
Es fundamental que tengas claros y definidos los requerimientos, así podrás generar
un esquema base para la implementación del sistema.
Nivel 02
Lección 01
Proceso de trabajo
Visión y alcance
Una vez recopilada la información del problema a resolver, los datos relevantes de
todos los involucrados en el proyecto de la organización y sus reglas de negocio, es
necesario llevar un registro de la información dentro de un documento visión, en el que
se define el alcance del proyecto. Para realizar un correcto documento visión de tu
proyecto, debes organizarlo de la siguiente manera:
Sección I Definición preliminar del problema.
Lección 02
Definición de la arquitectura
Para poder definir la arquitectura del software, es necesario tomar en cuenta los
requerimientos, el contexto de la organización y la experiencia previa en el desarrollo
de sistemas de software.
Definición preliminar
Los requerimientos representan las características más importantes, con las que
debe cumplir el sistema, se establecen con todos los involucrados y se analizan los
drivers arquitectónicos, para poder crear la o las estructuras del sistema de software,
para analizar el contexto de la organización, es necesario tomar en cuenta lo siguiente:
Una vez que estos aspectos se acoplan a los requerimientos, se elige una
metodología de modelado de arquitectura entre las siguientes:
Tipos de arquitectura
Para poder definir la arquitectura del software toma en cuenta los requerimientos, el
contexto de la organización y tu experiencia previa en el desarrollo de sistemas de
software.
Estilos arquitectónicos
Para tener un excelente control del diseño detallado, utiliza algún estilo
arquitectónico, que a través de guías definidas como un estándar, establezca un
esquema de organización para la estructura del sitio, en un entorno web se usan los
estilos de sistemas distribuidos, esto tiene como ventaja compartir cursos entre varios
servidores, una gestión fácil de los concurrencia, tolerancia a fallos, buena
escalabilidad, es decir, la propiedad de un sistema para fomentar el tamaño. Algunos
de los estilos arquitectónicos existentes aplicados a entornos web son:
Patrones de diseño
Tipos de patrones
Para ello debes usar patrones, estos sirven para adaptar detalles de la realidad, a la
estructura de los datos, funciones y métodos en el desarrollo del código, según su uso
y lógica existen tres tipos de patrones:
Creacionales. Inician y crean objetos que deben ser programados, una de las más
utilizadas es fábrica abstracta, este patrón es una clase de programación, que te
permite crear familias de objetos, como si fuera una fábrica tiene métodos y funciones
que crean objetos con solo ser activado, por ejemplo, una fábrica de discos que crea
objetos bluray o de doble capa.
Cada uno de estos patrones resuelve un problema particular por lo que tu tarea
como arquitecto es saber cómo aplicarlas de la manera correcta según las
necesidades de la arquitectura, esto ayudará a que el sistema funcione de manera
óptima.
Tácticas de diseño
Las tácticas siempre van ligadas al atributo que va a satisfacerse, por ejemplo, si se
tiene que satisfacer el atributo de calidad de desempeño, se debe cambiar la demanda
de recursos, para lograrlo se tiene que incrementar la eficiencia computacional,
haciendo algoritmos más eficientes.
Se observa como los patrones y las tácticas se fusionan para resolver problemas de
diseño de software de manera que se satisfagan los atributos de calidad.
Frameworks
Todos estos frameworks son utilizados por los desarrolladores, para facilitar la
programación de funcionalidades de páginas web dependiendo del lenguaje de
programación elegido para las mismas.
Diseño de interfaces
Como arquitecto AVA estarás a cargo del diseño de la interface de usuario, ya sea
para un ambiente web o una aplicación celular, esta debe estar enfocada en la
experiencia e interacción del usuario, de esta manera se garantiza el éxito de la
plataforma.
Modelo del diseñador. Este combina las necesidades e ideas del usuario y
los materiales de los que dispone el programador, para diseñar la
interactividad de la plataforma.
Modelo del usuario. Se enfoca en el comportamiento del sitio realizando
pruebas de usabilidad.
Para lograr una interfaz de usuario exitosa se deben seguir estos principios:
Lección 03
Vista lógica
Para describir una solución web, una sola pista arquitectónica de un desarrollo es
complicada e insuficiente, por esto se formulan varias vistas.
Definición y propósito
Vista lógica. Esta se centra en los requisitos funcionales, es decir, lo que el sistema
debe brindar a los usuarios, para formar esta vista, se debe descomponer el sistema
en una serie de abstracciones primarias con el objetivo de transformar el problema en
objetos o clases de objetos, sirve para potenciar el análisis funcional del desarrollo y
para identificar elementos comunes en varias partes del sistema.
Es posible que la vista lógica de algunas aplicaciones solo tenga dos capas, sobre
todo si está orientada a servicios ya que la capa de lógica de negocio y persistencia, no
están delimitadas de forma clara.
Vista de procesos
Otra de las vistas que forma parte del modelo 4 más 1 es la física, esta se encarga
de los requerimientos no funcionales del sistema, el objetivo de la vista física, es
observar la distribución del software en el hardware, en esta se deben tomar ciertas
características como disponibilidad, confiabilidad, desempeño, escalabilidad, entre
otras más.
El sistema se ejecuta sobre varios nodos ya que deben ser relacionados con los
elementos de las vistas anteriores, es en esta etapa donde se deben especificar todas
las configuraciones físicas.
Otra de las vistas que forma parte del modelo 4 más 1 es la vista de desarrollo la
cual se centra en la organización real de los módulos de software.
Vista de escenario
La última vista del modelo 4 más 1 es el uso de un conjunto de escenarios, que son
instancias de casos de uso, esta vista relaciona las otras cuatro donde su propósito es
dar una perspectiva general del sistema con la cual se pueda validar su arquitectura.
Lección 04
Casos de uso
Los casos de uso son herramientas que te permiten capturar los requerimientos
funcionales de un sistema, también proveen una explicación gráfica de cómo se debe
usar y describen la interacción de los usuarios con el sistema que se va a desarrollar.
Los casos de uso pueden estar compuestos de diferentes escenarios ligados entre sí
para satisfacer el objetivo de un usuario. Por ejemplo, de un producto de una tienda
web, se tiene el siguiente escenario, el cliente busca en el catálogo de productos y
agrega al carrito aquellos que desea comprar después el cliente ingresa sus datos,
nombre, dirección, número de tarjeta y acepta su pedido, el sistema autoriza, confirma
la compra y de inmediato manda un email al usuario con los datos. Otros escenarios
son que la tarjeta del cliente no sea autorizada o que ya tengas guardados los datos de
compra de un cliente frecuente en el sistema.
Escribe el título del caso de uso, para este ejemplo, nómbralo como Principal
escenario exitoso, ya que corresponde a una compra que se realizará, escribe los
pasos es un secuencia numerada, para esto toma en cuenta los siguientes puntos,
cada paso es una interacción entre el usuario y el sistema, debes escribir las
intenciones del actor, no cómo lo hace, no describas la interfaz de usuario, coloca los
actores en un escenario y enlista las tareas que hace en esa función, escribe las
variantes que se tienen del escenario principal, en este caso las del cliente frecuente y
el rechazo de la tarjeta, para ello usa el mismo método del paso anterior.
Herencia. Indica que una o varias subclases heredan los métodos y atributos
de otra clase.
Composición. Modela objetos complejos donde el tiempo de vida del objeto
está condicionado por el objeto que lo incluye, también se le conoce como
relación estático por valor.
Agregación. También modela objetos complejos, solo que en este caso el
tiempo de vida del objeto incluido es independiente, a esta relación se le
conoce como estática por referencia.
Asociación. Es una relación simple no fuerte, esto significa que el tiempo de
vida de un objeto no depende del otro.
Uso. Representa una relación donde una clase tiene una instanciación que
es dependiente de otro objeto o clase, se usa continuamente para denotar la
dependencia que tiene una clase de otra.
Entre cada paso debes quitar los elementos redundantes o innecesarios. Por último
debes hacer una generalización, para buscar atributos y características comunes y una
especialización para buscar clases más detalladas.
Diagrama de secuencia
Además del diagrama de clases tipo UML otro de los diagramas más utilizados es el
de secuencias, ya que muestra cómo interactúan entre sí un grupo de objetos.
Identifica los escenarios, enlista las situaciones en las que quieres ver cómo
funciona el sistema para resolver algo.
Identifica los eventos externos, encuentra quién demanda que empiece un
escenario.
Modela las interacciones, construye el diagrama poniendo el escenario y los
actores como si se contara una historia.
Al finalizar el diagrama deberás ser capaz de saber qué pasa con todos los
elementos del sistema.
Diagrama de estados
Un diagrama de estados muestra los cambios que tendrá el objeto una vez que sea
programado para cumplir con su objetivo.
Ejemplo práctico
Usa el conector de inicio para marcar el proceso que realizará el objeto que para
este ejemplo es “Hacer una llamada”, ya que el estado inicial del teléfono es reposo, no
se escribe alguna acción, agrega una flecha de evento que represente la acción
descolgar, con esto, indicas la transición del estado de reposo al de tono, identifícalo
con un rectángulo, utiliza otra flecha que cumpla con la condición de marcar, para
pasar del estado de tono al de esperando, este estado puede tener dos eventos,
ocupado o llamando, dependiendo de lo que suceda puede haber dos nuevos estados,
tono ocupado o tono llamando respectivamente, en el caso de tono ocupado hay dos
eventos posibles, colgar y colgar y descolgar, el primero marca el fin del proceso con
un círculo parecido al de inicio mientras que el segundo regresa al estado de tono para
comenzar de nuevo.
Debes analizar de este modo cada estado del objeto y realizar cada cambio hasta
que el proceso regrese al estado inicial o se agote toda posibilidad de realizar alguna
acción.
Todo cambio debe pasar por el Comité de control de cambios que está conformado
por: Director del proyecto, Arquitecto del proyecto, Administrador del proyecto. Ellos
deben aceptar o rechazar el cambio tomando en cuenta la capacidad de ejecución del
nuevo requerimiento; al rechazar el cambio, deben proponer alguna alternativa de
solución o indicar en qué circunstancias, deben realizar dicho cambio.
Para ejecutar una modificación, el Comité de control de cambios, sigue estos pasos:
Fecha de aceptación
Nombre del proyecto al que pertenece
Módulo afectado
Programador responsable
Descripción del cambio
Justificación del cambio
Prioridad del cambio
Una vez que llega la solicitud de cambio al programador, éste debe realizarlo dentro
del código del programa, se recomienda avisar sobre el ajuste en los comentarios
dentro del código, se debe marcar el inicio del cambio, poniendo en comentario: inicio
del cambio, fecha de aceptación, proyecto al que pertenece, módulo afectado,
programador responsable. Al término de toda modificación se debe poner: Proyecto al
que pertenece, módulo afectado, programador responsable, fin del cambio.
Análisis de impacto
Brainstorming
Cuestionario o entrevista
Reuniones de grupo o focus group
Juicio de especialistas
El método a utilizar depende del presupuesto del proyecto, ya que para el método
cuantitativo generalmente utiliza software de paga, para realizar el procesamiento
matemático con el fin de obtener un modelo de riesgos.
Cada uno de los riesgos identificados anteriormente tiene una función que define su
probabilidad de ocurrencia, estas funciones son graficadas donde el eje X es el tiempo
del proyecto, y el eje Y la probabilidad de que ocurra el riesgo. Existen estas funciones:
Después de elegir la función, se debe elegir una variable que será afectada por la
ocurrencia de este riesgo, esa variable generalmente es económica cuando se habla
de proyectos web, por lo que se elige el valor actual neto VAN del proyecto. Se trata de
calcular el grado variación de la VAN con respecto a la probabilidad de ocurrencia de
este riesgo, este cálculo es dado por computadora y debe realizarse para cada riesgo
que se haya considerado, cada riesgo genera una variación diferente por lo que se le
otorga un nivel diferente a ese riesgo.
Muchas empresas tienen software de análisis de riesgos muy precisos, mismas que
se alimentan de la información que se captura en ellos, la consideración de este
software debe estar dentro del presupuesto de requerirse un análisis de riesgo más
profundo. Mientras más nivel tenga un riesgo, más observación y medidas preventivas
deben realizarse.
Mantenimiento de software
Es común que, una vez hecho el desarrollo del software y haber entregado un
producto final, tengas que dar mantenimiento periódico al mismo, ya sea para corregir
errores o agregar funcionalidades.
Nivel 04
Lección 01
Infraestructura de servicios de TI
Una vez liberado un sistema de software, debes preparar un plan para organizar su
infraestructura enfocándolo como un servicio.
Estrategia de servicio
La quinta etapa envuelve todas las anteriores, pues supone la mejora continua, y
como tal, trata de establecer como prioridad la necesidad del cliente para enfocar la
calidad y continuidad del servicio con mejoras progresivas.
Estrategia de servicios
Para definir la estrategia considera las cuatro P de Mintzberg, que indican las
prioridades:
Perspectiva. Disponer de metas y valores bien definidos y asumibles.
Posición. Definir y diferenciar los servicios, lo que ofrece el software.
Planificación. Establecer criterios claros de desarrollo a futuro.
Patrón. Mantener una coherencia en la toma de decisiones y acciones
adoptadas.
Diseño de servicios
Una vez claros los objetivos y analizados todos los aspectos, realiza el modelo de
procesos de negocio o BPM, observa el ejemplo:
Indica con el símbolo correspondiente, el inicio del proceso, apunta con una flecha
hacia el símbolo del evento “viernes a las 6 pm” para indicar que es una actividad
externa a la cual depende la acción de agendar, continua con el flujo de información,
con una flecha que apunta al rectángulo que contiene la primera actividad que vas a
realizar, en este caso “Revisar el estatus del grupo de trabajo”, crea con el símbolo
correspondiente, la condición que ayuda a verificar, si los miembros del equipo están
disponibles aquí el diagrama se termina con el símbolo correspondiente, si están
disponibles, crea la actividad de aceptar asistencia del evento y finaliza el diagrama,
señalando con una flecha el evento.
Diseña las métricas de calidad y monitoreo necesarias para llevar el control de los
siguientes rubros:
Transición de servicios
Una vez desarrollados los módulos de las mejoras o un nuevo sistema de software,
se deben integrar al sistema existente para que los usuarios los utilicen.
Para saber si realizaste una correcta transición, observa los siguientes indicadores:
Los clientes tendrán sus necesidades cubiertas realizando juntas con los
usuarios finales
La implementación de nuevas funcionalidades es más eficiente
Los servicios responden mejor a los cambios
Mejor control de riesgos y disposición de planes de contingencia, que eviten
una degradación del sistema
Mejor soporte del sistema con bases de datos y datos de configuración
actualizados
La actualización de la base de conocimiento, permite una mejor toma de
decisiones para futuras actualizaciones del sistema
Cada uno de los planes debe interactuar entre sí para prevenir errores en la
implementación del servicio. En esta fase debe estar involucrada toda el área de TI,
para recaudar toda la información pertinente y retroalimentar la documentación del
área.
Operación de servicios
Esta fase es sin duda, la más crítica de todas, pues es donde el sistema se pone en
funcionamiento, los principales objetivos son: