1 ScrumBut

La siguiente imagen muestra el ciclo de vida del marco de trabajo conocido como SCRUM. Se dará un repaso para recordar el ciclo de vida.

Figura 1.1: Ciclo de vida de SCRUM

Los principales elementos de la metodología SCRUM son lo siguientes:

1. El Equipo Scrum
   • El propietario del producto (Product Owner)
   • El Equipo de Desarrollo (Developers)
   • El Scrum Master
2. Eventos de SCRUM
   • La iteración (Sprint)
   • Planificación de la iteración (Sprint Planning)
   • Reunión diaria de SCRUM (Daily Scrum)
   • Revisión de la iteración (Sprint Review)
   • Retrospectiva del Sprint (Sprint)
3. Artefactos de Scrum
   • Product Backlog
   • Sprint Backlog
   • Incremento
4. Transparencia de Artefacto
   • Definición de “Hecho” (Done)

El hecho de que un equipo de trabajo desarrolle software haciendo uso de algunos de los elementos de SCRUM no significa que lo esté llevando a cabo correctamente, es ese el momento en el que lo que realmente se hace es un SCRUM-But. Scrum-But se refiere a las razones por las cuáles el equipo no puede sacar el máximo provecho de SCRUM para resolver sus problemas y hacer realidad los beneficios del desarrollo ágil de software utilizando Scrum, tal y como lo refieren la Scrum Alliance y Scrum.org.

Algunas de las justifiaciones que sulen escucharse en los equipos de desarrollo que hacen SCRUM-But son:

• “Nosotros utilizamos Scrum, pero…¿Quien tiene un Daily Scrum todos los días? es demasiado!. Tan sólo tenemos uno por semana.”
• “Nosotros utilizamos Scrum, pero… Las retrospectivas son una pérdida de tiempo. Por lo que no hacemos.”
• “Nosotros utilizamos Scrum, pero… No podemos construir una pieza de funcionalidad en un mes. Nuestros Sprints son 6 semanas de duración.”
• “Nosotros utilizamos Scrum, pero… A veces nuestros gerentes nos dan tareas especiales. Por lo que no siempre tenemos tiempo para cumplir con nuestra definición de “Done”.”

1.1 ¿Vale la pena utilizar SCRUM?

Según los indicadores del Chaos Report 2012 de Standish Group, el 86% de los proyectos desarrollados bajo los metodos tradicionales son modificados o fracasan.

En contraste el mismo estudio recalca que con el uso de métodos ágiles, tan solo el 58% de los proyectos desarrollados son modificados o fracasan tal y como se puede observar en la siguiente gráfica.

Figura 1.2: Comparativa entre el procentaje de éxito y fracaso del método en cascada y los métodos ágiles

El métdo de cascada es un malentendido desde el principio. Fue supuestamente “inventado” por el diario “Gestion de desarrollo de sistemas de Software grandes” por el Dr. Winston W. Royce en 1970, pero la implementación que se ha descrito anteriormente es riesgoso e invita al fracaso.

En este punto cabe hacerle cierta justia al método de cascada, el cuál fue formalmente presentado por primera vez en 1970 por el Dr. Winston W. Roice, quien en su artículo “Managing the Development of Large Software Systems” aclara que lo que presenta es un modelo erróneo y no necesariamente funcional, sin embargo, fue tomado por la industria del software como un estándar de facto, lo cuál, ha provocado los altos porcentajes de fallo y fracaso en proyectos de software presentados anteriormente.

1.2 Discrepancia entre el modelo y el problema

¿Es un bebé una versión más pequeña de un adulto?, la respuesta es no, ya que un bebé no es un adulto pequeño, un bebé es un ser independiente. Por lo tanto creer que un bebé es un adulto en forma pequeña o de menor tamaño es algo erróneo. Las empresas como la NASA, IBM del departamento de la defensa crearon sus propios modelos de calidad como CMM para sus empresas, las cuáles, están constituidas por un gran equipo de trabajo, manejan al rededor de 800 mil trabajadores, por lo cuál se cataloga como una empresa grandes, al igual que IBM.

Figura 1.3: Pintura renacentista de un bebé con forma de adulto.

Entonces ¿porqué se pretende adaptar procesos que fueron desarrollados para manejar grandes organizaciones a empresas mucho más pequeñas? segun datos oficiales cenrca del 90% del desarrollo de software en países como México y España se lleva a cabo por pequeñas y medianas empresas (PyMEs) o incluse micro-pymes de dos o tres personas, las cuáles, no cuentan ni con la mitad de los trabajadores pertenecientes a las ya mencionadas, es lo mismo que creer que un bebé es un adulto pequeño. Es por ello que estas empresas necesitan adaptar “macro procesos” a sus necesidades y no las “empresas a los procesos”. Es aquí donde el uso de métodos ágiles puede marcar una diferencia.

2 Integración Continua

En palabras de Martin Fowler, unos de los principales exponentes del desarrollo ágil, la integración continua es una práctica de ingeniería de software dónde los miembros de un equipo integran su trabajo de manera frecuente, usualmente una persona realiza una tarea de integración diariamente. Cada integración es verificada mediante una compilación automatizada, que incluye las pruebas, con la finalidad de detectar errores de integración tan pronto como sea posible. El uso de esta práctica ha demostrado que ayuda a reducir significativamente los problemas de integración y permite a los equipos de desarrollo construir software cohesivo con mayor rapidez.

Uno de los conflictos que se presentan al no realizar integraciones continuas en los proyectos, es la ruptura del sistema al realizar e implementar cambios que aún no son probados; la falta de integración continua genera inestabilidad en el código además de un ciclo de retroalimentación muy largo, por mencionar solo algunos de los problemas derivados de la falta de uso de esta importante práctica de ingeniería de software.

Figura 2.1: Ciclo de vida de la integración continua

2.1 Ciclo de vida de la integración continua

Tal y como se muestra en la Fig. 2.1, el ciclo de vida de esta práctica de ingeniería de software es un proceso continuo, y que termina, hasta que el software alcanza una madurez en su integración lo suficientemente buena para que el producto de software desarrollado sea liberado al mercado o entregado a su usuario final. A continuación se describen brevemente cada una de las actividades del ciclo de vida de la integración continua.

2.1.1 Publicar código fuente de la máquina local

Checks in source code. ### 2.1.2 Descargar código fuente del servidor de control de versiones 2. Checks out source from VCS. ### 2.1.3 Compilar el código 3. Compile. ### 2.1.4 Realizar análisis estático de los estándares de programación y de errores 4. Static code analysis standards & bugs. ### 2.1.5 Ejecutar pruebas unitarias 5. Run unit test. ### 2.1.6 Realizar análisis de cobertura de código 6. Code coverage analysis. ### 2.1.7 Realizar análisis de seguridad estático del código fuente 7. Static code analysis security (time consuming). ### 2.1.8 Compilar unidades de código lista para distribución 8. build deployable units. ### 2.1.9 Desplegar la aplicación 9. Deploy APP. ### 2.1.10 Definir el análisis de rendimiento 10. Setup perf analysis. ### 2.1.11 Definir banco de pruebas 11. Set up test fixtures. ### 2.1.12 Realizar pruebas funcionales y de automatización 12. Functional test / automation. ### 2.1.13 Publicar reportes 13. Publish reports.

2.2 Ventas y desventajas de la integración continua

Como toda práctica en la ingeniería de software, la integración continua tiene sus ventajas y sus desventajas, a continuación en la Tabla 1 se mencionan las más relevantes.

Tabla 1: Ventajas y desventajas de continuous integration

A continuación se nombran algunas de las herramientas que se pueden utilizar:

• GitHub. Repositorio para control de versiones
• Travis-CI. Sistema distribuido de integración continua libre integrado con GitHub
• CPD (Continuing Professional Development)
• PMD (Project Mess Detector)
• Coverity.
• FxCop. Herramienta de análisis de código
• Jenkins. Servidor de integración continua open source

3 Vagrant y maquinas virtuales

Cuando se está desarrollando en una máquina propia que no es de la oficina y los integrantes del proyecto tienen preferencias por alguna tecnología (sistema operativo, base de datos etc), puede generar problemas de configuración y al realizar cambios en el repositorio de código, por lo cual utilizar una máquina virtual es una buena solución para evitar este tipo de conflictos de configuración.

Vagrant es una herramienta para la creación y configuración de entornos de desarrollo virtuales. Está disponible para Linux, Mac OS X, Windows, y otras plataformas.

3.1 Instalación de Vagrant en Windows

Descargar el paquete de instalación aquí y ejecutarlo, esta instalación no difiere a las instalaciones normales de Windows, se siguen los pasos que aparecerán en la pantalla. Es necesario descargar la Version 1.7.

NOTA: Descargar Putty aquí si el sistema operativo es Windows. Putty no se configura en la instalación, se ejecuta hasta que utilizamos el comando “vagrant up” ( que será un poco más adelante) y se realiza la configuración.

3.2 Instalación de Vagrant en Linux

Para la instalación de Vagrant desde consola teclear el siguiente comando:

1 `sudo apt-get install vagrant`

Para desechar la máquina virtual cruda, salir de la sesión SSH y ejecuta el siguiente comando:

1 `vagrant destroy`

3.3 Instalación de Vagrant en Mac OS

Para mayor información sobre la máquina virtual Vagrant para MAC OS pueden consultar los siguientes links: Enlace 1, Enlace 2

3.4 Instalación de VirtualBox en Windows

Para realizar la instalación descarga el paquete en la versión 5.0.4 y seguir los pasos normalmente en la siguiente liga: Enlace 3

NOTA: VirtualBox no corre en Windows con la versión 4.3, descargar la versión 5.

3.5 Instalación de VirtualBox en Linux

Se puede realizar la descarga del paquete en el siguiente link: Enlace 1, Enlace 2

Ó realizar la instalación desde consola con el siguiente comando:

1 `sudo apt-get install virtualbox`

3.6 Instalación de VirtualBox en Mac OS

Nota: Instalacion aun pendiente

Después de haber realizado la instalación de Vagrant y VirtualBox desde la consola realizar el siguiente ejercicio:

• Crear una carpeta que se utilizará para desarrollar los ejercicios del curso en la ruta donde regularmente se trabaja.

  mkdir scrum_developer

• El instructor proporcionará un archivo con el nombre “python.box” colocar dentro de la carpeta que se acaba de crear scrum_developer.

• Ejecuta el siguiente comando para que Vagrant reconozca que existe una máquina virtual.

  vagrant box add developer developer.box

• Ejecutar la máquina virtual con el siguiente comando.

  vagrant init developer

• Levantar la máquina virtual (Si tu sistema operativo es Windows, pasar al sub tema “3.7 Configuración de Putty” que se encuentra más adelante)

  vagrant up

• Realizar la conexión a la máquina virtual. Si tu sistema operativo es Windows es momento de configurar Putty ya que este SO no puede ejecutar el comando ssh.

1 `vagrant ssh`

3.7 Configuración de Putty.

Configurar Putty de la siguiente manera:

1. Desde la consola teclear el comando:

   vagrant up

Te mostrará la siguiente pantalla:

1. Ejecutar el programa Putty y configurar el Host Name como aparece en SSH Address en la imagen anterior.

3.-Con los datos ingresados en Putty, te pedirá usuario: vagrant y contraseña: vagrant.

4.-Si la configuración fue exitosa te aparecerá lo siguiente en la consola.

• Entrar a la raíz de la máquina virtual (lo que se guarde en este directorio, se guardará tanto en local como en la máquina virtual).

  cd /vagrant

En la siguiente tabla se mencionan los comandos que se utilizan en este tema (no van en el orden que se ejecutan)

Tabla: Comandos a utilizar en Vagrant.

4 Introducción al lenaguaje Python

Se necesita un lenguaje que todos los integrantes del equipo puedan aprender en poco tiempo, el cual debe ser el mismo para todos, que sea compatible con las herramientas de calidad que se utilizarán, sencillo de aprender para cualquier programador Junior, sencillo de codificar, y compatible con diferentes sistemas operativos.

La selección del lenguaje para este curso es Python. Es un lenguaje de programación interpretado con las siguientes características: soporta programación orientada a objetos, programación funcional, es multiplataforma, de código abierto, sencillo debido al uso de la semántica, la sintaxis y su portabilidad.

¿Cómo se hace?

Instalación

• Linux en la versión 2.7

  sudo apt-get install python2.7

• MAC OS

  Python versión 2.7.9 - 2014-12-10 Descargar

• Windows Descargar

¿Cómo verificar la instalación?

Entrar a ms-dos y ejecutar:

1 `python`

¿Cómo saber qué versión de python está instalada?

Ejecutar:

1 `python --version`

Ejercicio: Entrar a python en la máquina virtual para realizar los ejercicios que se encuentran en el siguiente manual

5 Comentarios útiles

Uno de los principios básicos de los desarrolladores de Software es:

“Todas las funciones deben ser documentadas”.

Habrá quien esté de acuerdo con esto y habrá quienes no, tu ¿Estas de acuerdo?, tu, ¿Documentas tus funciones?. Pues este principio es algo polémico ya que hay quienes dicen que:

“La mayoría de los comentario son una forma de duplicación…”

¿Por qué se dice esto?

En la siguiente imagen, se puede observar cómo la documentacion se duplica con el comentario de la función que se codificó:

¿Cómo hacer comentarios útiles y evitar la duplicación?:

Para evitar la duplicación y generar comentarios útiles debemos responder a las preguntas que se muestra en la siguiente imagen.

Who: ¿Quién hizo este código? el comando git blame nos dice qué persona hizo el código.

What: ¿Qué hace esta función? o esta clase? Esto nos lo debe decir el nombre de la función.

Where: El IDE nos dice en qué lugar es utilizada la función.

Why: El porqué o para qué sirve la función, es lo que se pone en el comentario.

How: El código dice como lo hace.

Estas preguntas nos ayudan a realizar comentarios útiles, sobre todo si se comienza a documentar el código y no se sabe como comenzar.

6 Doctest: Ejercicio

La falta de pruebas durante el desarrollo de Software genera caos por la innumerable cantidad de errores o fallas que puede tener un sistema, programa o aplicación, sólo al realizar las pruebas salen a relucir estos errores, pero probado está, que entre más tarde se encuentre un error, más costoso es corregirlo.

Doctest: es un módulo que incluye Python que permite la realización de pruebas unitarias basada en la salida estándar que se obtienen en la shell, como parte de la documentación de una función y método se puede escribir directamente el caso de prueba.

TDD (Test Driven Development). Consiste en el desarrollo de dos prácticas:

1. Escribir las pruebas antes del código
2. Refactorización.

Se toma un requerimiento y se desarrolla una prueba, pensando en cómo debería ser la funcionalidad del método y verificar que ésta falle. A Continuación se desarrolla el código de la prueba y se verifica que la prueba pase satisfactoriamente, hecho esto, se procede a realizar refactorización para mejorar la funcionalidad del código. Con esto se verifica que el código está cumpliendo con los requisitos mediante la realización de las pruebas.

Existen herramientas que nos ayudan a ejecutar pruebas automatizadas como JUnit similar a Doctest.

En la siguiente tabla se mencionan los comandos y su descripción que se utilizaran para verificar la funcionalidad de las pruebas que se desarrollaran en el ejercicio sobre “Doctest”.

Tabla: Comandos para ejecutar el archivo de pruebas unitarias

Ejercicio: En el repositorio de código se encuentra el archivo con el nombre “python_lab.py” con pruebas unitarias, guardar el alchivo en la carpeta del curso. Estas pruebas no están funcionando correctamente. Realizar las correcciones para que las pruebas puedan funcionar correctamente. Utiliza el comando “python -m doctest python_lab.py” para correr las pruebas y verificar cuáles estan correctas y cuáles no.

En la siguiente imagen se muestra el funcionamieto de “python -m doctest python_lab.py”

Nota: Para conocer al desarrollador de cada línea de codigo ejecutar el siguiente comando:

1 `git blem nombre_del_archivo`
2 `git blem python_lab.py`

7 Retrospectiva del día 1

En casi todos los proyectos de desarrollo de Software se presentan conflictos como la falta de claridad en los requerimientos, mala comunicación del equipo, selección de herramientas nuevas sin curso introductorio previo, por mencionar algunos.

La retrospectiva en la ingeniería de Software nos ayuda a identificar esos conflictos y a buscar una solución para mejorar en los futuros proyectos.

¿Cómo se hace?

La retrospectiva es una junta corta que se realiza después de la terminación de un proyecto o una iteración de proyecto, en la cuál se abordan los aciertos y errores que se han generado en el transcurso de la realización del proyecto. En la retrospectiva se propone cómo mejorar los conflictos presentados y se discute qué se está haciendo bien y se quiere seguir haciendo de la misma manera, para realizar un mejor trabajo. En un lugar visible para todos los integrantes (pizarrón, pared, ventana, cartulina) se representan dos secciones: “Qué hicimos bien y queremos repetir” y “Qué podemos/debemos mejorar”. De esta forma, se recomienda que la retrospectiva se desarrollé en torno a las siguientes preguntas:

• ¿Qué hicimos bien y queremos seguir haciendo?
• ¿Qué podemos / debemos mejorar?
• O la identificación de una propuesta

Pasos:

• Cada integrante del equipo tiene 2 post-its, uno para cada sección, pasa a ubicarlo dónde corresponde y lo lee frente al equipo.
• De la sección “Qué podemos / debemos mejorar” se toman dos propuestas entre todos los integrantes y se hace el compromiso de mejorarlos.

8 Repositorio de código Git

Cuándo se trabaja en un proyecto de desarrollo de software, ya sea individualmente, siendo parte de un equipo de trabajo o de manera distribuida, pueden generarse problemas si no se cuenta con un repositorio de código dónde se encuentren versiones del mismo. Por ejemplo, si dos o más personas están trabajando en el mismo archivo y los dos realizan cambios a las mismas líneas de código podría generarse perdida al realizar las actualizaciones al archivo, si se está trabajando sin repositorio y toda la información se encuentra solo en una carpeta en una máquina personal, y por error se elimina ésta carpeta, se daría una pérdida completa del proyecto generando un grave problema para el desarrollador y para todo el equipo.

El repositorio de código ayuda a que el proyecto se encuentre ubicado en un lugar seguro, además se puede tener un control de las versiones, cambios realizados, fechas de modificación, fechas de última versión, el nombre del integrante que modificó el código, entre otra informacion relevante; si hubiera un error en alguna versión y fuera encontrado durante producción, se puede tomar una versión anterior que no tenga errores y que no haya sufrido cambios significativos y utilizarla. A continuación se aprenderá a utilizar este tipo de repositorios de código.

¿Cómo funciona Git?

La siguiente imagen muestra los componentes básicos para comprender Git.

A continuación se muestra un diagrama con el flujo del funcionamiento de Git.

Comandos más utilizados

Existen muchos repositorios de código, uno de los más utilizados es Git. En la siguiente liga se puede encontrar un pequeño manual que ayudará a comprender el funcionamiento de Git aquí

8.1 instalacion de Git

8.1.1 Instalacion de Git en MAC OS

Deberá tener instalado Homebrew

1 `brew update`
2 `brew install git`

8.1.2 Instalacion de Git en Debian/Ubuntu

1 `sudo apt-get update`
2 `sudo apt-get install git`

8.1.3 Instalacion de Git en Windows

Descargar Git aquí y ejecutarlo

9 Introducción a Gogs

La administración de un repositorio de código no es una tarea sencilla de realizar desde consola, como una solución a este problema existe una aplicación Web llamada Gogs (Go Git Service) cuyo objetivo es proporcionar un servicio para la gestión de proyectos en Git (similar a GitHub o GitLab) para servidores propios de manera más fácil, más rápida y con el menor esfuerzo posible. Esto es posible gracias a una distribución binaria e independiente de la aplicación escrita en Go que funciona en todas las plataformas soportadas por el lenguaje, incluyendo Linux, Mac OS X y Windows. Con Gogs podemos controlar Tickets, y administrar los archivos que necesitamos en nuestro proyecto así como contar con el historial de tickets.

¿Cómo se usa?

Ejercicio: El siguiente ejercicio se realizará mediante el repositorio Gogs, la interfaz es la que se puede observar a continuación:

Pasos generales para el desarrollo del ejercicio (no son pasos específicos)

• Entrar a la url que dara el instructor, ejemplo: http://10.13.4.78:3000/
• Registrarse
• Reunirse en equipo, seleccionar un líder y nombre del equipo
• Solo el líder, creará un repositorio, haciendo clic en Fork, al repositorio actual (Creado por el instructor).

• En “Repository Name” asignar un nombre al nuevo repositorio (podría ser el nombre del equipo).

• Agregar a los compañeros de equipo como colaboradores.

• Todo el equipo hace un clon del repositorio en Vagrant desde la máquina virtual después de que el líder haya hecho el Fork.
• Copiar la url del repositorio desde Gogs.

• Desde la consola entrar a /vagrant y ejecutar el comando:

git clone “pegar aqui la url del repositorio que fue copiado previamente”

• En equipo organizarse para seguir realizando los ejercicios que se comenzaron en el tema “Doctest” de forma colaborativa con el repositorio Gogs.
• Cada uno de los integrantes deberá hacer commit, push y pull para actualizar el repositorio de código.
• Para hacer referencia a los “issue” que están el Gogs, cada miembro del equipo deberá colocar “Refs #numero_de_issue_al_cual_se_refiere” dentro del comentario, para poder hacer referencia de la prueba al “issue” como se muestra de ejemplo en la siguiente pantalla:

• Para cerrar el “issue” se cambiará el comando “Refs” por: “fixes #3” como se muestra en la siguiente imagen:

NOTA: Los comandos son los mismos que se encuentran en el tema “8. Repositorio de código Git”.

10 Estándar de código

La falta de establecimiento de un estándar de código hace que sea difícil dar mantenimiento, esto complica el entendimiento de un sistema para la persona que no lo programó y disminuye la calidad del mismo. La programación con diferentes estándares de codificación en un mismo equipo de desarrollo crea conflictos a la hora de subir los cambios al repositorio.

El estándar de codificación brinda calidad a nuestro código por lo cuál es importante, sea cuál sea el lenguaje de programación en el que se esté acostumbrado a programar, ya que para todos los lenguajes de programación existe un estándar de código que se puede adoptar.

Si se está desarrollando de forma colaborativa, todos los desarrolladores deben adoptar el mismo estándar de código con lo cuál, debe parecer que el mismo desarrollador codificó todo el programa. Con un estándar de código establecido se facilitará el mantenimiento del mismo, por ejemplo, añadir nuevas características, modificar las ya existentes, depurar errores, o mejorar el rendimiento.

Por citar algunos ejemplos se mencionan los siguientes:

Identación. Usa 4 espacios por cada nivel de indentación.

¿Tabuladores o espacios?. Nunca mezcles tabuladores y espacios.

Tamaño máximo de línea. Limita todas las líneas a un máximo de 79 caracteres.

No usar espacios alrededor del signo. Igual cuando se encuentre en un listado de argumentos de una función:

• Correcto: def suma(a=0, b=0):
• Incorrecto: def suma(a = 0, b = 0):

No se debe realizar comentarios obvios.

Puedes encontrar mas información sobre el estandar de código aquí

10.1 Python Enhancement Proposals (PEP8).

Está dedicada a la recopilación de los estándares seguidos por los desarrolladores de Python a la hora de escribir código para la librería estándar, éste ejecuta las reglas automáticamente y genera un resultado de las líneas que no cumplen con el estándar de codificación.

Instalación

1 `sudo pip install flake8`

Actualización

1 `pip install --upgrade`

¿Cómo se usa?

Al ejecutar los siguientes comandos se mostraran las violaciónes que estan presentes en el estandar de codigo definido por Python.

1 `flake8 Nombre del archivo.py`
2            ó
3 `pep8 nombre del archivo.py`

Donde mostrará las violaciónes al estándar de código Python de la siguiente manera:

1 `pep8 ejercicio.py`

El siguiente comando cuenta las líneas que hay con error:

1 `flake8 python_lab.py | wc -l`

Ejercicio: Aplicar flake8 ó pep8 al archivo “python_lab.py” observar cuáles errores marca y corregir segun el estandar de python.

11 Pretty Printers: Autopep8

Como se mencionó en el tema anterior cumplir o adoptar un estándar de codificación beneficia a todos los desarrolladores y los problemas que podría ocasionar no seguir ningun estandar. Python cuenta con la librería Autopep8 colaborando con pep8 que indica cuáles líneas de código necesitan darse formato, Autopep8 soluciona estos errores de estándar de codificación y los corrige automáticamente. En otras palabras pep8 encuentra las líneas que necesitan ser corregidas y Autopep8 las corrige automáticamente, ahorrando al desarrollador tiempo en corregir línea por línea.

¿Cómo se usa?

Instalar desde consola

1 `sudo pip install autopep8`

Realizar la corrección del código según el estándar de python

1 `autopep8 --in-place nombre_del_archivo.py`

Ejemplo:

A continuación se muestra un fragmento de código en el cual aplicamos autopep8 para dar formato con el estándar de código de Python.

Después de aplicar autopep8 este es el resultado:

Ejercico: Aplicar autopep8 al archivo “python_lab.py”. En caso de que aun muestre errores, corregir manualmente como en el ejercicio anterior, hasta que no marque ningun error.

12 Introducción a Jenkins

Jenkins es una herramienta de integración continua Open Source para el desarrollo de Software. Se encuentra en ejecución en un servidor que es un contenedor de servlets, como Apache Tomcat. Soporta herramientas de control de versiones como CVS, Subversion, Git, Mercurial, Perforce, Clearcase y puede ejecutar proyectos basados en Apache Ant y Apache Maven, así como scripts de shell y programas batch de Windows.

¿Cómo se usa?

Jenkins permite configurar el tiempo de ejecución de las pruebas de integración.

Nota: Es mala idea integrar el comando de autopep8 (que se encarga de la corrección del estándar de código de Python) ya que se recomienda realizar estas correcciones antes de enviar cambios al servidor.

Ejercicio: Con ayuda del instructor configurar el servidor Jenkins.

• Desde Gogs, el líder del equipo añade un colaborador llamado “Jenkins”.

• Desde Jenkins, seleccionar configuraciones y añadir en “Credentials” a Jenkins para que tenga permisos.

• En “Build triggers” indicar cada cuanto tiempo se realizará la actualización

Formato para realizar las pruebas en un periodo de tiempo.

En el campo “Execute shell” podemos agregar comandos que se quieren ejecutar cada determinado tiempo solo si el servidor encontró cambios, e incluso se puede indicar el directorio en la cuál se desea la ejecución del comando.

• En el campo “Execute shell” agregar el siguiente comando para que lo ejecute el servidor de manera automática:

  python -m compileall .

Este comando compila todo el código a partir de esta carpeta

• Dar clic en “Build now” o “Construir ahora” y observa lo que sucede.

• Añadir un nuevo comando al campo “Execute shell” Este comando nos indica si violamos el estándar de código. Para este caso asignamos un máximo de 160 caracteres por línea de código.

  flake8 –max-line-length=160 .

• Dar clic en “Build now” o “Construir ahora” y observa si tus resultados son satisfactorios.

13 Complejidad Ciclomática

Existen múltiples métricas que de manera predictiva nos ayudan a detectar áreas de nuestro código en las cuáles se presentarán defectos. Una de estas es la Complejidad Ciclomática. La cual se define formalmente como “CC = Número de condiciones + 1”. Esta fórmula fue propuesta por McCabe como una forma simplificada y práctica para calcular la complejidad.

Con base a esta métrica podemos decidir qué funciones y métodos son los más propensos a tener defectos. En la siguiente tabla se evalúan los riesgos dependiendo de la cantidad de complejidad ciclomática.

Tabla: Evaluación del riesgo según la complejidad ciclomática encontrada en un sistema.

¿Cómo se calcula?

Ejercicio:

• Aplicar la siguiente instrucción al servidor Jenkins:

  --max-complexity=2 .

• Este comando permite que el sistema que estamos integrando al servidor tenga una complejidad ciclomática de “2”, la cantidad de complejidad puede cambiar dependiendo de lo que se quiera.

Ejemplo:

1 `--max-complexity=1 .`

14 Refactoring

El término refactoring se refiere a una transformación del código que no afecta la funcionalidad externa del sistema para mejorar la facilidad de comprensión o cambiar su estructura y diseño, con la finalidad de facilitar el mantenimiento en el futuro.

Martin Fowler nos presenta en su libro “Refactoring: Improving the Design of Existing Code”, una excelente guía para aprender más sobre este concepto.

• REFACTORING: IMPROVING THE DESIGN OF EXISTING CODE
• Por: MARTIN FOWLER , ADDISON-WESLEY, 1999
• ISBN: 9780201485677

Datos del libro

• Nº de páginas: 320 págs.
• Encuadernación: Tapa blanda
• Editorial: ADDISON-WESLEY
• Lengua: INGLÉS
• ISBN: 9780201485677

Uno de los conceptos que se presentan en este libro es Code Smell, este concepto se refiere a distintos tipos de errores de diseño que debemos evitar al momento de programar. En la siguiente tabla se muestra un catálogo de algunos de los Code Smells más sobresalientes.

Tabla: Ejemplos de Code Smells.

Se pueden encontrar todos los Code Smells del libro aquí

Ejercicio: Realizar refactoring a las pruebas de TDD del archivo “python_lab.py”.

Nota: El siguiente comando nos permite conocer cuántas líneas de código tiene un archivo:

1 `wc -l nombre_del_archivo`

15 Unit Test

El desarrollo de una aplicación es deficiente si no se cubren pruebas unitarias, existen malas creencias sobre el desarrollo de pruebas unitarias como: “pérdida de tiempo”, “resulta complicado probar el código”, “las pruebas no son importantes”, “no ayudan a mejorar el código”, y una clásica frase de los desarrolladores “mi trabajo es desarrollar, no probar código, ese no es mi trabajo!”, todos estos son algunos ejemplos de los pretextos que pueden tomar los desarrolladores para no realizar pruebas unitarias y las cuáles están completamente equivocadas.

Una prueba unitaria es un método que prueba una unidad de código, lo cual agrega madurez y calidad al desarrollo de Software, desarrollar pruebas unitarias es una de las mejores prácticas que se deben aplicar desde el comienzo de la programación de cada individuo, para que sea adoptado como un buen hábito de desarrollo de Software. Las pruebas unitarias mejoran la calidad de las aplicaciones ya que ayudan a disminuir los errores o bugs, y es menos costoso corregir un error en la fase de desarrollo, ya que tomaría más tiempo encontrar un error cuando el sistema esté en producción. El desarrollo de la pruebas unitarias debería ser creado antes de comenzar la codificación de una manera sencilla y entendible para todos.

Como ejemplo de la redaccion de una prueba unitaria en Python, es la sigueinete funcion, la cuál nos devuelve los minutos de una semana y de dos semanas, conjuntamente se agrega el resultado que se espera obtener al correr la funcion:

Suponga que este es uno de los requerimientos de un sistema y que fue redactado en una historia de usuario.

Para explicar un poco mejor como Python ejecuta las pruebas se explicara de la siguiente manera:

• Def: define la función y el nombre de la función
• Lo que se encuentre entre comiillas triples “”” es tomado como la prueba.
• Lo que va después de >>> es el resultado que esperamos.
• Y enseguida realizamos el código que ejecutara la función.

def minutes_in_weeks(weeks):

1 """ 1: (Task 0.5.1) Minutes in a Week
2 
3 >>> minutes_in_weeks(1)
4 10080
5 
6 >>> minutes_in_weeks(2)
7 20160
8 """

La redacción de esta prueba es fácíl de entender para cualquier desarrollador o tester y también el cliente.

Después de haber redactado todas las pruebas para cada una de las historias de usuario se procede a codificar la función de la siguiente manera (podría ser de una manera diferente según la imaginación del desarrollador).

def minutes_in_weeks(weeks):

1 """ 1: (Task 0.5.1) Minutes in a Week
2 
3 >>> minutes_in_weeks(1)
4 10080
5 
6 >>> minutes_in_weeks(2)
7 20160
8 """

{.python} weeks = 2 r = [60 * 24 * 7 * weeks] print(r) ~

{.python} [20160]

~

16 Code Coverage

Es la cantidad de código medido que indica qué porcentaje de pruebas se están cubriendo. Verificar el Code Coverage de una aplicación aumenta la calidad, ya que entre más cobertura tenga la aplicación, se garantiza que mayor cantidad de código está siendo probado y también se detecta código innecesario, código que no se esta ejecutando o identificar si es importante para el funcionamiento de la aplicación.

Para verificar el Code Coverage de una aplicacion es necesario contar con dos cosas: una herramienta para la generacion de las pruebas unitarias, y alguna aplicación para medir las pruebas, ambas herramientas deben ser compatibles.

Se dice que el Code Coverage es bueno si es arriba de 80%. Osea es bueno si las pruebas se estan cubriendo en una totalidad arriba del 80%.

Para ello Python cuenta con un comando el cuál se agrega a la configuración de Jenkins o el servidor de integración continua que se utilice, para que estas pruebas se ejecuten cada determinado tiempo según la configuración establecida.

Ejercicio: Todos los integrantes del equipo deberan instalar en su maquina Vagrant Code Coverage para Python.

Instalar:

1 `sudo pip install coverage`

Nota: En caso de que no se encuentre instalado.

Ejercicio: Solo el líder de equipo debe agregar el siguiente comando a la configuración de Jenkins:

1 `--with-coverage`
2 `--cover-min-percentage=99`

17 Gitignore

Frecuentemente se necesita que repositorios de código ignoren archivos temporales que las herramientas de desarrollo utilizadas generan. Estos archivos son innecesarios para el correcto funcionamiento del sistema que se esta desarrollando, son importantes para las herramientas de desarrollo como NetBeans, SublimeText, Eclipse etcetera, y cada una de estas, crea conflictos cuando se realiza la integracion en el repositorio.

Para solucionar este problema existe una plaicacion Web llamada .gitignore. Esta aplicacion genera un archivo con las extensiones de los archivos que requieren ser ignorados

Ejercicio Con los siguientes pasos se creara el archivo .gitignore

Un buen lugar para empezar sería generar el archivo “.gitignore” aquí

Esta aplicacion es sencilla de utilizar, simplemente se escribe el nombre de las herramientas de desarrollo que usan el equipo de trabajo. Por ejemplo si alguien utiliza SublimeText y otra persona utiliza NetBeans usarán esas instrucciones. Da clic en “Generar”

Se generará un archivo como el siguiente:

Con el archivo de gitignore.io actualizar el archivo “.gitignore” en tu repositorio de código, una sola persona del equipo realizara commit y push para guardar los cambios.

Todos los miembros del equipo deberán realizar pull para mantener su repositorio local actualizado.

Por último se necesia decirle a git que “olvide” los archivos “basura” que ya tenga guardados.

Para ello siguir las instrucciones que encontraras aquí

18 Pre-commit hooks

¿Cómo evitar que los desarrolladores hagan commit al repositorio si el código no compila? o ¿Cómo asegurar que todos los mensajes de commit sigan cierto formato?

Los pre-commit hooks son pequeños programas que se ejecutan antes de que el desarrollador pueda hacer commit en su repositorio local y por ello son el lugar ideal para correr pequeñas pruebas o cosas que se deben asegurar para mantener el repositorio de código saludable.

Instalar desde la consola pre-commit-hook y algunos otros comandos de interés:

1 `flake8 --install-hook`
2 	ó
3 `pip install git-pre-commit-hook`

NOTA: Podría pedir tener instalado flake8, ejecuta el siguiente comando:

1 `sudo apt-get install python-flake8`

Actualización:

1 `pip install --upgrade git-pre-commit-hook`

Desinstalación:

1 `pip uninstall git-pre-commit-hook`

Ejercicio:

A continuación crear un pre-commit hook que impida que se haga commit de código que no cumple con el estándar o que no compile.

• Entrar al archivo “.git” que se encuentra de manera oculta dentro de la carpeta en la cual se están realizando los ejercicios.

  cd .git

Ahora entrar a la carpeta “hooks que también se encuentra oculta

1 `cd hooks`

Dar un

1 `ls`

para que liste los archivos que contiene esta carpeta

Abrir el archivo “pre-commit” con el siguiente comando:

1 `nano pre-commit`

Modificar la línea de “false” a “true”:

1 Flake8_STRICT, false 
2 	a
3 Flake8_STRICT, true

Guardar y salir.

Modificar el archivo python_lab.py para tratar de violar el estandar de codigo.

Tratar de hacer commit de los cambios. Mostrara como resultado un error que no dejará que suba los cambios ya que se está tratando de subir un código que no cumple con su estándar.

Para mas dudas sobre pre-commit-hook checar el siguiente enlace aquí

19 Ejercicio Generación de tickets: Crear aplicación con Flaskr

El objetivo de este ejercicio es practicar el manejo de un repositorio de código para el control de versiones con el equipo de trabajo.

• El líder de equipo crea un fork del proyecto que el instructor indicará
• Agregar a los colaboradores del equipo
• Cada miembro hace un clon del fork que realizó el líder

Se desarrollará una aplicación básica que consta de:

• Inicio de sesión con “usuario” y “contraseña”
• Captura de mensaje que contendrá “título” y “mensaje”.
• Visualización de todos los mensajes
• Cierre de sesión

Pasos generales:

• Generar tickets a partir del clone del repositorio.
• Cada integrante del equipo debe desarrollar un ticket y subir sus cambios al repositorio para mantenerlo actualizado
• Desarrollar la aplicación siguiendo la especificación de los tickets por cada uno de los integrantes
• Verificar el correcto funcionamiento de la aplicación

Link del tutorial para el ejercicio aquí

NOTA: Dudas o aclaraciones verificar con el instructor del curso.

20 Tarea: investigación de las herramientas vistas con los lenguajes: Java, PHP, C++, .Net, R, Ruby.

Por equipos elegir un lenguaje de programación, del cual se expondrá los siguientes puntos:

1. Buscar el estándar de código de mi lenguaje de programación
2. Buscar la herramienta del check coding standard
3. Buscar la herramienta pretty print (autopep8)
4. ¿Mi lenguaje implementa doctest?
5. Pruebas unitarias de mi lenguaje
6. Code coverage de mi lenguaje
7. Buscar el servidor de integración continua de mi lenguaje.

NOTA: Cada equipo contará con 15 minutos para exponer.

21 Retrospectiva del día 3

Realizar retrospectivas de la misma manera durante un largo tiempo, puede afectar la mejora (que es el propósito principal de una retrospectiva), ya que se deja de aprender. Una manera de seguir aprendiendo y la retrospectiva cumpla su objetivo es aplicando maneras diferentes de realizar retrospectivas, por ejemplo: “The Joel Test”.

The Joel Test

Joel Spolsky describe 12 preguntas para identificar si una empresa de desarrollo para identificar si se esta desarrollando código de calidad. Con estas preguntas es facíl de identificar si se esta desarrollando buen código, cada pregunta vale un punto, si la respuesta es “si”, se realiza la suma de los puntos e indentificara que tan bueno o malo esta desarrolando código una empresa. Según Joel, 12 es perfecto, 11 es tolerable, pero 10 indica que tiene serios problemas.

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec for requirements?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

Por lo tanto, si se es dueño de una empresa o como buen emprendedor pretende iniciar con una empresa de desarrollo debera tomar en cuanta que las empresas que desarrollan con la mejor calidad, tienen una puntacion de 12 como Microsoft, pero en general las empresas en México según los resultados de la aplicacion de este test a alumnos de la maestria en Ingenieria de Software (CIMAT) impartida en Zacatecas arrojaron que las empresas en las que han trabajado o realizado estadias o residencia profesional, calificaron a la empresa con un promedio de entre 4 y 6.

Se sabe que estos aspectos no determinan si una empresa es exitosa o no, pero cumplir con estas doce preguntas, sin duda alguna le ayudaran a formar un equipo de trabajo con disciplina y que genere Software de calidad.

Link Joel Test aquí

Otra manera de realizar las retrospectivas es aplicando el Check-list que sugiere SCRUM. Es una lista de preguntas específicas, las cuales se van marcado si el equipo de trabajo está cumpliendo con esa tarea o actividad, en caso contrario, son las preguntas que se toman en cuenta para realizar la mejora y establecer los compromisos.

Link del Check-list: aquí

22 Pruebas de interfaz de usuario: Selenium IDE

Las pruebas de interfaz de usuario consisten en la implementación de un conjunto de eventos en la UI, como dar clic sobre el sistema y observar que el comportamiento sea el esperado, esta tarea la mayoría de las veces es encargada a estudiantes que se encuentran en una organización realizando estadías por parte de la institución educativa, “trabajo fácil”, pero esto no es enriquecedor para los estudiantes. Para la implementación de pruebas de interfaz ya existe Software que aplica estas pruebas automáticamente, una de las herramientas es Selenium IDE (Integrated Development Environment) es un plug-in de Firefox fácil de utilizar y es generalmente la manera más eficiente de ejecutar para este tipo de aplicaciones, nos permite ahorro de tiempo en su ejecución.

¿Cómo se usa?

Instalación.

• Descargar el navegador Firefox.
• Instalar el Plug-in Selenium IDE aquí

Versión de Selenium que se debe instalar 2.0.9

• Aparecera un icono en la esquina derecha de tu navegador.

Al seleccionarlo mostrará la interfaz siguiente:

NOTA: Para mayor información revisar el link aquí

Pirámide de pruebas

Se recomienda que la cantidad de pruebas desarrolladas y aplicadas sean de la siguiente manera, de mayor a menor (mayor cantidad de pruebas unitarias y menor la cantidad de pruebas de interfaz). Como se representa en la siguiente imagen:

Ejercicio Instalar Selenium IDE y realizar pruebas de interfaz a la aplicacion desarrollada en el tema “19. Ejercicio de generacion de tickets”.

23 Seguridad: SQL Injection, OWASP

Los datos y la información que se generan diariamente en internet es demasiada, por lo cual las aplicaciones Web deben ser sitios seguros, y lo menos vulnerables ante ataques generados por usuarios malintencionados que hacen mal uso de sus conocimientos informáticos y que pueden dañar las aplicaciones. Diseñar aplicaciones Web sin tomar en cuenta la seguridad puede generar graves problemas en algún futuro, sin embargo desarrollar una aplicación segura no es una tarea fácil, pero sí representa un mejor trabajo.

SQL Injection. Es uno de los métodos más utilizados que aprovecha la vulnerabilidad de las aplicaciones para realizar operaciones sobre las bases de datos, el cual debe ser tomado en cuenta por los desarrolladores de aplicaciones Web.

OWASP (Open Web Application Security Project). Es un proyecto de código abierto que proporciona recursos como artículos, libros, capacitaciones, Software de testeo, etcétera, gratuitos para determinar y combatir las causas que hacen que el software sea inseguro, y con ello promover Software seguro y de calidad.