domingo, 26 de febrero de 2017

Ensayo - Diferencias entre XP & SCRUM

Cuando desarrollamos software, los programadores siempre preferirán una metodología ágil debido a su facilidad de empleo en el proceso de desarrollo y su minúscula documentación, por ello es de gran ayuda conocer las diferentes metodologías que existen, así como sus respectivas cualidades, pros y contras.
Las metodologías más usadas según la  encuesta que realiza anualmente VersionOne, es SCRUM con un 56% de los resultados, seguido de una hibridación entre SCRUM/XP. Saber lo que alguien prefiere puede ser un buen punto de partida para la elección de una metodología a la hora de desarrollar software, conocer sus puntos de vista y sobre todo, sus argumentos que sustentan dicha decisión.
Sin embargo el tema a tratar en este escrito, son las diferencias más significativas entre XP Y SCRUM.


Imagen 1: Cuadro comparativo entre XP y SCRUM




Todas esas características que hacen única a una metodología ágil, también la hace diferentes a las otras, en este caso, podemos ver de una manera gráfica, que hay más diferencias que semejanzas entre XP y SCRUM, sin embargo, se rigen bajo el manifiesto ágil, el cual, a mi parecer, es la semejanza más importante que comparten.
En conclusión, cada metodología es útil para ciertos puntos, mientras una se enfoca en el proceso de administración otra se centra en crear producto funcional. La decisión de utilizar XP o SCRUM, dependerá de nuestro proyecto, es decir, de los elementos que lo conforman, por ejemplo, no se deberá de trabajar con SCRUM si el cliente está disponible para trabajar en el equipo de trabajo, no sería lo óptimo, es por ello, que se necesitar hacer un escrutinio de todos y cada uno de los elementos con los que se cuenta en dicho momento.  



REFERENCIAS



Leyes de Lehman, ejemplos.


1ra Ley “Cambio continúo”:
El ejemplo que se propone, habla sobre como un navegador (Internet Explorer) se vuelve poco satisfactorio a comparación de otros, como Chrome o Firefox. Pongamos de ejemplo a un programador, es poco probable que utilice Explorer, debido al pobre soporte de CSS (Cascading Styles Sheets), y aunque hay estudios que proponen a Explorer como el navegador más seguro, no cabe duda que una de sus deficiencias es su velocidad de búsqueda.
Este es un claro ejemplo de la primera ley de Lehman, en donde si no actualizas tu software, hay altas posibilidades de que se vuelva menos útil para los usuarios.


2da Ley “Complejidad Creciente”:
Para hablar sobre esta ley, tomaré como referencia a un estudiante x. Conforme avanza su trayectoria escolar el grado de complejidad/dificultad aumenta de forma considerable, la estructura cambia, las materias se incrementan y todo evoluciona,  así que no podemos decir que la secundaria tiene el mismo nivel de complejidad que la preparatoria.

3ra Ley “Evolución prolongada”:
Esta ley quiere decir que a medida de que la estructura del software se vuelve más compleja se empieza a restringir los cambios en el sistema. Por ejemplo, en un sistema bancario, las modificaciones son restringidas debido a la alta complejidad de este, y se llegaran a hacer, podrían se catastróficos para la empresa. Este tipo de software, es desarrollado mediante un lenguaje de programación llamado COBOL el cual fue creado en los años 50’s. Es aquí donde nos preguntamos por qué no utilizar otro.
  
4a Ley “Estabilidad Organizacional”:
La producción de una empresa es un claro ejemplo de esta ley. Si producen un producto todos los trabajadores, esta producción se realiza en un tiempo constante y no se ven afectados si cambian a un trabajador, ya que la producción seguirá constante. La 4ta Ley de Lehman se refiere toma como punto de partida el tiempo de vida de un programa y su velocidad de desarrollo, las cuales no se ven afectadas por los recursos dedicados.
En este caso, los recursos son los trabajadores, y el programa, la producción. El programa no se ve afectado si uno de los trabajadores es cambiado, la tarea es la misma. 


5a Ley “Conservación de la Familiaridad”:            
A medida de que un programa evoluciona, todo aquello que esté relacionado con el sistema debe de tener un conocimiento total de su contenido y cambios, por lo que si se vuelve muy complejo, y los participantes no logran adquirir todo el conocimiento necesario, no se podrá mantener un  control. Ejemplo de ello, es un fallo de avión, el cual es una versión más nueva de otro, es decir con nuevas características. Al agregar nuevas características la estructura se hizo más compleja, y los participantes, no logran comprender del todo el funcionamiento, lo que ocasiona la falla.

6a Ley “Crecimiento continuado”:
Instagram y sus “historias”, fue una nueva funcionalidad añadida a la red social más popular para la fotografía, lo que aumento su uso en los usuarios, pasando por encima de Snapchat. Al igual en el año 2017, la funcionalidad para publicar fotos, tuvo un cambio un tanto especial, ahora se pueden publicar más de 1 foto por publicación, tipo collage horizontal.
El crecimiento de este tipo de anexos a esta red ha incrementado su popularidad, colocándola como la 3 red con más usuarios en el mundo (400 millones).



7a Ley “Decrecimiento de la calidad”:
La tecnología wifi de un proveedor no es la misma en todos los lugares, es decir, en lugares poco habitados o alejados de la parte urbana, la calidad de estos servicios disminuye drásticamente, esto, por falta de adaptación de la funcionalidad en dichos lugares, es decir, porque no tienen la infraestructura pertinente para proporciona un servicio equitativo.
A lo que esta ley se refiere, es que la calidad de un sistema se verá disminuida si este no se adapta a cambios de entorno de funcionamiento.






8a Ley “Retroalimentación del sistema”:
Las calificaciones de play store y sus correspondientes comentarios son un ejemplo de esta ley. Cada comentario es tomado en cuenta para que el sistema se mantenga actualizado y con un menor número de defectos.
A esto se le llama retroalimentación, lo que facilita información relevante para nuevas versiones del sistema.





REFERENCIAS


domingo, 12 de febrero de 2017

Ensayo - Soporte de Software


Todos podemos hablar y deducir diversos significados para el software y quizá hasta de su proceso de creación, pero, ¿qué tanto sabemos acerca del soporte de software?, o ¿qué diferencia existe entre el mantenimiento y el soporte de software? Estas interrogativas son problemáticas vivientes que se han ido tratando de diversas maneras, por distintos autores y su correspondiente subjetividad.
Antes de tratar el tema del soporte de software, tendríamos que entender el significado individual de cada una de las palabras de dicha conjunción. “El software de computadora es el producto que diseñan y construyen los ingenieros del software, esto abarca programas que se ejecutan dentro de una computadora de cualquier tamaño o arquitectura” (Pressman, 2010). Conocer este significado nos ayudará a entender la esencia de los párrafos siguientes.
Realmente, el soporte, se define como la atención o asistencia que se le da a un ente, este puede ser, una persona, un objeto o, en nuestro caso, el software. Muchas veces el soporte de software se confunde con el mantenimiento lo cual es un error muy usual; mientras el mantenimiento es “la modificación de un producto de software después de su entrega al cliente o usuario para corregir defectos, para mejorar el rendimiento u otras propiedades deseables” (Barreiro, 2017), el soporte de software es una unificación del soporte técnico con una asistencia sobre el mismo producto.
Es importante mencionar que el mantenimiento de software es confundible con el soporte, debido a las diferentes clasificaciones que se le puede dar, como el correctivo, el cual “localiza y corrige defectos en un programa tras su entrega” (Barreiro, 2017), o bien el perfectivo, en el que se le agregan nuevas funcionalidades al software.

El crecimiento que ha tenido el soporte de software ha enmarcado la creación de nuevas necesidades. Los ingenieros ahora además de crear y diseñar sistemas tienen que saber dar un buen soporte de software. Podemos concluir con que la era del software está en un auge vigoroso, que la creación de sistemas y de las miles de líneas de código que los conforman, no dejaran de presenciarse en nuestra vida en un buen rato, pero no solo eso, sino que su  correspondiente mantenimiento y soporte serán igual de perceptibles.


REFENCIAS
Barreiro, P. S. (11 de 02 de 2017). unican. Obtenido de http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-ii/materiales/tema8-mantenimientoSistemasSoftware.pdf

Pressman, R. S. (2010). Ingeniería de Software - Un enfoque rápido. México: Mc Graw Hill.



Ensayo - Métodos Ágiles


A través de los años, el desarrollo de software ha aumentado de manera desmesurada, esto implica que también crezca y se elabore la extensa documentación cada vez que se crea un producto como lo es el software. “En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término “ágil” aplicado al desarrollo de software” (Canós, Penadés, & Letelier), esto para crear una alternativa al proceso de desarrollo de software tradicional, la cual permitiera elaborar de manera rápida y simple software. ”El objetivo de los métodos ágiles es permitir que una empresa sea ágil” (Carvajal Riola, 2008)
A partir de ese año, se enmarca un nuevo concepto para el desarrollo de software, las metodologías agiles empiezan a surgir como una opción más viable ante los rigurosos métodos tradicionales. Pero para poder decir que se está trabajando con un método ágil, es necesario conocer su filosofía, la cual está embebida en el manifiesto ágil. Este manifiesto consta de 12 puntos clave que se deben de seguir en el desarrollo de software y poder decir que es “ágil”, sin embargo podemos sintetizarlo a 4 puntos:
  • Cliente.
  • Cambios.
  • Simplicidad y funcionalidad.
  • Trabajo en equipo.

Cuando hablamos del cliente, es referirse a la persona que proporciona recursos monetarios y los requerimientos que desee, pero en una metodología ágil es hablar de un miembro más del equipo de desarrollo. “Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito” (Canós, Penadés, & Letelier).
Simplicidad y funcionalidad. Pieza clave en un método ágil. Quizá el punto más importante. Las entregas constantes que se hacen al cliente, su correcto funcionamiento y su respectiva simplicidad, decidirán la trayectoria que tomará el software, claro, aquí dejamos implícito que la retroalimentación con el cliente es esencial.
“Bienvenidos los cambios”. Cuando se aplica un metodología ágil no importa el número de cambios, ni de qué tipo sean, mediante el constante trabajo colaborativo con el cliente, los cambios que se le realizan al software son instantáneos.
Desde que se crearon las metodologías agiles, el desarrollo de software se hizo más fácil, la documentación dejo de pesar y se enfatizó “no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante” (Canós, Penadés, & Letelier). Con dicha filosofía, se han desarrollado diferentes métodos agiles, cada uno enfocándose en algo distinto. Un ejemplo es SCRUM, a comparación de XP (Extreme Programming), SCRUM se basa en sus sprints y reuniones diarias de 15 minutos, mientras que XP se “centra en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo”. (Canós, Penadés, & Letelier).
Hoy en día, cuando desarrollamos software, es necesario analizar todos los elementos del proceso. Es decir saber elegir cuando utilizar una metodología ágil y cuando usar una tradicional. Mientras que la ágil eficaz para proyectos pequeños la tradicional es útil cuando son proyectos a largo plazo, o para empresas que son bastante grandes y que tienen la oportunidad de tener un equipo específico y el tiempo necesario para su finalización.
En conclusión, no siempre es necesaria una extensa documentación si se tiene la oportunidad de trabajar con un método ágil, sin embargo, es inteligente conocer los diferentes factores que pueden decidir o no utilizarlo.


Imagen 1: Mapa Conceptual sobre "Metodologías Ágiles"



REFERENCIAS


Canós, J. H., Penadés, M. C., & Letelier, P. (s.f.). Métodologías Ágiles en el Desarrollo de Software. Valencia: DSIC.

Carvajal Riola, J. C. (2008). METODOLOGIAS ÁGILES: HERRAMIENTAS Y MODELO DE DESARROLLO PARA APLICACIONES JAVA EE COMO METODOLOGIA EMPRESARIAL.