Arquitecto de ambientes virtuales de aprendizaje

Aprende a evaluar el impacto de la tecnología en el desarrollo de formación innovadora

creando arquitecturas de ambientes virtuales de aprendizaje para fomentar un desarrollo
integral.

El arquitecto AVA es el especialista de software responsable de tomar las mejores

decisiones para aprovechar la tecnología, en el diseño, desarrollo e instalación de
aplicaciones educativas, a través de esta capacitación desarrollarás:

 Habilidades y conocimientos tecnológicos que te permiten liderar la planeación

de ambientes virtuales.
 La capacidad para comunicar de manera sencilla las características de un
sistema de software.
 La capacidad de comprender el funcionamiento de una organización, para
dirigir el desarrollo del ambiente virtual al cumplimiento de sus objetivos.

También aprenderás a interpretar las necesidades y problemas de los usuarios y

conceptualizarlas en requerimientos para diseñar el ambiente virtual, conocer qué
cualidades del sistema deben alcanzarse y en qué medida, para cumplir con la
construcción de la plataforma en tiempo y forma, identificar y mitigar los riesgos asociados
a su desarrollo, usar las mejores metodologías y buenas prácticas para la planeación,
diseño, desarrollo, instalación y mejora continua en un ambiente virtual de aprendizaje.

Nivel 01
Lección 01
Arquitectura de software

Generaliza las diferentes actividades para realizar una 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:

 Estudia y analiza cada aspecto de la organización y los intereses de los

involucrados en el proyecto, así se tomarán las mejores decisiones.
 Averigua hasta el último detalle, esto te ayudará a facilitar el desarrollo
simultáneo de módulos o componentes y detectar errores antes de que su
impacto sea mayor.
 Dedica tiempo a la elaboración de modelos y esquemas que te permitan
visualizar de manera general el sistema y el funcionamiento de cada uno de sus
componentes, considera además del panorama actual que resuelve el sistema,
la visión a futuro de su crecimiento y mejora.
  Una arquitectura detallada te ayudará a resolver posibles discusiones y
cuestionamientos del software durante su gestión y precisar el costo y la
duración de su desarrollo.

Ciclo de desarrollo de la arquitectura de software (Infografía)

1. Requerimientos
2. Diseño
3. Documentación
4. Evaluación
5. Implementación

Medidas de seguridad y salud laboral

Conoce las medidas de seguridad y salud laboral.

Áreas de trabajo (Infografía)

 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.

Esta estructura te ayudará en la administración de proyectos en su crecimiento y

mejora continua.

 Desarrollo
 Implementación
 Control
 Mantenimiento de tecnologías de la información en forma de software

Lección 02
Ambientes virtuales de aprendizaje

Identifica las ventajas y desventajas de los diferentes tipos de ambientes virtuales de

aprendizaje.
 Un ambiente virtual de aprendizaje es una aplicación diseñada para facilitar la
comunicación pedagógica con el alumno, permitiéndole aprender a distancia o de manera
presencial. Tiene las siguientes ventajas:

En aplicaciones de escritorio, solo se necesita una computadora para acceder.

Al estar en la red se puede tener acceso remoto a través de internet.

El desarrollo de acciones educativas puede llevarse a cabo sin que los profesores o
alumnos coincidan en el mismo lugar.

Características de los AVA

Todo ambiente virtual de aprendizaje debe contar con las siguientes cuatro
características:

 Interactividad. Permite que la persona sea el protagonista de su formación.

 Flexibilidad. Se refiere a que la plataforma sea adaptable a diferentes
organizaciones donde se desee implementar.
 Escalabilidad. Asegura que la experiencia sea la misma con pequeños o
grandes volúmenes de usuarios.
 Estandarización. Permite exportar o importar cursos en formatos universales.

El ambiente AVA que implemente estas características, garantiza el éxito del objetivo
para el que fue creado y el logro de metas futuras.

Todo ambiente virtual de aprendizaje tiene dos dimensiones:

 La dimensión tecnológica representada por las herramientas informáticas con

las que está construida la plataforma, sus objetivos son: la publicación de
materiales, la comunicación con miembros del grupo, realización de tareas y
organización de la asignatura.
 La dimensión pedagógica, representada por el proceso de enseñanza y
aprendizaje que se desenvuelve dentro del ambiente virtual, este se basa en la
interacción que tiene el usuario a partir de la resolución de tareas didácticas, en
esta dimensión se concibe el diseño instruccional de los contenidos que
deberán ser abordados por la plataforma en cuestión, generalmente se
desarrollan las siguientes actividades:
 Selección del contenido adecuado para transformarlo en guiones.
 Videos, juegos y más.
 Creación de actividades para poner en práctica lo aprendido en las
clases.
 Creación de evaluaciones para verificar que el alumno haya aprendido.

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.

 B-learning. Consiste en un tipo de educación que combina las estancias

presenciales en aula junto con las estancias virtuales.
Todo el plan de formación debe estar contemplado entre estas dos opciones en
no menos de 25% para cada una, sólo así se considera dentro de este tipo de
AVA.
 Sistema de gestión de contenidos de aprendizaje (LCMS). Es un
espacio centralizado donde se deposita el contenido docente para
formación mixta (en línea o presencial).

 M-learning. Se defina como un medio de aprendizaje que se basa en la

recepción y entrega de contenidos electrónicos, se apoya en la tecnología móvil
y su objetivo es complementar los métodos de enseñanza. Está pensado,
principalmente, para consultar información de manera inmediata que facilite la
comprensión de un hecho en particular.

 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.

Etapas del aprendizaje

 Etapa sensomotora
 Etapa preoperacional
 Etapa de operaciones concretas
 Etapa de operaciones formales

Principios de diseño

Identifica los fundamentos que definen el diseño de la arquitectura de un software.

 Antes de comenzar con el diseño de una arquitectura, es necesario que aprendas
ciertas nociones clave a tener en cuenta, para lograr un diseño efectivo de sistemas de
software.

Un software monolítico es difícil de estudiar ya que su número de variables y

complejidad hace el código indecifrable y difícil de corregir o mejorar, por ello se
recurre a la modularidad que es la partición del sistema, facilitando así su desarrollo al
permitir la división del trabajo, sin embargo, partirla en muchos módulos haría crecer el
costo entre sus interfaces.

La abstracción es la capacidad de interpretar la realidad en un modelo

representativo, cuando se considera una solución modular, pueden formularse varios
niveles de abstracción, para que el modelo pueda ser lo más exacto posible.

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:

 La de datos. Permite obtener información que describe un objeto como su

nombre y tamaño.
 La procedimental, permite obtener una determinada secuencia de
instrucciones que tienen una función limitada y específica como mover,
caminar o correr, esto ayuda a representar un objeto a diferentes niveles de
detalle y dejar de lado lo que no es relevante.

La cohesión es un indicador cualitativo que mide la capacidad de trabajo coordinado

de sus elementos, para proporcionar algún comportamiento definido, conforme más
bajo sea su valor el módulo se vuelve más independiente e inservible, por ello se busca
que la cohesión sea alta, para que simplifique la modificación en el código.

El acoplamiento mide el grado en el que un módulo está conectado con otros y el

mundo exterior, para que sea óptimo y funcional, su valor debe ser bajo ya que de
nada sirve tener muchos caminos si no existe tránsito que pase por ellos.

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

Reconocer cuáles son los requerimientos de negocios entre las propuestas de la

mesa directiva y las necesidades del proyecto.

Un requerimiento es una especificación que describe alguna funcionalidad, atributo

o un factor de calidad de un sistema de software, puede describir también, algún
aspecto que restringe la forma en que se construye ese sistema.
 Por ello es importante considerar el nivel de importancia de los requerimientos:

 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.

Es importante que todos los involucrados en el proyecto aporten su visión para

lograr acuerdos que establezcan requerimientos de negocios alcanzables y realistas.

Requerimientos del usuario

Reconocer cuáles son los requerimientos del usuario entre las propuestas de la
mesa directiva y las necesidades del proyecto.

A partir de las reglas y requerimientos del negocio, podrás especificar los

requerimientos de usuarios, estos especifican los servicios ofrecidos a los usuarios
mediante el sistema de software, algunos de los principales requerimientos de usuarios
son:

 Fácil uso de las interfaces

 Calidad del contenido para una fácil comprensión
 Calidad de la experiencia de usuario usando la interfaz del sistema

Estos requerimientos se identifican por lo general mediante técnicas como casos de

uso o historias de usuario, usando buenas prácticas de las metodologías existentes
como el estándar UML, en el conjunto de los requerimientos de usuarios, se distinguen
dos tipos:

 Primario. Son requerimientos que describen servicios o funcionalidades que

los usuarios necesitan en el sistema y son clave para los procesos de
negocios, por ejemplo, debe haber máximo 10 cuentas de administrador, los
 usuarios sólo tienen acceso al contenido sin poder modificarlo, el portal debe
tener no más de 5 páginas de navegación.
 Secundario. Son las acciones necesarias que debe realizar el sistema pero
que puede prescindir de ellas en caso de falta de tiempo para ser
desarrolladas, por ejemplo, la pantalla de inicio debe contener un apartado
de noticias de última hora con respecto a los cursos, el portal debe tener los
colores del logotipo de la organización.

Estos requerimientos generarán diagramas de casos de uso que ayudarán a realizar

los requerimientos funcionales y no funcionales.

Requerimientos funcionales y no funcionales

Reconocer cuáles son los requerimientos funcionales y no funcionales 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.

El cliente o usuario final es tu fuente de información más grande para tu sistema, la

mesa directiva y el área de desarrolladores son la segunda fuente, ellos te permitirán
encontrar las funcionalidades de segundo rango de prioridad. Después realiza lo
siguiente:

1. Recopila las necesidades de los involucrados o Stakeholders del proyecto,

sintetízalas y verifica si una funcionalidad cubre una necesidad o más de
una.
2. Tradúcelas en funciones técnicas, para que los desarrolladores las analicen
y encuentren la mejor manera de desarrollarlas, ya que en ocasiones, éstas
requieren hardware, sistemas operativos, software de desarrollo y pruebas.
3. Verifica que el equipo de trabajo cuenta con las herramientas necesarias e
informa al propietario del proyecto el resultado del análisis, para obtener lo
que hace falta.
4. En caso de que los resultados muestren la insuficiencia de herramientas,
analiza si con el presupuesto se pueden cubrir y si requerirá más
financiamiento.

Estos requerimientos te servirán para definirlos de usuarios detallados donde se

baja aún más el nivel de desglose hasta llegar al nivel de estructura de datos y de
capacidad de hardware e infraestructura.

Requerimientos funcionales y no funcionales

 Los requerimientos se dividen en:

 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.

A veces no es fácil distinguirlos, por ejemplo, la seguridad puede ser un

requerimiento no funcional al principio, sin embargo, profundizar en su definición,
puede generar nuevos requerimientos funcionales, como la necesidad de autentificar a
los usuarios del sistema, que es un requerimiento funcional. Para poder definir
correctamente ambos tipos es necesario tomar en cuenta atributos de calidad que
corresponden adecuadamente con las reglas del negocio previamente establecidas,
entre los lineamientos principales están:

 Usabilidad. La facilidad con que una persona puede interactuar con el

software.
 Confiabilidad. Las fallas y tiempo de recuperación.
 Mantenibilidad. La capacidad de darle soporte al programa.
 Restricciones. En el uso de la plataforma, lenguajes y herramientas de
desarrollo.
 Seguridad. El nivel de protección de los datos, software y la plataforma
tecnológica ante la amenaza de pérdidas o actividades ilícitas.
 Disponibilidad. El período en que un sistema puede ser usado sin
interrupciones.
 Extensibilidad. La capacidad y facilidad de adquirir mejoras en el futuro.
 Escalabilidad. La capacidad del sistema o servicio TI, de tratar con el
crecimiento, por ejemplo, mayor número de conexiones o usuarios, no debe
confundirse con extensibilidad, que mide la capacidad del sistema de crecer
en funcionalidades.

Interfaces externas y restricciones

Además de depender de atributos de calidad, los requerimientos detallados

necesitan contemplar interfaces externas y restricciones que dependen de los
interesados externos en el proyecto, estos pueden ser desde proveedores hasta
licencias, los cuáles condicionan el desarrollo de las funcionalidades desde la
perspectiva temporal hasta la técnica, a partir de éstos, permitirá que los
requerimientos de usuarios detallados muestren las especificaciones precisas a nivel
técnico, estas comprenden desde el diseño de datos con modelos y diagramas, hasta
llegar a las especificaciones del código fuente, todo debidamente documentado y
anexado al documento general del proyecto.

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

Como arquitecto de ambientes virtuales de aprendizaje debes conocer los principios

relacionados con la arquitectura de software, tener un amplio conocimiento respecto a
la tecnología, contar con excelentes habilidades de comunicación oral y escrita que te
permitan desempeñarte como líder técnico en los proyectos, saber aplicar tus
conocimientos y habilidades para crear nuevas herramientas que faciliten el
aprendizaje.

Para realizar tus labores de manera efectiva, el proceso de trabajo te ayudará a:

1. Aprender las diferentes etapas de la administración de una organización, así

como sus distintas áreas y funciones dentro de esta.
2. Analizar a profundidad el proceso de negocio de las organizaciones.
3. Identificar y satisfacer las necesidades y requerimientos de todos los
involucrados en los proyectos de software de todos los niveles jerárquicos de
la organización.
4. Aplicar métodos y estrategias de ingeniería de software para la planeación,
modelado desarrollo y documentación de proyectos de software, aplicado a
ambientes virtuales.
5. Conocer las características de las tecnologías de la información para valorar
su utilidad dentro del proyecto de ambientes virtuales de aprendizaje y así
elegir las más convenientes para la organización.
6. Adquirir la capacidad de aplicar metodologías para la optimización del
trabajo.
7. Conocer métodos de evaluación de software para la realización de pruebas
de calidad.
8. Estar al tanto del avance tecnológico para saber aplicar nuevos paradigmas
y tendencias en la creación de nuevas herramientas que faciliten el
aprendizaje.

Visión y alcance

Aprende a redactar un documento donde definas la visión y el alcance del proyecto

para sincronizar el trabajo del equipo.

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.

En la primera sección como Introducción, debes definir el propósito de tu visión

como primer apartado, el cual es el objetivo del proyecto, después necesitas delimitar
claramente el alcance del proyecto, enlistando la serie de proyectos consecuentes, en
el siguiente inciso, debes revisar un diccionario de definiciones, acrónimos y
abreviaciones relevantes para el proyecto, con el fin de que todos los involucrados
comprendan las nociones, debes incluir las referencias a documentos que se anexan
en el mismo archivo, para facilitar la consulta rápida del documento es necesario que
incluyas un inciso con el resumen del contenido del documento visión; explica la
metodología de desarrollo de proyectos elegida en al menos una página para que al
menos conozcan el método de trabajo.

En el apartado Posicionamiento, se explican los aspectos de la organización y del

negocio como contexto para introducir el problema a resolver, en la definición del
problema, da una breve descripción y explica a quién afecta y cuál es el impacto de
este, en la posición del producto haz una revisión por cada involucrado citado en la
definición, para describir las cualidades que el sistema propuesto posee en contra de la
competencia, después debes mencionar a todos los involucrados en el proyecto, por
cada uno tienes que mencionar los siguientes datos: nombre, rol, tipo de usuario,
responsabilidades en el sistema, solo en caso de ser usuario directo en el sistema y
enlista las serie de actividades que realizaría con él, criterios de éxito para evaluar
desempeño, problemas clave donde se muestra la solución actual y el cambio que te
gustaría que el nuevo sistema desarrollara, involucramiento con el proyecto donde se
enlistan las responsabilidades como seguimiento de desarrollo, evaluación, entrega de
documentos y más, entregables aquí se enlistan todos los documentos que debes
entregar, para el correcto desarrollo del proyecto, asuntos incluye información extra
que puede ser relevante para el proyecto. En el último punto de la sección, describe el
entorno de usuario, donde se expone la estructura de la organización, a la que
pertenece el futuro usuario del sistema con un organigrama, además de mostrar
antecedentes, o sistemas relacionados que responden a la problemática.

Sección II Definición del alcance del problema

Aquí se describe la preparación del proyecto a desarrollar, en la primera parte,

describe los resultados del análisis del proyecto propuesto, el modelo de negocio
muestra la serie de procesos que el sistema debe llevar a cabo para lograr su objetivo;
en la perspectiva, describe cómo cambia el nuevo sistema el actual trabajo de los
interesados; enlista los beneficios y describe los componentes del sistema que lo
satisfacen; enlista los requerimientos que ya están listos y aquellos que dependen de
terceros; también se estiman ciertas cifras como el costo de producción de sistema
incluyendo dependencias externas, como patrocinadores, asimismo se contempla el
costo que el sistema tendrá para el cliente; haz otra lista con el número de personas
que se necesitan para su desarrollo, ingenieros de sistemas, redes y otros; contempla
el tema de las licencias del desarrollo para uso de software especializado; la
descripción del producto, se puede realizar por módulos, procesos o por el área de
problema a tratar; en las restricciones describe las limitaciones que el equipo de
desarrollo no puede modificar; si la organización ya utiliza estándares oficiales para
desarrollar procesos, se listan en el apartado de estándares aplicables; desglosa a
detalle los requerimientos funcionales y no funcionales, hasta llegar a los
requerimientos detallados que surgieron de la etapa de planeación, estos se clasifican
en tres principales para facilitar su consulta, en los requerimientos de desempeño,
mismos que debes desglosar, requerimientos de documentación anota la
documentación solicitada por los usuarios, requerimientos de ambiente son aquellos
requerimientos no funcionales que describen las condiciones para que el sistema
trabaje de manera adecuada y eficiente, como la temperatura, el ancho de banda el
hardware especializado y más; en el apartado de manual de usuario, explica la
disposición, formato y fechas de entrega del mismo con el fin de que sea revisado por
el cliente, incluye datos de contacto en caso de soporte, guías de instalación y
configuración; por último incluye un breve apartado de conclusiones y anexos para
explicar mejor el proyecto.

Este documento es indispensable para que comiences la planeación de la

arquitectura y el modelado de datos, ya que de este dependen que se lleven a cabo
eficientemente los procesos, evitando cambios y errores.

Lección 02
Definición de la arquitectura

Estructura los elementos que comprenden la 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:

 Aspectos del negocio, el costo de la arquitectura existente y el costo de

instalación de equipo nuevo, personal disponible.
 Aspectos de estructura organizacional, el análisis del impacto de conservar
algún recurso como bases de datos o servidores, esto depende del enfoque
del nuevo sistema, no realizar cambios en ningún proceso del negocio.
  Tendencias actuales, uso de tecnología especializada en la nube, uso de
interfaces o plataformas móviles.
 Tecnología disponible, sistema centralizado contra distribuido, desarrollo
interno, uso de servicios externos.

Metodología del modelado

Una vez que estos aspectos se acoplan a los requerimientos, se elige una
metodología de modelado de arquitectura entre las siguientes:

 Lenguajes de descripción de la arquitectura (ADLS), ayudan a describir de

forma sencilla el sistema en términos de componentes y arreglos.
 Diagramas UML, de aspectos estructurales o estáticos, como los de
componentes y despliegue, de comportamiento o dinámicos como los
diagramas de estado y secuencia.
 Diagramas de alto nivel, utilizan bloques que muestran un panorama muy
general de la estructura del sistema, por lo general es el primero en
realizarse y se va detallando con los demás modelos.

Para un arquitecto es fundamental no confundir los siguientes términos:

 Diseño arquitectónico. Se refiere a la estructura de un sistema general sin

involucrarse en detalles como algoritmos o estructuras de datos.
 Estilo arquitectónico, define las restricciones dentro de un grupo de diseños
arquitectónicos como centralizada, enfocada a servicios, secuencial, etc.
 Patrón arquitectónico. Es una guía que soluciona un problema particular de
impacto pequeño y comúnmente repetitivo.

Prepara adecuadamente la elección de la arquitectura, es indispensable para

comenzar con la planeación y el modelado, ya que estos dependen de un correcto
análisis de los modelos, estilos y patrones usados en los componentes para que se
lleven a cabo eficientemente y se mitiguen lo más posible cambios y errores.

Tipos de arquitectura

Evalúa las ventajas y desventajas de los diferentes 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:

Cliente-servidor. El sistema se descompone en servicios gestionados por

servidores, donde los clientes pueden visualizar los servicios, existen dos formas
diferentes:

 Cliente fino. El procesamiento de la información y la gestión de los datos se

realizan dentro del servidor, el cliente solo es responsable de visualizar el
resultado.
 Cliente grueso. El servidor solo realiza la gestión de los datos, el cliente
ejecuta el procesamiento y visualización de la información.

Arquitectura orientada a servicios (SOA), se accede a la información por medio

de interfaces de servicios web, los servicios web son una representación estandarizada
de la información por medio de la ejecución de algún programa, este recurso es alojado
comúnmente en un servidor para que pueda ser usado por otros sistemas, esto permite
que el servidor sea independiente de las aplicaciones que lo usan, lo que proporciona
diversidad de desarrollo.

Modelo Vista Controlador. Este estilo arquitectónico separa en tres la estructura

de los datos, la visualización y la lógica de la funcionalidad, es una modificación del
estilo cliente-servidor, el modelo gestiona la estructura y el comportamiento de los
datos responde a solicitudes de información y a instrucciones que se reflejan en el
almacenamiento de los datos el controlador interpreta acciones para facilitar
información al modelo o cambiar la vista, es el que realiza las funciones, la vista solo
sirve para ver la información y como interface para realizar acciones. Esta estructura
modular es muy conveniente en entornos web, permite una gran flexibilidad en el
desarrollo puesto que cambiar las vistas no repercute en la lógica y la estructura de los
datos y viceversa, de igual forma es muy adaptable a cambios, por ejemplo, la interfaz
puede modificarse para que su apariencia sea más llamativa, la desventaja de estos
estilos es la implementación de seguridad, ya que su estructura es más compleja que
un estilo aplicable a un sistema local que no está desplegado en internet, sin embargo
se compensa con su fácil aplicación y uso para el desarrollo, ya que permite un mejor
trabajo en equipo para los desarrolladores.

La elección de un estilo de arquitectura es indispensable para que comience el

modelado de los datos, ya que estos dependen de un correcto análisis de los
conceptos y componentes, para que se lleven a cabo eficientemente, y así evitar
cambios durante el desarrollo que repercuten directamente en las fechas de entrega
del proyecto.

Patrones de diseño

Identificar diferentes patrones de diseño.

 Una vez elegido el estilo de la arquitectura del sistema, debes elegir su 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.

Estructurales. Separan la interfaz del desarrollo, explican como las clases y

objetos, se agrupan para formar estructuras más grandes, algunos de los más
utilizados son:

 Patrón adaptador. Convierte la interfaz de una clase de programación en

otra, para agregar funciones, por ejemplo, la clase motor eléctrico adaptor,
modifica la clase motor, para que la clase motor eléctrico tenga
funcionalidades parecidas a las de motor pero mejoradas.
 Patrón decorador. Permite añadir funcionalidades a una clase de
programación existente, evitando la herencia sucesiva de clases que
incorporan nuevos métodos, por ejemplo, la clase vehículo mediante una
clase decorador permite agregar las funcionalidades de parrilla y GPS.

Comportamiento. Describen la comunicación entre objetos y clases, algunos de los

más utilizados son:

 Patrón Intérprete. Convierte un lenguaje a clase de programación compleja

en una más simple, por ejemplo, la clase instrumento, tendrá una clase del
tipo abstracexpression la cual permitirá interpretar los sonidos del
instrumento en notas y partituras.
 Patrón Observador. Notifica cambios de estado de un objeto para dividir sus
funcionalidades por ejemplo, la clase observador, reúne las diferentes
funciones de las clases ventana selección, ventana color y ventana
opciones, para que sean utilizadas por la clase principal.

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

Identificar y aplicar diferentes tácticas de diseño.

 Las técnicas de diseño son técnicas de las ciencias de la computación, que ayudan
a resolver problemas específicos en el software de manera que para cada evento que
llegue a nuestro sistema, la sumatoria de las tácticas empleadas dan una respuesta,
dentro de las restricciones contempladas, las tácticas se dividen en tres categorías
cada una con diferentes finalidades:

 Demanda de recursos. Aquí encontrarás las tácticas para incrementar la

eficiencia computacional, reducir la sobrecarga del comportamiento
computacional, administrar la tasa de muestreo.
 Administración de recursos. Para introducir concurrencia, mantener múltiples
copias, limitar tamaños de colas.
 Arbitrado de recursos. Las tácticas para establecer las políticas de
calendarización.

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.

Ventajas de las tácticas de diseño

Aumentan el desempeño de la solución, por ejemplo, en una página de ventas un

usuario envía una oferta cuando hay 2000 usuarios conectados, esta oferta es
procesada y transcurren en diez milisegundos, entre la petición y el envío de las
actualizaciones a los demás usuarios, para que esto suceda, la oferta debe aplicarse
en el momento en el que el sujeto solicita actualización de su estado de manera que
distintos usuarios puedan ser notificados de forma concurrente, así no habrá que
esperar hasta que un usuario termine de procesar la notificación de actualización, para
que el siguiente comience su trabajo, lo cual ayuda a aumentar el desempeño de la
solución, con este ejemplo, se observa que de las tácticas mencionadas se utilizan
introducir concurrencia y mantener copias múltiples, esta última se aplica guardando la
página de ventas en la memoria caché de cada usuario, para que de esta forma no sea
necesario tener que acceder a la base de datos para actualizarla.

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

Reconocer las características de diferentes frameworks para el desarrollo de

software.

Al codificar la plataforma AVA o las funcionalidades de la misma, podrás utilizar

frameworks, que son softwares que facilitan esta tarea.

Marcos de trabajo (Frameworks). Son elementos reutilizables de software que

proveen funcionalidades y se enfocan en la solución de un problema específico como
creación de interfaces de usuarios tanto locales como web, comunicación remota,
seguridad, reutilización, a pesar de que los frameworks son elementos de código se
consideran conceptos de diseño, pues su implementación es opcional. Los frameworks
implementan una variedad de patrones y tácticas, como ejemplo de ello son los
enfocados en la creación de interfaces de usuario, que frecuentemente implementan el
patrón llamado “Modelo Vista-Controlador”, que es la relación entre la interfaz de un
software y el controlador que interpreta las acciones del usuario. A pesar de que los
frameworks ofrecen soluciones que pueden ser utilizadas de forma más directa que los
patrones y las tácticas, estos tienen algunos inconvenientes, por ejemplo, pronunciada
curva de aprendizaje, dificultad de elección por la gran cantidad de ellos, evolución
constante y obsolencia rápida, la necesidad de incluir todo un framework aún si solo se
usa una parte, soporte limitado, cuando son frameworks poco populares o de fuente
libre.

No obstante es difícil imaginar un diseño de un sistema que no involucre una

variedad amplia de frameworks, los cinco frameworks más populares son:

 ASP.NET. Se utiliza con el lenguaje de programación C#.

 Angular JS. Se utiliza con el lenguaje de programación Javascript.
 Ruby on Rails. Se utiliza con el lenguaje de programación Ruby.
 JSF. Se utiliza con el lenguaje de programación Java.
 Django. Se utiliza con el lenguaje de programación Python.

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

Conocer diferentes tipos de 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.

Interfaces de usuario. El diseño de una interfaz de usuario es una actividad

multidisciplinaria que involucra especialistas en diseño gráfico, programación,
comunicación, etc. El objetivo es lograr que las aplicaciones sean atractivas e
interactivas, esto se logra con gráficos, pictogramas, combinación de colores y
simbologías especializadas para llamar la atención del usuario sin afectar el
funcionamiento técnico. El diseño de un sistema se enfoca en dos direcciones:

 Front-End. Se encarga de la presentación y de la interacción de la

plataforma.
  Back-End. Se encarga de la programación para la funcionalidad de la
plataforma.

El diseño de la interface se ubica en el Front-End que sigue estos modelos:

 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.

A partir de ambos modelos, el arquitecto decide cuáles funcionalidades .se pueden

realizar con los recursos de programación disponibles.

Principios para el diseño de interfaces

Para lograr una interfaz de usuario exitosa se deben seguir estos principios:

 Anticipación. Las aplicaciones deben adelantarse a las necesidades del

usuario.
 Autonomía. Se debe dar al usuario un ambiente flexible para que aprenda
rápidamente a utilizar la aplicación.
 Valores por defecto. La configuración predeterminada, debe permitir al
usuario fácilmente la interfaz.
 Modularidad. Permite el crecimiento de la plataforma de manera sencilla.

Toma en cuenta que diseñar tu interfaz siguiendo estos principios reducirá la

aparición de errores en las siguientes fases del proceso.

Lección 03
Vista lógica

Conocer las características de la 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.

Vistas arquitectónicas. Son descripciones de los componentes de un sistema, así

como de su comunicación e interacción. Se usan varias de estas para describir un
sistema de forma suficiente, la vista más usada en la de Philip Crushtein, que propone
un modelo de 4 más 1 vistas: Lógica, de procesos, física y de desarrollo.

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.

A nivel de arquitectura, una aplicación web se compone de tres capas:

 De presentación. Muestra los componentes que generan la interfaz de

usuario y su interrelación como los botones, imágenes y formas.
 De lógica de negocio. Maneja las reglas del negocio que permiten al sistema
cumplir con los requerimientos de los usuarios, como una validación de
pagos o una verificación de productos existentes.
 De persistencia. Tiene los componentes necesarios para garantizar la
duración y consistencia de los datos de la aplicación, el mejor ejemplo es el
sistema gestor de una base de datos.

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

Identificar las características de la vista de procesos.

La vista de procesos o comportamiento (Dinámica), es la segunda vista del modelo

4 más 1, es este vista donde se presenta la concurrencia y la distribución de los
procesos de la aplicación web lo que debe mostrar la vista de procesos, es la
interacción de los usuarios con la aplicación y de ésta con el servidor, debe especificar
el hilo de control donde se ejecuta la operación de una clase identificada en la vista
lógica, en esta vista se deben mostrar decisiones en los procesos y concurrencias con
bloques de describen actividades. Esta vista se divide en dos tipos de procesos:

 Los que son ejecutados por el servidor, normalmente son la mayoría de

procesos, como una petición HTTP al servidor.
 Los que son ejecutados por el cliente, son procesos ligeros como la
interacción con el navegador web.

Un ejemplo de una vista de procesos es la descripción de un usuario que interactúa

con el navegador web donde este traduce los eventos en peticiones HTTP al servidor y
después el servidor responde de forma HTTP, para que el navegador web, muestre las
respuestas en la página HTML.

Vista física (estática)

Identificar las características de la vista física.

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.

Componentes de la vista física.

Se dividen en dos partes, el cliente y el servidor.

Por el lado del cliente están:

 Navegador web. Aplicación que permite la organización de archivos en

HTML.
 Cliente grueso. Es la aplicación que reside dentro del cliente y procesa los
datos, los más conocidos son los Applets de Java.
 Aplicaciones externas. Que complementan la funcionalidad del sistema como
los visualizadores de pdf.
 Firewall. Es una protección para evitar el acceso no deseado a alguna red.

Los componentes por el lado del servidor son:

 Servidor Web. Es un programa que permite la transmisión de datos en

HTML, por medio del protocolo HTTP.
 Recursos HTML. Están en ese lenguaje y son enviados al cliente para ser
visualizados por el navegador.
 Servidor de bases de datos. Es un gestor encargado de administrar los
recursos de persistencia tanto de su acceso como manejo.
 Sistemas heredados. Son elementos que han quedado anticuados pero
siguen en funcionamiento.

Vista de desarrollo o implementación

Identificar las características de la vista de desarrollo.

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.

La vista de desarrollo es la organización real de los módulos del software en su

ambiente de desarrollo, su objetivo es dar un panorama de las capas del sistema y
puede tener las mismas que las de la vista lógica, su diseño depende del tipo de
desarrollo puede ser una aplicación web, una de escritorio, o algún tipo de servicio.

Los aspectos más importantes de una aplicación web son:

 Mapa de navegación. Da una vista general de las páginas y su relación.

  Administración de sesiones de usuario. Son controles de accesos con
diferentes permisos.
 Tecnologías para generar páginas de aplicación. Con ellas puedes crear
páginas dinámicas por medio de un lenguaje de programación.
 Técnicas de seguridad. Protegen los datos de los usuarios y limitan accesos.

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

Conocer las características de los 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.

Contenido de los casos de uso

Para generar el contenido de un caso de uso sigue estos pasos:

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.

La clave en la realización de casos de uso, es pensar en todas las condiciones

posibles de múltiples escenarios, solo así, la planeación quedará correctamente
documentada para las posteriores etapas de conceptualización.
 Diagrama de clases

Elaborar diagramas de clases.

El diagrama de clases UML es uno de los más usados en la planeación y desarrollo

de software, está compuesto por bloques y cada uno es una clase, tienen tres
divisiones donde se colocan datos en el siguiente orden: títulos, atributos y métodos.

En la programación orientada a objetos tanto los atributos como los métodos

pueden ser públicos, privados o protegidos. Otra de las cosas que describe un
diagrama de clases es la relación que hay entre ellas, esto se hace a partir de líneas
con flechas, tomando en cuenta la cardinalidad de las relaciones. Como las relaciones
van alineadas con el paradigma orientado a objetos se dividen en cinco tipos:

 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.

Para diseñar un diagrama de clases debes identificar:

 Los objetos y clases

 Sus tributos y funciones
 Sus asociaciones y agregaciones
 Las relaciones de herencia

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.

Composición del diagrama

 El diagrama de secuencia cuenta la historia de la ejecución de un programa a través
de: Objetos en forma de bloque donde se incluye el nombre y la clase, un mensaje
entre éstos, una barra vertical que muestra su tiempo de vida, un actor, la forma en que
se representa el envío de los mensajes puede ser:

 Síncrono. Donde el objeto pierde el control hasta recibir respuesta.

 Retorno. Es la respuesta a un mensaje previo.
 Directo. El originario no espera respuesta, pero pasa el control.
 Asíncrono. El originario no espera respuesta, y permanece activo.

Es importante que tengas siempre presente, la diferencia entre una clase y un

objeto.

Construcción del diagrama

Para construir un diagrama de secuencia sigue estos pasos:

 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

Elaborar diagramas 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

Para poder realizar un diagrama de estado, haz lo siguiente:

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.

De este modo tendrás descrito y documentado el panorama completo del proceso,

para que sea desarrollado por los programadores, también te servirá de referencia para
realizar alguna actualización.
 Nivel 03
Lección 01
Cambios al desarrollo

Aplica metodologías para realizar cambios al desarrollo.

En el desarrollo de una plataforma, suelen surgir cambios que deberás analizar,

validar, o rechazar y documentar. Para realizar estas gestiones existe la gestión de
cambios, tiene el objetivo de controlar las modificaciones que sufre la plataforma que
construye un equipo de programación, hay cuatro fuentes fundamentales de cambios a
un desarrollo:

 Nuevos negocios o condiciones comerciales

 Nuevas necesidades del cliente
 Reorganización del negocio
 Restricciones de presupuesto

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:

 Evaluación del impacto

 Búsqueda de alternativas
 Aprobación por parte del comité
 Ajuste al plan del proyecto
 Notificación a los interesados
 Gestión del proyecto de acuerdo al nuevo plan

Cada cambio debe estar sujeto a las Normas Empresariales de Comunicación,

siempre tiene que haber una solicitud de cambio impresa y firmada por el responsable
o por correo electrónico, para que se realicen las modificaciones correspondientes.
Esta solicitud o correo debe contener lo siguiente:

 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.

De esta manera se lleva un control de las modificaciones al proyecto en términos de

software y desarrollo.

Análisis de impacto

Aplicar buenas prácticas para el análisis de impacto.

Después de haber identificado y clasificado los cambios en una plataforma, se debe

realizar el análisis de los riesgos que puede sufrir el sistema en desarrollo, esto permite
estudiar las posibilidades y las consecuencias de cada uno de los cambios para
otorgarle un nivel de riesgo al proyecto AVA.

Métodos de análisis de riesgos

Existen dos métodos para determinar el nivel de riesgo de cualquier proyecto:

Método cualitativo. En este la toma de decisiones, se base completamente en el

juicio, la experiencia o la intuición, generalmente se utiliza cuando el riesgo es bajo y
no se justifica un análisis completo. Las metodologías cualitativas son las siguientes:

 Brainstorming
 Cuestionario o entrevista
 Reuniones de grupo o focus group
 Juicio de especialistas

Método cuantitativo. Permite asignar valores de ocurrencia a los diferentes riesgos

identificados mediante un modelo matemático de registros. Todo método cuantitativo
realiza un análisis de probabilidad.

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.

Modelos de riesgos. Esta es una representación de la realidad a través de una

estructura de cálculos matemáticos, en la cual se detectan variables significativas de
riesgos que se miden con base en las variables económicas. Para desarrollar este
modelo se deben seguir estos pasos:

 Selección de funciones de probabilidad

 Identificación de variables económicas
 Selección de funciones de probabilidad

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:

 Triangular. Se conocen valores máximos y mínimos de la probabilidad, esta

función considera por ejemplo, la probabilidad de que las ventas bajen.
 Uniforme. Se conoce el valor máximo de la probabilidad, riesgos como la
probabilidad de renuncia de profesionales son considerados por esta
función.
 Discreta. Se conocen diferentes valores posibles de probabilidad.

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

Aplicar buenas prácticas y metodologías para el 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.

Objetivos del mantenimiento de software

De todo el desarrollo de software, el mantenimiento es la última etapa y está

enfocada a asegurar que el producto, siga funcionando a través del tiempo, para
lograrlo, el mantenimiento contempla:

 Corregir los errores que lleguen a surgir en versiones de producción.

 Agregar nuevas funcionalidades con el fin de alargar el ciclo de vida del
software.
 Eliminar funciones obsoletas, es decir, versiones viejas de algunos objetos
del software que solo ocupan espacio en memoria.
  Optimizar el software usando objetos más eficientes, estos deben ser
implementados en todos los desarrollos del mismo.

Todo desarrollo de software debe estar basado en la adaptabilidad, de lo contrario,

un cambio puede ocasionar graves daños al mismo.

Mantenimiento preventivo de software

Muchos de los problemas encontrados en un desarrollo no derivan del software en

sí mismo sino del hardware que lo contiene, es por ello que debe seguir estos pasos,
para no agregar problemas al desarrollo.

 No descargues software de internet, música, videos o juegos

 Mantén actualizado el antivirus de la PC
 Realiza acciones de limpieza y escaneado en busca de virus cada seis
meses
 No abras archivos adjuntos en correos de remitentes desconocidos
 Verifica que todas tus herramientas de software estén actualizadas en la
última versión liberada por el fabricante.

Realizar un mantenimiento al software y al hardware es esencial para asegurar el

ciclo de vida de desarrollo, además las correcciones o adaptaciones que realices te
servirán para preparar un nuevo lanzamiento del producto creado, conocido como
“lanzamiento de mantenimiento” que resolverá problemas pendientes.

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

Primera etapa – Estrategia del servicio

La primera etapa es la estrategia del servicio, donde se explica cómo diseñar,

desarrollar e implantar su gestión como un activo, estratégico que aportará valor
económico y de reconocimiento al negocio.

Segunda etapa – Diseño

La segunda etapa es el diseño, en ella se plantean guías que ayuden a desarrollar

la gestión del servicio; se establecen principios y métodos para convertir la estrategia
en servicios y activos.

Tercera etapa – Transición

 La tercera etapa es la transición, aquí se desarrollan y mejoran las capacidades
para llevar a producción servicios nuevos o las mejoras que se han agregado desde la
estrategia.

Cuarta etapa – Operación

La cuarta etapa es la operación, donde se crean guías para la eficiencia y

efectividad en la entrega y soporte del servicio. Convierte la estrategia en una
capacidad o funcionalidad.

Quinta etapa – Mejora continua

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

Conocer las buenas prácticas para la creación de estrategias de servicios.

Un sistema de software se convierte en un servicio cuando sus funcionalidades se

despliegan a través de un medio como internet.

Características de una buena estrategia

Una correcta estrategia de servicio debe:

 Servir de guía estableciendo y priorizando objetivos y oportunidades

 Conocer los servicios de la competencia
 Armonizar la oferta con la demanda de los servicios
 Proponer funcionalidades a los servicios que destaquen del resto de la
competencia
 Gestionar los recursos y capacidades necesarios para prestar los servicios,
tomando en cuenta los costos y riesgos asociados
 Alinear los servicios ofrecidos con la estrategia de negocio
 Elaborar planes que permitan un crecimiento sostenible
 Crear casos de negocio para justificar inversiones estratégicas
 Adaptar la utilidad ofrecida a las necesidades reales del cliente y aumentar
su rendimiento
 Asegurar que el servicio se presta de forma continua, preservando la calidad
y cumpliendo con los estándares de seguridad y objetivos
 Evitar la pérdida de control en los procesos, costos ocultos y una calidad
inferior a la prometida

Cómo definir una estrategia

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

Conocer las buenas prácticas para el diseño de servicios.

El diseño de servicios tiene como objetivo modelar las funcionalidades o modificar

las ya existentes, para adecuar el sistema de software, a las necesidades de los
usuarios, para que el diseño cumpla con dichas necesidades, debe:

 Considerar la estrategia de servicio

 Adecuarse a las necesidades actuales
 Ser rentable y eficiente
 Cumplir los estándares de calidad adoptados
 Aportar valor a los usuarios para diferenciarse de la competencia
 Equilibrar funcionalidad y calidad

Pasos previos al desarrollo

Antes de desarrollar el diseño, ya sea para implementar nuevas funcionalidades o

modificaciones:

 Ten claros los objetivos del sistema

 Defina y analiza las funcionalidades de los módulos
 Compara la documentación y pruebas del software existente para averiguar
si existen módulos reutilizables
 Lleva un control de costos y retorno de la inversión
 Analiza los recursos y capacidades de desarrollo involucrados
 Considera la contratación de recursos externos
 En caso de ser un servicio o módulo nuevo, incluye un análisis de la
arquitectura usada y de la que vas a desarrollar, para ello ajusta las
tecnologías usadas al objetivo del negocio, aplica la infraestructura TI
necesaria, gestiona las aplicaciones, gestiona los datos y la información,
analiza la documentación y el software existente, considera los planes de
liberación del servicio.

Desarrollo del diseño

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:

 Proceso. Realización de actividades calendarizadas

 Cumplimiento. Adecuación a las políticas y requisitos predefinidos
 Eficacia. Calidad de los resultados obtenidos
 Rendimiento. Productividad de los procesos y gestión de los recursos
utilizados

Una vez terminado adjunta cada esquema al documento de la estrategia.

Evita confundir esta metodología con la planeación de un sistema de software, pues

son enfoques diferentes.

Transición de servicios

Aplicar una buena metodología para la 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 cumplir adecuadamente con esta transición:

 Crea un plan para el proceso de cambio

 Usa entornos de pruebas y preproducción necesarios
 Realiza pruebas necesarias para asegurar la adecuación del nuevo servicio
a los requisitos predefinidos
 Establece planes de despliegue y retorno a la última versión estable en caso
de fallas
 Cierra el proceso de cambio con una detallada revisión post-implementación

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

Identificar con buenas prácticas una correcta 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:

 Coordinar e implementar todos los procesos, actividades y funciones

necesarias, para la presentación de las nuevas funcionalidades del sistema
acordados con los niveles de calidad aprobados.
 Dar soporte a todos los usuarios del sistema
 Gestionar la infraestructura tecnológica necesaria para la presentación de los
nuevos módulos o funciones del sistema.

Pasos de la fase de operación

Para realizar correctamente la fase de operación, haz lo siguiente:

 Busca un equilibrio entre estabilidad y capacidad de respuesta, la estabilidad

es necesaria pues los usuarios requieren disponibilidad y muestran
resistencia al cambio, por otro lado las necesidades del sistema o tendencias
tecnológicas cambian rápidamente y eso requiere habitualmente rapidez en
las respuestas.
 Evita los problemas de inestabilidad, adoptando una actitud proactiva que
permita dar respuestas a las nuevas necesidades de forma progresiva.
 Evita el uso de una actitud reactiva, ya que provoca que los cambios solo se
implementen cuando la organización tiene un estado de urgencia, esto no es
una correcta planificación del cambio.
 Encuentra un correcto equilibrio entre la gestión interna que intenta mantener
la tecnología y recursos humanos necesarios para el funcionamiento del
servicio y las necesidades de los usuarios.
 No comprometas al área de TI, para prestar servicios faltantes.
 No excedas la infraestructura TI, encareciendo innecesariamente el costo de
los servicios.
 Esta fase es la más susceptible a errores por tal razón, las observaciones que los
usuarios brinden deben documentarse perfectamente por el área de TI para llevar un
correcto funcionamiento.

Mejora continua de servicios

Aplicar metodologías para la mejora continua de servicios.

La mejora continua consiste en adaptar el sistema y sus servicios a las necesidades

cambiantes de los usuarios. Esta debe permitir mayores retornos a la inversión y la
satisfacción del usuario.

Objetivos de la mejora continua

Se resumen en los siguientes puntos:

I. Monitorizar y analizar los parámetros de seguimiento del sistema, algunos de

estos son:
 Conformidad. Los procesos se adecúan a los nuevos modelos y reglas.
 Calidad. Se cumplen los objetivos preestablecidos en plazo y forma.
 Rendimiento. Los procesos son eficientes y rentables para la organización.
 Valor. El servicio es mejor que el de la competencia y se refleja en la
presencia y lealtad de los usuarios.
II. Incrementar el número de los usuarios conformes con el servicio y la calidad
III. Dar soporte a los usuarios con retroalimentación a la fase de estrategia y
diseño para la definición de nuevos módulos o funciones.

Para el control y monitoreo, utiliza primero el Ciclo de Deming:

 Define los objetivos y los medios para conseguirlos

 Implementa la visión preestablecida
 Comprueba que se llegue a los objetivos con los recursos asignados
 Analiza y corrige las desviaciones detectadas y promueve mejoras a los
procesos utilizados

Etapas de la mejora continua

Si el sistema necesita una actualización, realiza los siguientes pasos:

1. Clasifica las métricas para conocer si se ha alcanzado la calidad y el rendimiento

en:
 Tecnológicas. La capacidad, disponibilidad y el rendimiento de las
infraestructuras y aplicaciones
 De procesos. El rendimiento y calidad de los procesos de gestión del sistema
como un servicio de TI.
 De servicios. Que evalúan los servicios ofrecidos en términos de
funcionalidad.
2. Define las métricas mediante factores críticos de éxito, los aspectos cualitativos
y cuantitativos de los indicadores para evaluar los factores críticos de éxito. Por
ejemplo: Si la organización se ha propuesto como factor crítico la mejora en la
atención al usuario, los KPI incluirán tiempo medio de resolución de los errores,
adecuación de los procesos de crecimiento de la demanda del sistema,
observaciones de los usuarios respecto a la atención prestada mediante
encuestas.
3. Recopila los datos necesarios, la materia prima compuesta de mensajes sin
procesar, por ejemplo, número de usuarios del sistema y su edad.
4. Procesa los datos, siguiendo el ejemplo, sería una estadística del rango de
edades del alcance del software.
5. Analiza los datos, interpreta la información en términos de experiencia y
reflexión, por ejemplo, algunos usuarios involucrados en servicio clave, corren
riesgo por no adaptarse a las mejoras del sistema.
6. Propón medidas correctivas, toma la mejor decisión basada en el conocimiento,
información y datos disponibles, por ejemplo, opta por mejorar la interfaz del
sistema para minimizar las pérdidas asociadas a los usuarios que no se han
adaptado al sistema de software.
7. Implemente las medidas correctivas, genera los informes que permitan evaluar
los servicios ofrecidos y los resultados de las mejoras propuestas. Recopila la
información que retroalimente al área de desarrollo.

La mejora continua involucra el diseño, la transición y la operación, ya que, además

de mejorar los procesos de la organización que ofrece el servicio, ayuda a la
evolución del sistema.

Difusión del AVA

Aplicar buenas prácticas para la difusión de los ambientes virtuales de aprendizaje.