Software Engineering

Proceso de gestión de proyectos que describe el proyecto (su alcance) en componentes más pequeños hasta conseguir componentes manejables. Permite describir el alcance del proyecto de manera detallada (dinero y tiempo), cada grado de definicion aumenta el entendimiento sobre la concreción del proyecto, esto es, cada componente esta orientado a la realización del proyecto y a cumplir los objetivos. Los elementos de WBS son los componentes del alcance y el trabajo asociado, pueden buscarse expertos para lograrlo.

Listar y describir a lo menos 3 roles que normalmente conforman un equipo de desarrollo de Software.

Desarrollador. Encargado de desarollar el software.

Tester. Encargado de probar el software.

Jefe de proyecto. Encargado de dirigir el software.

¿Qué es Scrum?

Es un marco de trabajo ágil para desarrollar principalmente, aunque no limitado, proyectos software. Usando en la industria del software con XP, esto es, Scrum+XP es un proceso de desarrollo de software ágil.

¿ Qué se entiende por alcance?

Alcance es la definición de los parámetros -factores que definen el sistema y determinan su comportamiento-, del proyecto descrito en términos de requirementos; describe el trabajo que está dentro de los límites del proyecto.

Listar diferencias entre un enfoque de desarrollo en cascada y ágil

Cascada realiza una iteración. El ágil n iteraciones. En cada iteración se realizan la toma de requerimientos, el desarrollo y pruebas.

En ágil se prefiere la colaboración vs las herramientas.

Ágil es usado en proyectos complejos, cascada para simples.

¿Qué se entiende por requerimientos funcionales y no funcionales?

Requerimientos funcionales. Propiedad lógica de dominio que debe ser exhibida en el software.

Requerimientos no funcionales. Propiedad cualitiva (libre de ambiguedad) que debe ser exhibida en el software.

Listar ejemplos de requerimientos funcionales y no funcionales (Ordenar por tipo).

Funcionales	No funcionales
Cuando el usuario ingrese su precio Entonces debe guardarse el precio con IVA tal queel pago de IVA es f(x)=x*1.16donde x es el precio neto del producto.	Debe usarse C++ para la API REST.
Cuando se guarde el video Entonces el usuario debe poder ver la lista de videos guardados.	Debe usarse PostgreSQL como BD.
Pausar video tal que el video se deje de reproducir.	El video debe tardar 50 ms en empezar desde que el usuario lo solicita.

¿Cómo se sabe si un proyecto de software se ha finalizado?

Cuando el Product Owner lo ha finalizado.

Cuando las historias de usuario descritas en criterios de aceptación son cumplidas, desplegadas, probadas con software de calidad.

¿Qué se entiende por Capacidad?

El máximo esfuerzo que puede lograr el equipo de desarrollo:

Capacidad=total de horas por miembro* dias productivos

¿ Qué se entiende por Esfuerzo?

El trabajo (conjunto de tareas) necesario para lograr los criterios de aceptación del requerimiento, esto es, que este finalizado.

¿Qué elementos se recomienda integrar cuando se redacta el Planteamiento de un problema o una Oportunidad?

Contexto (Organizacion, influencias, proyectos parecidos, …).

Actores (Stackholders), especialmente el Decision Maker.

Elementos externos al proyecto: investigaciones, restricciones legales, condición del mercado,...

¿ Qué es SMRT?

Acrónimo del ingles (Specific, Measurable, Achievable, Relevant, Time bound) para indicar que los objetivos deben ser: específicos, simples, significativos, medibles, motivantes, útiles, relevantes, realistas, basado de resultados y limitados por el tiempo.

Si te pidiera estimar el costo y tiempo de desarrollo de un proyecto, ¿qué harías para estimarlo?

Si tuviera experiencia en el dominio y en el ecosistema, uso mi experiencia previa, Sino requisitó, entiendo que es lo que necesita el cliente, esto como un primer borrador. Y entonces, descompongo el proyecto mediante un WBS con costos y tiempo para una primera iteración y en cada iteración repito el proceso. Estimar en el largo plazo no es fácil, por tanto, apostar por una iteración (3 semanas a 1 mes) siempre es más sencillo.

¿ En proyectos de software con enfoque ágil, cuáles roles hay ?

Product owner. El es una persona encargada de entender y representar las necesidades de los stakeholders.

Scrum master. Persona responsable de aplicar Scrum al proyecto para conseguir los objetivos: ayudar a definir cuando esta cumplida un requisito, facilitar la colaboración entre los distintos roles, remover obstáculos, …

Team Member. Personas que desarrollan el proyecto y llevan a cabo el incremento del producto en cada sprint.

¿ Qué es el product backlog?

Artefacto en Scrum para requisitar, a saber es una lista de requerimientos priorizados.

¿Qué es un Sprint?

Intervalo de tiempo (3 semanas a 1 mes) donde el equipo desarrolla el Sprint Backlog.

¿Qué es una historia de usuario?

Una manera informal de describir un requisito funcional desde la perspectiva del usuario final. La formalidad y la definicion de finalizado son los criterios de aceptación.

¿ Qué son los puntos de historia de usuario ?

Métrica de historias de usuario para estimar el esfuerzo hecho.

¿ Para qué sirve el Burn Down Chart y cómo se usa ?

Burn Down Chart es una herramienta visual que mide el trabajo completado en un intervalo de tiempo uniforme (dias, semanas, meses) comparado al trabajo no completado que se supone terminado por la planeación. Se usa cuando hay un calendario de finalización.

¿Qué son los OKR?

Acrónimo del inglés Objetives and key results, usado como marco de trabajo administrativo para guiar los esfuerzos de una organización. Se escriben los objetivos y de ahí los resultados clave (iniciativas para lograr el objetivo).

¿ El Scrum Master es el jefe del proyecto ?

No. Su rol es facilitar las tareas de Scrum y que los distintos roles pueden cumplir su trabajo con su ayuda. La idea de Scrum es evitar un jefe de proyecto, porque se considera que los miembros del equipo son auto-organizados y multi-disciplinarios.

Aunque en las empresas puede variar, suele ser el Product Owner el que cumpla este objetivo.

Listar algunos nombres de sistemas de gestión de proyecto

RedMine.

Trello.

Asana.

Jira.

Notion.

¿Qué es administración de riesgos?

Disciplina de la administración de proyectos que incluye los procesos para manejar, identificar, analizar, monitorear, implementar y planear respuestas para los riesgos asociados al proyecto. Esto, para optimizar las probabilidades del éxito del proyecto.

Disciplinas de desarrollo

Requisitos.

¿Qué es?

Anotaciones del Sistema correcto esperado por el dueño del producto.

Artefactos.

Sprint backlog

Product backlog

Kanban priorizado (upstream a downstream)

Anotaciones fundamentales
- Glosario
- Entorno operativo
- Presupuesto
- Nombre del proyecto

Ecosistema.

¿Qué es?

Espacio de trabajo donde un conjunto de herramientas, funcionan como una unidad para el desarrollo con en el resto de las disciplinas.

Artefactos -estos artefactos es para software posible adaptación-

Computadora del desarrollador

Servidor de pre producción

Servidor de artefactos del repositorio

Servidor para la calidad del código

Servidor del control de versiones

Servidor de Continua integración.

Desarrollo Colaborativo.

¿Qué es?

Es la implementación continua del Sistema Correcto.

Actividades como:

Integración continua

Otros temas referentes al desarrollo

Actualización del diseño arquitectónico

Comunicación mínima basada en scrum y xp.

BDD basado en el Kanban, en una unidad de trabajo que libera features y hotfix.

Artefactos

Sistema funcional

Despliegue.

¿Qué es?

Llevar la versión más reciente (el sistema actual) al ambiente de producción.

Pruebas de Sistema.

¿Qué es?

Conjunto de pruebas del Sistema en un entorno pre-producción.

Actividades como:

Exploratorio

Pruebas no funcionales

Modelo conceptual

Acercamientos al Triangulo

Resultado esperado

El dueño del producto anota la primera descripción del sistema objetivo y un nombre. Se define a los interesados: dueño del producto, usuarios finales y expertos en el dominio.

Se define el entorno operativo: la arquitectura física, las versiones, los lenguajes, frameworks, ecosistema y otras tecnologías a considerar.

Se da un primer acercamiento al glosario, que es de uso general.

Presupuesto operativo. En base al entorno operativo.

Consideraciones

El acercamiento inicial al alcance sirve como andamio para evaluar y tomar decisiones oportunas. Se debe definir lo que necesita en una primera instancia, lo mínimo indispensable para iniciar en la primera iteración.

Y cabe, decir que estos artefactos son objetos vivos, es decir, pueden adaptarse según transcurre la iteración. En esta fase, solo sirven como un andamio para entender como es el sistema objetivo, y el contexto del mismo.

Artefactos

Descripción

Que es lo que pretende resolver el sistema.

Nombre

Basado en técnicas de mercadotecnia: naming.

Entorno operativo

Cuáles son las tecnologías que se usaran y como se conectaran en ellas.

Stakeholders

La organización (Dueño del producto), el usuario final y los expertos del dominio.

Glosario

Catálogo alfabetizado de las palabras y expresiones de uno o varios textos que son del dominio, junto con su significado o algún comentario que ayuda al equipo a manejar los mismos términos.

Scrum + XP

Lo que planteo aquí está basado en Scrum y XP (dos métodos distintos y complementarios), y varias de las ideas aquí expuestas son consideraciones que ayudan a concretar dichos marcos de trabajo, lo que significa que primero deben leerse ambos métodos de sus creadores antes de leer este apartado.

Lista de producto (product backlog)

Cualquier esfuerzo por parte de equipo de desarrollo debe estar aquí, a efectos priorización y productividad. Es decir: mejoras, errores, fallos de seguridad y controles de esfuerzos (pruebas de supuestos, cantidad de trabajo realizado, etc.). Por lo que se sobreentiende que lo anotado en la lista de producto no se realizara hasta que llegue su hora en el sprint respectivo, evitando las pérdidas de tiempo. Lo no planeado es un desperdicio de tiempo: crisis, juntas, etc.

Recordando que la lista de producto se agregan historias de usuario (requisitos funcionales -valor para el negocio-) y lo que necesita el equipo (requisitos no funcionales -valor del producto-). La diferencia entre valor del negocio y del producto, la tecnología no cambia la esencia de la solución.

Modelo de una historia de usuario:

Como un ROL necesito la CARACTERISTICA/FUNCIONALIDAD con la finalidad de RAZON/RESULTADO.

Planificación del Sprint (sprint planning)

El trabajo a realizar durante el sprint se planifica en la planificación de sprint. Aquí se prioriza y se detalla. Este plan se crea mediante el trabajo colaborativo del Equipo Scrum Completo. Basado, pero no limitado en la lista de producto. Las preguntas que responde esta actividad son: ¿Qué puede entregarse en el incremento? -lo que implica priorizar y limitarse los esfuerzos a eso- ¿Cómo se conseguirá hacer el trabajo necesario para entregar el incremento? Para responder a estas preguntas realizamos las siguientes actividades:

Definición de criterios de aceptación

Los criterios de aceptación nos permiten definir una historia de usuario, lo que quiere decir que por cada historia de usuario y a varios criterios de aceptación. Los criterios de aceptación definen los requisitos del Product Owner sobre cómo debe comportarse la aplicación para que una determinada acción se pueda llevar a cabo, normalmente por parte de un usuario de la aplicación.

Los criterios de aceptación deben describir siempre un contexto, un evento y la respuesta o consecuencia esperada del sistema.

La forma más utilizada para describir los criterios de aceptación es conocida como: Dado un contexto Cuando ocurre el evento Entonces se espera el resultado.

En este nivel, se hacen las estimaciones.

ATDD

Los criterios de aceptación deben tener ejemplos concretos, lo que quiere decir, cada criterio tiene un ejemplo concreto, para luego sea desarrollado con TDD -en el desarrollo colaborativo-.

Presupuesto

Cálculo anticipado del coste del sistema en la iteración. Sueldos, entorno operativo, etc.

Kanban

Una lista de historias priorizadas (en ToDo), con criterios de aceptación, y con un ejemplo de lo esperado.

1.3 Sobre las historias repetitivas.

Las historias sean de usuario o de equipo, donde se vea que se repiten las tareas de las historias, o lo que se espera de la historia, entonces, es deber del equipo scrum buscar la simplificación y la automatización en búsqueda de eficiencia, y eficacia. Este proceso, debe hacerse cada vez que se vean patrones.

1.4 Sobre las peticiones

Mientras se está en la iteración, pueden surgir peticiones durante el desarrollo, no se anotan en la planeación del sprint, sino en la lista de producto. Cabe decir, que si un desarrollador no le quedo claro una historia de usuario (lo que significa que faltaron criterios de aceptación), primero, se anota el criterio de aceptación al final de los demás, se resuelven los que son posibles con el conocimiento actual y al finalizar se habla con el dueño del producto.

1.5 Sobre el equipo

Autogestiona do: las personas eligen las historias de acuerdo a sus posibilidades.

Autoorganizado: las personas se unen en equipos y colaboran con quien tengan que hacerlo.

Ecosistema

Consideraciones previas

Lo correspondiente a la gestión del proyecto, es independiente de tecnología. Y es lo primero a definir al iniciar un proyecto.

Al pasar el proceso de arquitectura, es posible definir la Forja.

Componentes del Ecosistema

Servidor de Gestión del Proyecto

Forja

Componentes de la Forja

Computadora de despliegue

Servidor de Colaboración de Software.

Computadoras de Desarrollo.

Servidor de Calidad de Código.

Servidor de Continua Integración.

Servidor de Repositorio de Artefactos.

Gestión del proyecto

Tecnología por defecto:

https://tree.taiga.io/project

Responsabilidad:

Manejador del proyecto

Documentación - Wiki

Bug tracker - Peticiones

Computadora de despliegue (producción)

Computadora donde se despliega el software (computadoras de producción).

Se debe definir las tecnologías, plataforma, y las versiones correspondientes. Anotar en una tabla, con dicha información. Porque es indispensable para crear las máquinas de pre-producción, y no haya problemas de compatibilidad entre los componentes del software.

Preparar el entorno de despliegue.

Servidor de Colaboración de Software.

Control de versiones (repositorio de código)

Tecnología por defecto

https://github.com/

Al iniciar

En el read me, anotar el nombre, elección de licencia y la descripción del proyecto.

Crear las ramas básicas:
1. master.
1. develop.
1. features#x-name (en base al manejador de proyectos)
1. hotfix#x-name (en base a las peticiones)

Establecer el commit inicial, sobre develop:
1. Arquitectura inicial (framework)
1. Librerías obligatorias:
  1. Para las pruebas:
    1. Unitarias
    1. Integración
    1. Sistema
  1. Para el reporte de errores (logs)
1. Otros componentes que se consideren

Anotaciones

Ramas:
- Master. Apunta al último commit de producción, es decir, a la última versión del código liberado.
- Develop. Es la rama de desarrollo, siempre estable, código que cumple los requisitos de calidad y con todos los test superados.
- Feature. Parte de develop, se añaden las nuevas características y vuelve a develop cuando vuelve a ser estable.
- Issue. Parte de develop, para temas que son parte del proceso, solo que no vienen dentro los demás. Por ejemplo, pruebas de integración, pruebas de aceptación, UX, etc.
- Release. Se utiliza para estabilizar un código para salir a producción. Una vez terminada, se fusiona con master.
- Hotfix. Se utilizan para corregir (bugs, fallos de seguridad, etc) del código en producción.

La configuración para producción está en el servidor de continua integración.

La configuración para desarrollo está en las computadoras de desarrollo.

Sobre el versionado (release):
a.b.c

a trata sobre la entrega de software

b son nuevas características

c son arreglo de errores

Computadora de desarrollo

Al iniciar:

Crear una copia de la máquina de producción.

Descargar o actualizar el IDE más profesional y adecuado.

Descargar un plugin para la conexión con el repositorio.

Descargar un plugin para las métricas en local.

Realizar la configuración básica sobre el IDE.

Conectar repositorio remoto, con el local.

Fetch sobre el repositorio, rama develop.

Crear una rama tipo feature o hotfix. Nómbrala en base a la wiki y en base al código de develop.

Conectar máquina de producción y repositorio.

Configuración del proyecto (con variables de entorno).

Servidor de calidad de código

Tecnología por defecto:

https://about.sonarcloud.io/

Al iniciar:

Seguir las instrucciones del tutorial de Sonar Cloud.

Configurar según sea el estándar de diseño.

Consideraciones:

Cobertura del 80%.

Arreglar todos los problemas de diseño.

Servidor de continua integración

Modelo informático para hacer continuas integraciones, lo más a menudo posible, para detectar fallos cuanto antes. Si hay algún problema, con una de las partes, el proceso no sigue. Cabe decir, que es un proceso automático.

Tecnología por defecto

https://travis-ci.org/

Actividades de la integración

Validar

Compilar

Pruebas unitarias

Empaquetar

Pruebas de integración

Verificar

Instalar (solo si es la rama master)

Deploy (solo si es la rama master)

Cuando y que

Cuando los desarrolladores incrementan a develop, mediante las ramas feature, se realiza las primeras 6 actividades de continua integración.

Cuando se actualiza master, mediante develop o hotfix, se realizan todas las actividades de continua integración.

Consideraciones

Las configuraciones para deploy, están en el servidor de continua integración.

Configurar adecuadamente el servidor de calidad de código.

Configurar adecuadamente el servidor de entrega.

Usar variables de entorno

Hacerlo todo mediante scripts

Servidor de artefactos

Dependiendo del proyecto. Puede ser necesario, llevar un control sobre las entregas.

Tecnologías:

Git o Nexus

Desarrollo de software colaborativo

Flujo de trabajo

Forja en acción