馃幃

Software Engineering

Tags
Created
Updated

Prerequisites

馃懇馃徏鈥嶐煉Foundations of Computer Science

Resources

Hands-on project to build great things using Software Engineering

https://github.com/danistefanovic/build-your-own-x
https://github.com/danistefanovic/build-your-own-x

Structured programming

Structured programming. Dijkstra.

Literate programming

Software engineering skills

https://sonatafynexxus.mx/comprehensive-list-of-the-best-software-engineer-skills/

Object-oriented programming

https://betterprogramming.pub/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7

Software

https://www.youtube.com/playlist?list=PLj2IVmcP-_QOG6580LPjSJhmmau0kfzg-

https://www.youtube.com/watch?v=cEBkvm0-rg0&ab_channel=Fireship

Work management platform

Systems

Plain text

Markdown

https://orgmode.org/

Software for tracking changes SVN

UML

https://plantuml.com/

https://github.com/mingrammer/diagrams

Pattern of Design

Testing

TDD

https://philippe.bourgau.net/from-apprentice-to-master-how-to-learn-tdd-test-driven-development/

Licences

Preguntas clave

  1. 驴 Qu茅 es software?

Instrucciones y los datos ejecutables que se suministran a una computadora.

  1. 驴Describa qu茅 es ingenier铆a de software?

La aplicaci贸n de un enfoque sistem谩tico, disciplinado y cuantificable para desarrollar, operar y mantener software.

  1. 驴Qu茅 es un WBS? 驴Qu茅 permite y qu茅 elementos podemos integrar?

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.

  1. Listar y describir a lo menos 3 roles que normalmente conforman un equipo de desarrollo de Software.
  1. 驴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.

  1. 驴 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.

  1. Listar diferencias entre un enfoque de desarrollo en cascada y 谩gil
  1. 驴Qu茅 se entiende por requerimientos funcionales y no funcionales?
  1. Listar ejemplos de requerimientos funcionales y no funcionales (Ordenar por tipo).
  1. 驴C贸mo se sabe si un proyecto de software se ha finalizado?
  1. 驴Qu茅 se entiende por Capacidad?

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

Capacidad=total de horas por miembro* dias productivos

  1. 驴 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.

  1. 驴Qu茅 elementos se recomienda integrar cuando se redacta el Planteamiento de un problema o una Oportunidad?
  1. 驴 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.

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

  1. 驴 En proyectos de software con enfoque 谩gil, cu谩les roles hay ?
  1. 驴 Qu茅 es el product backlog?

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

  1. 驴Qu茅 es un Sprint?

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

  1. 驴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.

  1. 驴 Qu茅 son los puntos de historia de usuario ?

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

  1. 驴 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.

  1. 驴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).

  1. 驴 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.

  1. Listar algunos nombres de sistemas de gesti贸n de proyecto
  1. 驴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.

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-

Desarrollo Colaborativo.

驴Qu茅 es?

Es la implementaci贸n continua del Sistema Correcto.

Actividades como:

Artefactos

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:

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

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

Componentes de la Forja

  1. Computadora de despliegue
  1. Servidor de Colaboraci贸n de Software.
  1. Computadoras de Desarrollo.
  1. Servidor de Calidad de C贸digo.
  1. Servidor de Continua Integraci贸n.
  1. Servidor de Repositorio de Artefactos.

Gesti贸n del proyecto

Tecnolog铆a por defecto:

https://tree.taiga.io/project

Responsabilidad:

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

  1. En el read me, anotar el nombre, elecci贸n de licencia y la descripci贸n del proyecto.
  1. 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)
  1. 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

a trata sobre la entrega de software

b son nuevas caracter铆sticas

c son arreglo de errores

Computadora de desarrollo

Al iniciar:

  1. Crear una copia de la m谩quina de producci贸n.
  1. Descargar o actualizar el IDE m谩s profesional y adecuado.
  1. Descargar un plugin para la conexi贸n con el repositorio.
  1. Descargar un plugin para las m茅tricas en local.
  1. Realizar la configuraci贸n b谩sica sobre el IDE.
  1. Conectar repositorio remoto, con el local.
  1. Fetch sobre el repositorio, rama develop.
  1. Crear una rama tipo feature o hotfix. N贸mbrala en base a la wiki y en base al c贸digo de develop.
  1. Conectar m谩quina de producci贸n y repositorio.
  1. Configuraci贸n del proyecto (con variables de entorno).

Servidor de calidad de c贸digo

Tecnolog铆a por defecto:

https://about.sonarcloud.io/

Al iniciar:

Consideraciones:

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

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

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

Desarrollo colaborativo

Metodolog铆a de desarrollo: XP

2. Las 12 practicas

3. Testing en eXtreme Programming

4. 驴C贸mo se desarrolla?

4.1 Kanban a BDD a TDD a Push. Sobre requisitos funcionales.

Design

https://sanchezcarlosjr.github.io/software-engineering-master-by-escuelait/

Pruebas de sistema

Floyd鈥揌oare logic and loop invariance

Testing

Pruebas funcionales

Pruebas exploratorias

Shell vs terminal vs consola vs multiplexer vs cli

NameQue es?
ShellInterface de usuario para los servicios del sistema operativo.
TerminalInterface software para comunicarse a un servidor.
ConsolaInterface hardware para comunicarase a un servidor.
CLIShell por comandos. No graficos.
promptUbicacion actual dentro del sistema de archivos dentro de un CLI. Con base en las configuraciones puede aportar distinta informacion (git)
multiplexerVarias sesiones de inicio de sesion. con pseudo-terminales dentro de una sola teminal.
screen o demusComando para abrir una nueva terminal de un servidor externo. (multiplexer)
Untitled

Git Flows

GitHub flow

Git

GitLab flow

Release flow

Trunk-based development

Master-only flow (One Flow)

Communicational procotols

API REST

Graphql

Pattern designs

Reactive programming

Redux

System design