ūüéģ

Software Engineering

TagsBusinessComputer science
Created
Updated

Prerequisites

Resources

Hands-on project to build great things using Software Engineering

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

Structured programming

Software engineering skills

https://www.fastcompany.com/40436077/how-software-is-eating-the-military-and-what-that-means-for-the-future-of-war

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

Object-oriented programming and clean code

Smart pointers

Notes

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

https://www.youtube.com/watch?v=uTxRF5ag27A&ab_channel=LexFridman

The Clean Coder: A Code of Conduct for Professional Programmers

Clean Code by Robert C. Martin

Clean Architecture: A Craftsman's Guide to Software Structure and Design

Design Patterns: Elements of Reusable Object-Oriented Software

Code Complete

Don't Make Me Think by Steve Krug.

The Problem with Software: Why Smart Engineers Write Bad Code. Adam Barr

https://www.youtube.com/watch?v=nyKg7gtNdQ8&t=403s&ab_channel=AssociationforComputingMachinery(ACM)

https://stereobooster.github.io/two-big-schools-of-object-oriented-programming

Software

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

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

What tech talks should every software engineer watch?

Dynamic Languages Wizards Series

Longer version of the above two talks can be found below here:

This is interesting as well, Kartik Ayyar's answer nails it:What are some must-see Google Tech Talks?



Future of Data Science

Power of Simplicity

Update Apr 1 2016:

Richard Feynman on Computing:

https://www.youtube.com/watch?v=EKWGGDXe5MA&feature=emb_logo&ab_channel=MuonRay

Guy Steele: Growing a Language

https://www.youtube.com/watch?v=oKg1hTOQXoY&feature=emb_logo&ab_channel=JeffGonis

Alan Kay's Turing Award Lecture

https://www.youtube.com/watch?v=_ahvzDzKdB0&feature=emb_logo

Alan Kay at OOPSLA

Doug Engelbart 1968 Demo

https://www.quora.com/What-tech-talks-should-every-software-engineer-watch

Systems

Notes

System design.

Airbnb (product) have got awesome Talks. Tech Talks at Airbnb

https://www.youtube.com/watch?v=mqGSnjJBM7Y&ab_channel=MasterCloudApps

We Are the Nerds: The Birth and Tumultuous Life of Reddit, the Internet's Culture Laboratory

Software for tracking changes SVN

UML

Pattern of Design

Testing

Debugger vs unit testing

https://martinfowler.com/articles/testing-culture.html

TDD

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

Languages

Tools

https://en.wikipedia.org/wiki/Programming_tool

Perl

Python

Raymond Hettinger Transforming Code into Beautiful, Idiomatic Python

Java

C++

Licenses

Software methodologies

Scrum

RUB

Notes

Scrum a pocket guide

Refactoring

Software quality

Notes

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‚ÄďHoare logic and loop invariance

Testing

Pruebas funcionales

Pruebas exploratorias

Git Flows

Communicational procotols

API REST

Graphql

Pattern designs

Redux

System design

Case of study

Next steps?