Etapas del proceso desarrollo de software:

• Análisis de Requerimiento: Se entiende qué se tiene que contruir, requerimientos funcionales y

no funcionales. El resultado es una comprensión muy clara del problema al resolver.
• Diseño de la Solución: Un equipo de desarrollo plantea cuales son las posibles soluciones al
problema. Y el resultado es un detalle de la solución en el formato que tenga que ser dado.

• Desarrollo y Evaluación: Desarrollo y testing, existen criterios de aceptación para la solución. El

resultado es un Artefacto de Software.

• Despliegue: Se necesitara infraestructura para la realización de Operaciones. El resultado de esto

es el Software Disponible.

• Mantenimiento y Evolución: Se detectan errores y se agregan funcionalidades. Cuando termina

el Software queda deprecado.

Dificultades en el desarrollo del Software

Se dividen en 2 tipos de problemas:

Esenciales: Especificación, diseño y comprobación del concepto

Accidentales: Detalles de la implementación y producción actual

Esenciales

Complejidad: Cuando el problema a resolver es complejo en sí mismo.

Conformidad: Entender en que contexto se usará el producto y como se adecuada al contexto

imperfecto (Ejemplo: ¿Requiere internet, que disponibilidad existe de Internet?, ¿Requiere
actualizaciones mayores?)

Tolerancia al cambio: La medición de cuanto podemos adaptarnos a los cambios.

Invisibilidad: Dificultad de entender su forma, ya que es intangible, solo existen en código o

documentación
Accidentales

Lenguajes de alto nivel: Dificultad de dominar el stack tecnológico.

Entornos de desarrollo: Las dificultades expuestas por software de desarrollos, editores de

textos, IDE’s, herramientas de terceros.

Las Metodologías Ágiles Redifinieron los Roles para acomodarlos a su filosofia de Trabajo
(Tradicional vs Metodologías Ágiles).

Experto de Dominio: (tradicional) Era la persona que acudiamos para resolver las necesidades de
los REQUERIMIENTOS{Que se requiere para este Software}

Experto de Dominio: (Metodologías Ágiles) Hace un analisis de los stakeholders (Que resolver de
su Producto?)

Analista (Tradicional): Es la Persona que indaga en Que es lo que hay q resolver, define un
problema…

Analista (Metodologías Ágiles): Es la persona que define los requerimientos es El Cliente, el va ir

definiendo como sera el software a medida Cual es su Problematica.

Administrador de sistemas (Tradicional): Se encargaban de toda la operacion del sistma(Si había

servidores, actualizar librerias, Encontrar Errores en los logs y dar el Feedback al equipo de
desarrollo)

Administrador de sistemas (Metodologías Ágiles) Fue reemplazado por el DevOps (Operaciones y

Desarrollo unidos) Es la persona Responsable de Entender la Infraestructura a la que va nuestra
app y Entender los Requerimientos de ese lado del mundo
Administrador de sistemas (Metodologías Ágiles) Fue reemplazado por el SRE (Ing de la Confianza
del Sitio) es similar al Administrador de Sistemas pero Conectando el mundo de sistemas con el
mundo del dia-dia de la app

QA - Equipo de Texting (Tradicional): Evaluación de Software

QA - Equipo de Texting (Metodologías Ágiles): Fueron Unidos en un Solo Equipo de Desarrollo (QA-
Tester, Desarrollador, Aquitecto) Se Encarga de Tomar las decisiones arquitectonicas (La
arquitectura Emergera de un Equipo Autogestionado)

Gestor del Proyecto (Tradicional): Se ecargaba de todo lo que era la entrega, Cumplir con toda la
gestion del ciclo de Vida del Proyecto

Gestor del Proyecto (Metodologías Ágiles): Se conoce como Facilitador (SCRUM Master) lleva al
equipo atraves de el ciclo de (Entender que es lo nos Para)

Arquitectura de Software es:

“La estructura del sistema, compuesta por elementos de software, sus propiedades visibles y sus
relaciones”

Software Architecture in Practice

“El conjunto de decisiones principales de diseño tomadas para el sistema”

Software Architecture: Foundations, Theory and Practice

Les dejo mi resumen.

Cada uno de los stakeholder tiene que ser conectado por el Arquitecto con sus requerimientos.

Stakeholder -> Arquitecto -> Requerimientos = Implementaciónes en el Sistema.

Los Requerimientos de cada stakeholder afectan de forma única el sistema.

Cliente: Entrega a tiempo y dentro del presupuesto.

Manager: Permite equipos independientes y comunicación clara.

Dev: Que sea fácil de implementar y de mantener.

Usuario: Es confiable y estará disponible cuando lo necesite.

QA: Es fácil de comprobar.

La unión de todos estos requerimientos (funcionales o no funcionales) van a llevar al arquitecto a

tomar decisiones que impacten sobre el sistema.

La arquitectura nace en metodologías tradicionales en donde su objetivo era principalmente

encontrar los problemas y diseñar una solución a gran escala que ataque a esos problemas
esenciales, como también a los de alto riesgo del desarrollo a realizar.

Las metodologías Agiles plantean que la arquitectura emerge de un equipo auto-gestionado y por
ende ven al diseño de una solución como algo evolutivo y que se va dando de sprint a sprint.
Diferencias:

Tradicional: En la etapa de diseño es donde se tiene la definición del problema, requerimientos,

restricciones y riesgos todos

estos son los agentes que van ayudar al arquitecto a tomar decisiones, el arquitecto contara
con herramientas de diseño para poder

tomar esto como entrada, para luego tener un modelo de la arquitectura y la documentación
para implementar ese modelo, la etapa de diseño no

implementa software, sino que le da a la etapa de desarrollo las herramientas para

implementar lo que se analizó, al modelo tradicional lo que le falta

es el feedback ya que el arquitecto no tiene nociones de lo que el sistema ya hace y como el

usuario interactúa con ese sistema, hasta que el arquitecto no

hace toda esa solución y la solución no se implementa y se despliega no se tiene feedback de

como esas decisiones son tomadas o si son buenas decisiones.

Agile: En la metodología ágil todo se trata de momentos en donde podemos evaluar o reevaluar
nuestras decisiones, esto se realiza en el planeamiento del spring que es donde planeamos los
momentos arquitectónicos importantes. Una vez planeado el spring y se define lo que se tiene que
definir arquitectónicamente se ejecuta en base a las prioridades que se tienen y luego se le lleva al
usuario haciendo el despliegue y gracias a eso se obtiene feedback, cabe destacar que una vez que
se obtiene feedback se pueden reevaluar las decisiones de la arquitectura.

El problema:

El espacio del problema

Detalla que es lo que se va a resolver sin entrar en detalles del “cómo”.

El espacio de la solución
Brinda el detalle del “cómo”, reflejando los detalles del problema detectado, evitando resolver
problemas que no se quiere resolver.

Los Requerimientos

Una vez que entendemos el espacio del problema y el espacio de la solución, vamos a entrar a
analizar los requerimientos de nuestro sistema.

Requerimientos de producto

Los podemos dividir en tres (03):

• Capa de requerimientos de negocio, son reglas del negocio que alimentan los requerimientos del
negocio.

• Capa de usuario, tienen que ver en cómo el usuario se desenvuelve usando el sistema, qué
atributos del sistema se deben poner por encima de otros.

• Capa Funcional, se ven alimentados por requerimientos del sistema, ¿qué cosas tienen que pasar
operativamente?

Esta capa se ve afectada por las restricciones que pueden afectar operativamente a lo funcional.

Requerimientos Significativos para la Arquitectura del Producto:

• Requerimientos funcionales: (Funciones indispensables) Tienen que ver con las historias de
usuarios, que hablan sobre específicamente lo que hace el sistema, por ejemplo que usuario
ingrese al sistema.

• Requerimientos no funcionales: (Atributos de calidad): son aquellos que agregan cualidades al

sistema, por ejemplo que el ingreso de ese usuario sea de manera segura.

Requerimientos de proyecto

• Tienen que ver más con el rol de gestor de proyectos, se usan para dar prioridad a los
requerimientos del producto.
• Estos dos mundos de requerimientos hablan de las prioridades del equipo de trabajo del
proyecto.

• Tiene que ver con requerimientos logísticos, que no tienen que ver con el desarrollo del
software.

Los Riesgos

Es necesario identificar los riesgos para poder priorizarlos y atacarlos en orden y asegurar que las
soluciones arquitectónicas que propongamos resuelvan los problemas más importantes.

Identificación de los riesgos:

• Toma de Requerimientos (Requerimientos funcionales):

Se calificará su riesgo de acuerdo a su dificultad o complejidad.

• Atributos de calidad (Requerimientos NO funcionales):

Se calificará su riesgo de acuerdo a la incertidumbre que genere, cuanto mas incertidumbre hay,
mas alto es el riesgo.

• Conocimiento del dominio:

Riesgo prototípico, son aquellos que podemos atacar de forma estándar.

Pregunta de examen:

Los riesgos hay que identificados para poder priorizarlos, recuerda que no es necesario mitigarlos
todos, debemos siempre tener en cuenta y dar prioridad a aquellos riesgos que ponen en peligro
la solución que se está construyendo.

Las Restricciones
Las restricciones en el contexto de un proceso de desarrollo de software se refiere a las
restricciones que limitan las opciones de diseño o implementaciones disponibles al desarrollar.

Los StakeHolders, nos pueden poner limitaciones relacionadas con su contexto de negocio,
ejemplo:

• Las limitaciones legales, la implementación de un producto podría tener restricciones en algún

país, y esto seria una limitante a considerar para el desarrollo del producto.

• Limitaciones técnicas, relacionadas con integraciones con otros sistemas.

• El ciclo de vida del producto, agregará limitaciones al producto, por ejemplo a medida que
avanza el proceso de implementación el modelo de datos va a ser más difícil de modificar.

Nota:

El arquitecto debe balancear entre los requerimiento y las restricciones.

Apuntes:

Arquitectura, panorama y definición

Panorama Arquitectónico

Hay muchas librerías, muchos frameworks, mucho conocimiento arquitectónico implícito entre las
comunidades.

¿Qué es un estilo de arquitectura?

Cuando hablamos de estilo de arquitectura hablamos de algo genérico.

Un estilo de arquitectura es una colección de decisiones de diseño, aplicables a un contexto
determinado, que restringen las decisiones arquitectónicas específicas en ese contexto y obtienen
beneficios en cada sistema resultante.

_Software Architecture: Foundations, Theory and Practice (Taylor, 2010)

Les dejo mi resumen:

Programa principal y subrutinas: Es el estilo más básico donde se tiene una rutina y se manda a
llamar otra subrutina en donde la subrutina puede retornar o no un resultado, pero la rutina
principal continua hasta que acabe la subrutina.

Orientada a Objetos: Una versión con esteroides del estilo anterior. Se utiliza para aplicaciones
que vamos a mantener por mucho tiempo. Tratamos de juntar el estado de la aplicación creando
objetos los cuales tienen una interfaz publica (interfaz en este caso se refiere a una definición de
funciones o estructura que esta clase puede implementar) donde la llamada no es solo una
subrutina, sino objetos que interactuán entre si.

Arquitectura multinivel: Son diferentes componentes que se van a comunicar en un orden en

especifico donde un componente principal crea el llamado a un componente inferior en algún
momento, un ejemplo de esto son las aplicaciones cliente-servidor.

En este caso no estamos tan preocupados por cual es la secuencia de ejecución sino como los
datos fluyen de un punto a otro.

Flujo de datos:
• Lote secuencial: Lo importante es ejecutar una pieza de código y que el final de esa pieza ya
procesada pase a una siguiente etapa.

• Tubos y filtros: Se tiene un string o un flujo de datos continuo en donde cada aplicación recibe
continuamente esos datos los procesa y los hace como salida a otra aplicación o al final de la
ejecución.

Nota:

En el estilo de flujo de datos lo que se tiene son diferentes aplicaciones que van a estar conectadas
en general en tiempo real por lo tanto ya no se necesita interacción con el usuario para decidir
cuándo empieza un proceso o cuando termina otro.

Cuando usamos el estilo de arquitectura de flujo de datos:

• Cuando tenemos un proceso que tiene que tener una salida clara pero que puede ser separado
en partes en donde tenemos parte a parte lo que necesitamos hacer.

• Cuando necesitamos un string de entrada parte a parte ir procesándolo y tener una salida al final
del túnel.

ESTILOS: CENTRADAS EN DATOS.

Estilo de pizarrón, permite centralizar los datos en una sola base de datos, alimentada por varias
partes involucradas, una vez que todas las partes interesadas ingresan los datos, el sistema
centralizado genera una salida.
Estilo Centralizado, En este caso el sistema posee los datos centralizados en una base de datos, y
hay dos (02) sistemas que comparten la misma base de datos.

Estilo Experto, En este caso el sistema que centraliza los datos, tiene la capacidad de entender los
datos y consultas que realiza el cliente, generando salidas inteligentes. (inteligencia artificial).

COMPONENTE INDEPENDIENTES

Invocación implícita: Tiene que ver con que nuestra aplicación puedan mandar mensajes entre si,
sin que sepa a quien le esta hablando.

Invocación explícita: Tiene que ver con el desarrollo de componentes que si se conocen entre si,
pero que sean desarrollado independientemente.

ARQUITECTURA ORIENTADAS A SERVICIOS:

El Enterprise Services Busses, sabe que proceso tiene que llevar a cabo para lograr su cometido,
dando a los componentes la información que éstos requieran. El ESB, es inteligente.

Es necesario tener en cuenta que cualquier actualización del sistema, mantiene conectado a los
componentes que brindan servicios de consulta.

Estilos Monolíticos:

Es más fácil darle prioridad a la eficiencia de las comunicaciones.

Son más fáciles de probar.

Curva de aprendizaje son más fáciles, todas las piezas estan en el mismo lugar. (Los microservicios
son fáciles de entender).

La capacidad de modificación es más fácil.

La modularización es más fácil de romper, por lo que es más fácil no garantizar esa separación a
largo plazo.

En la usabilidad, es mas costoso, porque habría que respaldar toda la aplicación y no pequeños
microservicios.

Puede ser un desafío para el despliegue, porque habría que garantizar que toda la aplicación o
sistema se adapta a ese contexto específico.

Estilos Distribuidos:

Es más fácil darle prioridad a la eficiencia de las comunicaciones.

Para hacer una prueba de principio a fin hay que tener todos los componentes disponibles .

La curva de aprendizaje es más difícil, porque habría que entender todas las piezas de los
componentes.

Al ser desplegadas independientemente, son versionadas independientemente, y esta variación de

serviones hace mas complejo su modificación.

La modularidad, es más fácil porque los componentes que son desplegados independiente.

la disponibilidad se pueden tener multiples copias del sistema. por lo que este disponible es mas
barato.

La adaptabilidad es más fácil en el despliegue porque los componente se despliegan

independientemente en múltiples contextos.

Esta vez el reto es que tomes un sistema conocido y haz lo siguiente:

Describe sus atributos de calidad percibidos.

¿Estás de acuerdo con las decisiones tomadas?

Propón el énfasis en algún atributo de calidad.

Describe qué se vería favorecido

¿Qué se vería afectado negativamente?

Repaso de la clase:

PlatziServicios

Situación/Problema:

La bañera de nuestra casa está dañada debido a que se rompió nuestra cañería, es necesario los
servicios de un plomero que me permita arreglar dicho problema y sea de nuestra confianza.

Entonces se comienza con los requerimientos del sistema:

Criterio de éxito:

Conectar rápidamente a un cliente con un profesional de confianza.

Garantizar el aumento del volúmen de trabajo al profesional.

Idea: Definición de una forma ideal de como se satisface una necesidad. Ejemplo: Tener una forma
mucho más sencilla de solicitar un servicio de plomería que llegue a mi casa con un plomero que
se conozca.

-Historias de usuarios: Definir las experiencias que los usuarios han tenido respecto a la solución
de su necesidad. Ejemplo:

Experiencia de un cliente x: quiero contactar a un profesional en el momento para reparar un

problema en mi hogar.

Experiencia de un cliente y: quiero conocer la experiencia del profesional para decidir a quien
contacto.
Experiencia de un profesional x: quiero cobrar mi trabajo realizado para seguir prestando el
servicio.

Experiencia de un profesional y: necesito tener más repertorio de personas para ampliar mi

currículo de trabajo y flujo del mismo.

Requerimientos más técnicos:

Etapas de la prestación de servicio:

Solicitar, aceptar y finalizar una prestación de servicio de forma segura.

Comunicación: La forma en como el cliente solicita el servicio a su hogar.

Evaluación: Como se evalua los profesionales y clientes para futuros tiempos

Riesgos

Son referentes a historias de los usuarios.

Ejemplo:

El cliente utiliza un servicio y no completa el pago en un tiempo determinado

La persona que solicita el servicio no puede confirmar quien es la persona

Restricciones

Limites que tiene nuestro proyecto de acuerdo a variables.

Ejemplo:

Recursos disponibles para el desarrollo: programadores, equipos de cómputo, energía, comida,

lugar de trabajo, servicios públicos, etc.
Registro de impuestos del profesional: Que el profesional cumpla con el pago de impuestos ante
las instituciones.

Antecedentes penales: que el profesional cuente con ser un ciudadano ejemplar dentro de la ley.

Teniendo en cuenta todas las restricciones y requerimientos que existe, lo más adecuado es
montar una arquitectura cliente-servidor dentro de la web que permite de una manera mucho
más sencilla la automatización de procesos.

Repaso de la clase:

Sinopsis: Nuestra startup está teniendo exito como sistema y así mismo hemos de necesitar de
nuevos requerimientos para llegar a la mayor cantidad de clientes posible.

Análisis de requerimientos:

Criterios de exito:

Brindar con nuestro servicio a empresas clientes estabilidad y control de costos de las prestaciones
de servicios que se necesiten.

Se tiene una visión en el circulo de empresas prestadoras una visión de crecimiento de sus
servicios.

Historias de usuario:

El empresario cliente x quiere llevar control de sus finanzas mediante el reporte de gastos en
servicios.
El empresario cliente y necesita que halla un grupo de profesionales preferidos para nunca perder
la disponibilidad de nuestro servicio.

El empresario prestador x quiere medir el redimiento de sus profesionales.

El empresario prestador y quiere posicionarse mejor en el mercado para obtener más clientes

Requerimientos:

Reportes: Gastos por período, por el tipo de servicio contratado, ingresos, horas trabajadas por el
profesional por período y tipo de servicio prestado.

Autorización:

Gestión de usuario: El tipo de empleado que va a tener la empresa.

Roles

Permisos asociado a accines del sistema

Posicionamiento y comunicación: Ranking de prestadores por evaluación, lista priorizada de

prestadores por tipo de prestación.

Riesgo

Las empresas clientes no tienen como extraer información del sistema debido a que estas manejan
sus propia información.

Los juicios hechos por las misma empresas prestadoras de acuerdo con los fraudes.

Restricciones
Cumplir con estándares de auditoría profesional para que nuestro software sea seguro.

Garantizar la privacidad de datos de consumo

Con todo esto se decide que el estilo arquitectónico en la estructura cliente servidor pasa su
transacciones en lote secuencial a los reportes teniendo en cuenta el costo que supone presentar
reportes dentro del aplicativo.

Análisis de requerimientos:

Criterios de exito:

Se desea conectar tanto a empresas locales como globales con los mejores prestadores del
servicio.

Como visión se busca dar mayor facilidad de crecimiento y globalización de las empresas
prestadoras.

Historias de usuario:

El cliente a: quiere entender el sistema en su propio idioma. Razón: quiere garantizar el buen uso
del servicio.

El cliente b: quiere acceder tanto a servicios globales como locales. Razón: Quiere estandarizar a
los prestadores en diferentes ubicaciones.

El usuario necesita acceder a los servicios en cualquier momento sin tener problemas de los husos
horarios que existan dentro del mismo

La empresa prestadora: quiere brindar el servicio de fomar global. Razón: ampliar su alcance a
escala internacional

Requerimientos

Internacionalización:

Traducciones de contenido

Registro de prestadores globales y su capacidad de busqueda local o global.

Disponibilidad de datos:

Que sean medidos mediante reportes en tiempo real

Riesgos

Dificultad de transmisión de conocimiento y productividad de nuestros equipos de desarrollo.

Perdida de datos de manera parcial o total por imprevistos

Dificultad de acceso a los mercados por sus distinción de idiomas.

Restricciones

Husos horarios

La información que se provea a escala internacional

En conclusión: Se necesitan servidores globales y locales que conecten la información necesaria

para la toma de decisiones.

A su vez se los reportes se conectan con bus de eventos para ofrecer en tiempo real información
acerca de la empresa.