32. Ingeniería del Software y UML: Mercurial.

Mercurial es un sistema de control de versiones multiplataforma, para desarrolladores de software. Está implementado principalmente haciendo uso del lenguaje de programación Python, pero incluye una implementación binaria de diff escrita en C. Mercurial fue escrito originalmente para funcionar sobre Linux. Ha sido adaptado para Windows, Mac OS X y la mayoría de otros sistemas tipo Unix. Mercurial es, sobre todo, un programa para la línea de comandos. Todas las operaciones de Mercurial se invocan como opciones dadas a su programa motor, hg (cuyo nombre hace referencia al símbolo químico del mercurio). (Referencia: Mercurial).

Trigésimo segundo y último episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. Concluimos esta serie aprendiendo sobre Mercurial, ¿qué es? y ¿para qué sirve?.

31. Ingeniería del Software y UML: Calidad y pruebas de software (Parte 5).

JUnit es un conjunto de bibliotecas creadas por Erich Gamma y Kent Beck que son utilizadas en programación para hacer pruebas unitarias de aplicaciones Java.

JUnit es un conjunto de clases (framework) que permite realizar la ejecución de clases Java de manera controlada, para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se comporta como se espera. Es decir, en función de algún valor de entrada se evalúa el valor de retorno esperado; si la clase cumple con la especificación, entonces JUnit devolverá que el método de la clase pasó exitosamente la prueba; en caso de que el valor esperado sea diferente al que regresó el método durante la ejecución, JUnit devolverá un fallo en el método correspondiente. (Referencia: JUnit).

Trigésimo primer episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. Finalizamos el apartado sobre calidad y pruebas de software aprendiendo el manejo del framework JUnit para realizar pruebas se software desarrollados en Java.

30. Ingeniería del Software y UML: Calidad y pruebas de software (Parte 4).

La cobertura de código es una medida (porcentual) en las pruebas de software que mide el grado en que el código fuente de un programa ha sido testeado.

Sirve para determinar la calidad del test que se lleve a cabo y para determinar las partes críticas del código que no han sido testeadas y las partes que ya fueron testeadas,3 además se puede utilizar como técnica de optimización dentro de un compilador optimizador para llevar a cabo una eliminación de código muerto, más específicamente sirve para detectar código inalcanzable. (Referencia: Cobertura de código).

Trigésimo episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. En esta ocasión hablaremos sobre la cobertura de código y la complejidad ciclomática.

29. Ingeniería del Software y UML: Calidad y pruebas de software (Parte 3).

En cuanto a los niveles de pruebas para aplicar en software, existen cuatro que debe superar el programa, aplicación o sistema informático a ser probado. A continuación explicamos cada una de ellas.

En programación, una prueba unitaria es una forma de comprobar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.

La idea es escribir casos de prueba para cada función no trivial o método en el módulo, de forma que cada caso sea independiente del resto.(Referencia: Prueba unitaria).

Vigésimo noveno episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. Hoy continuamos continuamos con la temática de calidad y prueba de software explicando los niveles de pruebas.

28. Ingeniería del Software y UML: Calidad y pruebas de software (Parte 2).

La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. (Referencia: Calidad de Software).

Vigésimo octavo episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. Hoy continuamos viendo en detalle los aspectos necesario que rodean la calidad de un producto software.

27. Ingeniería del Software y UML: Calidad y pruebas de software (Parte 1).

Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Es una actividad más en el proceso de control de calidad.

Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software, así como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento en las actividades de desarrollo. (Referencia: Pruebas de software).

Vigésimo séptimo episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. Para el día de hoy tenemos un tema muy importante en el desarrollo de software, la fase de pruebas.

26. Ingeniería del Software y UML: SCRUM (Parte 2).

SCRUM también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto. (Referencia: Qué es SCRUM).

Vigésimo sexto episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. En esta ocasión nuestro maestro concluirá la sesión sobre SCRUM, un método ágil para el desarrollo de software.

25. Ingeniería del Software y UML: SCRUM (Parte 1).

SCRUM es un modelo de desarrollo ágil caracterizado por:

(1) Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto.
(2) Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos autoorganizados, que en la calidad de los procesos empleados.
(3) Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o de cascada. (Referencia: Scrum).

Vigésimo quinto episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. Hoy nuestro maestro explica lo que es SCRUM y por qué las empresas deberían usar este modelo ágil de desarrollo.

24. Ingeniería del Software y UML: Agilidad, una introducción (Parte 2).

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas. Software funcionando sobre documentación extensiva. Colaboración con el cliente sobre negociación contractual. Respuesta ante el cambio sobre seguir un plan.

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda. (Referencia: Manifiesto por el Desarrollo Ágil de Software).

Vigésimo cuarto episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. Hoy concluimos la introducción al paradigma de la AGILIDAD en el desarrollo de software.

23. Ingeniería del Software y UML: Agilidad, una introducción (Parte 1).

Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en inglés). La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica. (Referencia: Desarrollo ágil de software).

Vigésimo tercer episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. En este episodio realizaremos una introducción a la Agilidad en el desarrollo de software y una descripción de las metodologías que tienen este enfoque.

22. Ingeniería del Software y UML: Los requerimientos (Parte 4).

La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.. (Referencia: Ingeniería de requisitos. Técnicas principales).

Vigésimo segundo episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. En el análisis de requisitos es necesario saber las reglas del negocio con el objetivo de definir el alcance del proyecto.

21. Ingeniería del Software y UML: Los requerimientos (Parte 3).

En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos o Ingeniería de requerimientos1 comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de las partes interesadas, que pueden entrar en conflicto entre ellos.

Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.

El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc. (Referencia: Ingeniería de requisitos).

Vigésimo primer episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. En esta ocasión conoceremos a los participantes de la ingeniería de requisitos.

20. Ingeniería del Software y UML: Los requerimientos (Parte 2).

Sabemos que muchos proyectos de software fracasan porque no se realiza un estudio previo de los requisitos del usuario, no se hace una definición completa del alcance del proyecto. No realizamos el modelado del negocio antes de desarrollar el software, esto significa que el analista no se involucra en el problema; aunque tiene claro que el sistema debe desarrollarse para dar soporte a los procesos de la organización, sino se involucra en la problemática corre el riesgo de que los requisitos identificados no correspondan a las necesidades para lo que se debe crear. (Referencia: Los Requerimientos y su importancia en el desarrollo del Software).

Vigésimo episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. Continuando con el tema dejado en el episodio anterior seguimos ahondando más en lo que son los requerimientos.

19. Ingeniería del Software y UML: Los requerimientos (Parte 1).

Los requerimientos son declaraciones que identifican atributos, capacidades, características y/o cualidades que necesita cumplir un sistema (o un sistema de software) para que tenga valor y utilidad para el usuario. En otras palabras, los requerimientos muestran qué elementos y funciones son necesarias para un proyecto. (Referencia: Definición de Requerimientos).

Décimo noveno episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. Iniciando específicamente el bloque de Ingeniería del Software, hoy iniciamos conociendo acerca de los requerimientos y su importancia en el desarrollo de sistemas.

18. Ingeniería del Software y UML: Diagramas de Secuencia

Un diagrama de secuencia es un diagrama de interacción que destaca la ordenación temporal de los mensajes. Gráficamente, un diagrama de secuencia es una tabla que representa objetos, dispuestos a lo largo del eje X, y mensajes, ordenados según se suceden en el tiempo, a lo largo del eje Y. (Referencia: Diagramas de interacción. El Lenguaje Unificado de Modelado. Booch, Jacobson, Rumbaugh).

Décimo octavo episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. Para esta ocasión aprenderemos in-estenso el apartado referido a los diagramas de secuencia.

17. Ingeniería del Software y UML: Diagramas de Estados.

Los diagramas de estados son uno de los cinco tipos de diagramas UML que son utilizados con el fin de modelar los aspectos dinámicos de un sistema. Este diagrama muestra una máquina de estados. Un caso especial de un diagrama de estados es el diagrama de actividades, donde todos o gran parte de los estados son estados de actividad y todas o la mayor parte de las transiciones se disparan al terminar las actividades en el estado origen. Por lo tanto, un diagrama de actividades y un diagrama de estados son útiles para modelar la vida de un objeto. Pero, si un diagrama de actividades describe el flujo de control entre actividades, un diagrama de estados describe el flujo de control entre estados. (Referencia: Diagramas de estados. El Lenguaje Unificado de Modelado. Booch, Jacobson, Rumbaugh).

Décimo séptimo episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. Nuestro instructor enseña in-estenso el apartado referido a los diagramas de estados.

16. Ingeniería del Software y UML: Diagrama de Actividades.

Los diagramas de actividades son uno de los cinco tipos de diagramas UML que se usan para modelar aspectos dinámicos de un sistema. Un diagrama de actividades es en esencia un diagrama de flujo de control de entre actividades. Un diagrama de actividades no sólo es importante para modelar los aspectos dinámicos de un sistema, sino también para construir sistemas ejecutables a través de ingeniería directa e inversa. (Referencia: Diagramas de actividades. El Lenguaje Unificado de Modelado. Booch, Jacobson, Rumbaugh).

Décimo sexto episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. Nuestro instructor explica in-estenso el apartado que hace referencia a los diagramas de actividades.

15. Ingeniería del Software y UML: Diagrama de Casos de Uso (Parte 6).

Una relación de inclusión es representada como una dependencia, su estereotipo es include. Si queremos especificar la posición en un flujo de eventos en la cual el caso de uso base incluye el comportamiento de otro caso de uso, debemos escribir include seguido del nombre del caso de uso que queremos incluir.

Entretanto, una relación de extensión es representada también como una dependencia, su estereotipo es extend. Los puntos de extensión del caso de uso base se pueden listar en un compartimento extra. Estos puntos de extensión sólo son etiquetas que pueden aparecer en el flujo del caso de uso base. (Referencia: Organización de casos de uso. El Lenguaje Unificado de Modelado. Booch, Jacobson, Rumbaugh).

Décimo quinto episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. Sexta parte donde finalizamos el apartado de diagramas de casos de uso hablando sobre inclusión y extensión.

14. Ingeniería del Software y UML: Diagrama de Casos de Uso (Parte 5).

Si hablamos de organizar nuestros casos de uso, al igual que las clases, éstas pueden ser organizadas agrupándolas en paquetes. Los casos de uso también pueden organizarse especificando relaciones de generalización, inclusión y extensión entre ellos. El objetivo de estas relaciones implican la factorización del comportamiento común y la factorización de variantes. Si de generalización entre casos de uso se refiere, ésta es muy similar a la generalización entre clases. Ésto quiere decir que un caso de uso hijo hereda el comportamiento y significado del caso de uso padre, siendo posible que el caso de uso hijo añada o redefina el comportamiento del caso de uso padre. Además, el CU hijo puede ser ubicado en cualquier lugar donde aparezca el CU padre, siendo que tanto el uno como el otro puedan tener instancia concretas. (Referencia: Organización de casos de uso. El Lenguaje Unificado de Modelado. Booch, Jacobson, Rumbaugh).

Décimo cuarto episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. Quinta parte donde hablaremos sobre la generalización o especialización en nuestros casos de uso.

13. Ingeniería del Software y UML: Diagrama de Casos de Uso (Parte 4).

Generalmente, primero se realiza la descripción del flujo de eventos de un caso de uso de forma textual. Pero con el refinamiento de la comprensión de los requisitos del sistema, estos flujos se pueden representar de forma gráfica por medio de diagramas de interacción. Usualmente se echa mano de un diagrama de secuencia para especificar el flujo principal de un caso de uso, usándose variaciones de ese diagrama con el fin de especificar los flujos excepcionales del caso de uso.

Sabemos que es conveniente separar el flujo principal de los flujos alternativos, porque un caso de uso describe nada más y nada menos que un conjunto de secuencias, pues sería imposible describir en una sola secuencia, todos los detalles de un caso de uso no trivial. A cada secuencia se la denomina escenario. (Referencia: Casos de Uso y Escenarios. El Lenguaje Unificado de Modelado. Booch, Jacobson, Rumbaugh).

Décimo tercer episodio de la serie titulada, INGENIERÍA DEL SOFTWARE Y UML impartido por Demian Gutierrez. Cuarta parte donde conocemos los escenarios, base importante para modelar los casos de uso de nuestro proyecto.