Scrum vs XP

Scrum vs XP

Introducción

En este ensayo se hablará sobre las metodologías agiles Scrum y XP describiendo a cada una, se mencionará el proceso que estas emplean, además de señalar los distintos roles y las funciones estos realizan en dichas metodologías. También se expondrán los artefactos por medio de los cuales se organiza y planifica el proyecto, posteriormente se presentará una tabla en la cual se contrastarán las características de cada una de las metodologías.

Scrum

Esta es un tipo de metodología ágil para llevar a cabo el manejo del desarrollo del software, en este se practica como actividad principal el trabajo en equipo altamente eficiente con el fin de obtener el mejor resultado en el menor tiempo posible sin comprometer la calidad del proyecto. Se basa en la adaptación, auto gestión y se enfoca en construir las funciones más importantes para el cliente además de maximizar el retorno de la inversión. Esta metodología es la indicada cuando los proyectos que se realizan cambian sus requisitos constantemente.

Proceso

En esta metodología se lleva un proceso iterativo e incremental en donde se planifica en diversos bloques temporales, a través de cada iteración llamada Sprint el proyecto va evolucionando, esta se llevan a cabo en un periodo de tiempo de 2 a 4 semanas obteniendo de estas nuevas versiones del software, durante este se van haciendo ajustes, añadiendo o modificando la funcionalidad con el fin de darle mayor valor al negocio para que al final se entregue un producto de calidad cumpliendo con todas las especificaciones estipuladas con el cliente.

Roles

En esta metodología se desempeñan distintos roles con funciones específicas estos son:

• Scrum Master: Esta persona es la que se encarga de supervisar que todos los integrantes se desempeñen correctamente y cumplan con los objetivos establecidos en los sprints respetando todas las normas establecidas y se alineen al proceso de esta metodología.

• Product Owner:Esta persona representa al cliente o al grupo de accionistas a los cuales se está desarrollando el proyecto, este se encarga de revisar las funcionalidades del producto e indica los cambios o mejoras que se le debe de hacer además de Maximizar el valor para el negocio con respecto al Retorno de Inversión (ROI), abogando por los intereses de este.

• Team:Son el conjunto de programadores, diseñadores, arquitectos, testers etc., que se encargan de desarrollar el proyecto llevando a cabo los objetivos que se comprometieron a cumplir en cada sprint. 

• Stakeholders: Son los clientes, proveedores, accionistas etc. a los cuales se está desarrollando el proyecto y son los principales beneficiarios o afectados del resultado que da el producto.

Artefactos

Son las herramientas por medio de las cuales podemos tener una organización en nuestro proyecto ayudando a planificar mejor el proyecto.

• Product Backlog

Es un documento en el cual se establece todos los requisitos del proyecto, es decir se menciona todo lo que se va a hacer, conteniendo la descripción de las funcionalidades que va a tener en donde se especifica el grado de prioridad, el esfuerzo que demanda y los criterios de aceptación.Este solo lo puede modificar el product owner y su contenido está disponible para todos los miembros del equipo.

• Sprint (Ejecución de iteración)

Son las iteraciones que se llevan a cabo en un periodo de tiempo corto y este es fijo, en donde cada miembro del equipo fija los objetivos a completar comprometiéndose de que al final debe de entregar el resultado esperado, de forma que este proporcione un potencial avance en el proyecto.

• Incremento

Es el resultado que el equipo entrega y debe de cumplir con lo definido en el Product Backlog este resultado debe ser funcional y se tiene que marcarse como terminado.

• Sprint Backlog

 Esto son los elementos que se desarrollaran en el Sprint, en este se identifica el trabajo necesario para cumplir los objetivos establecidos,  se detalla todo lo que se va a realizar y tiene la característica de que puede ser modificado durante el transcurso del desarrollo si se encuentran nuevas tareas a realizar así como también se eliminan estas si ya no son necesarias además de que sólo el Equipo de Desarrollo puede realizar cambios en el Sprint Backlog.

•  Burn down chart

Es un diagrama en el cual se representa el progreso del proyecto, cuando se cumple con los objetivos en el tiempo especificado la línea es descendente de tal forma que cuando llegue al eje horizontal el proyecto se concluyó.

Reuniones en Scrum

• Daily Scrum

Son las reuniones que se hacen a diario en las que se habla sobre el progreso del proyecto, lo que se va a realizar en ese día y si se está teniendo alguna complicación.  Esta reunión debe de comenzar puntualmente al igual que todo el equipo debe de presentarse de la misma forma además de que todos los miembros pueden asistir, pero con la restricción de que solo los involucrados pueden hablar.

Esta reunión tiene una duración fija de 15 minutos, todos los asistentes deben de permanecer de pie y tanto la ubicación como la hora de este debe ser la misma siempre.

• Scrum de Scrum

Se llevan a cabo después del Daily Scrum o máximo después de cada dos días, se realizan cuando en la organización hay varios equipos de Scrum, en este se discute lo mismo que en el Daily Scrum pero centrándose en el área de integración, además se habla sobre lo que se va a realizar antes de que se vuelva a llevar a cabo la reunión.

• Sprint Planning Meeting

Se realiza al iniciarse el sprint, en esta se planteará lo que se va a realizar, en qué tiempo además de identificar el trabajo que será necesario para ese sprint y esta planificación deberá de duran 8 horas máximo.

• Sprint Review Meeting

Se realiza después de cada Sprint con el fin de revisar el trabajo, en caso de que sea haya completado se debe de mostrar. El tiempo de duración será 4 hora máximo.

• Sprint Retrospective

Se lleva a cabo al término de cada Sprint en donde entre todos los miembros analizan lo que se realizó con el fin de mejorar el proceso si así se requiere, el tiempo en el que se tiene que llevar a cabo esta reunión es de 4 horas.

XP (Extreme Programming)

Es uno de los muchos tipos que existe de metodología ágil, esta favorece la comunicación tanto entre el equipo como con el cliente, se caracteriza por fomentar el trabajo en equipo además de tener un buen entorno de trabajo, se caracteriza por la simplicidad de sus soluciones y la aceptación de cambios durante el desarrollo. Esta metodología es recomendada para proyecto con requisitos muy cambiantes.

Proceso

El ciclo que se lleva a cabo para esta metodología es:

1.- El cliente por medio de distintos artefactos como historias de usuario define el valor de negocio a implementar.

2. El programador estima el esfuerzo necesario para su implementación y realiza la planificación para realizar el proyecto.

3.- Según las prioridades del cliente y el tiempo en el que este desea el proyecto va a seleccionar lo que se va a desarrollar.

4. El programador construye ese valor de negocio bajo las normas de la programación extrema.

5.- Se realizan las respectivas pruebas al sistema en caso de que haya algún error este será arreglado y se volverá a aplicar la pruebas hasta que estas no arrojen errores.

Ciclo de vida:

El ciclo de vida ideal de XP consiste de seis fases:

Exploración:

Se realiza la toma de contacto con el proceso de negocio que se van a informatizar, así como con la arquitectura y tecnología de desarrollo además de que en esta etapa se realizan las historias de usuario y se analiza la posibilidad de realizar algún prototipo para determinar la viabilidad de proyecto.

Planificación de la Entrega: 

En esta etapa los programadores realizan la estimación del tiempo necesario para implementar cada historia de usuario y obtener es el plan o cronograma de entregas.

Iteraciones:

Se desarrollan las iteraciones que se van a realizar según las historias de usuario, cada una de estas será una actividad que realizará algún miembro del equipo y se llevan a cabo según el tiempo estipulado.

Producción:

Se llevan a cabo distintos tipos de pruebas y revisiones al proyecto antes de ser entregado, también se analiza sobre si se agregaran nuevas características debido a los cambios efectuados, posteriormente el cliente deberá de realizar la aceptación según su criterio o en caso de que no sea así se realizaran las correcciones correspondientes que este manifieste antes de ponerlo en funcionamiento.

Mantenimiento:

En esta fase el sistema ya está en funcionamiento se debe de mantener así por medio de soporte de software y caso de que sea necesario se deberá de aplicar mantenimiento correctivo a este, mientras tanto se siguen desarrollando nuevas iteraciones.   

        

Muerte del Proyecto:

Se presenta cuando ya no ay más historias de usuario a incluir en el sistema, el cliente está totalmente satisfecho con los resultados y por lo tanto no se realizarán más cambios al este, es esta fase se realizará la documentación final del proyecto.

También se puede dar debido a que ya no hay presupuesto para seguir en pie con el desarrollo o este no genera los beneficios que el cliente espera.

Roles

• Programador:Se encarga de definir las tareas según las historias de usuario con esto estima el tiempo que será necesario para la realización de cada una y escribir las pruebas unitarias que se realizaran al sistema para finalmente llevar a cabo la codificación de este.

• Cliente:Lleva acabo la tarea de escribir las historias de usuario asignando su prioridad y también redactara las pruebas funcionales que se aplicaran para validar si se implementara el sistema además de decidir cuál historia de usuario se implementara a cada iteración con el fin de aportar el mayor valor de negocio.

  

• Encargado de Pruebas (tester):Se encarga de ejecutar las pruebas (las cuales ayudo previamente al usuario a hacer)  y difundir los resultados entre todos los miembros del equipo, además tiene la responsabilidad del manejo de las herramientas necesarias para llevar acabo el soporte para las pruebas.

• Tracker(Encargado de seguimiento):Es la persona responsable de dar seguimiento constante al proyecto proporcionando la retroalimentación necesaria a los integrantes del equipo para que puedan desempeñar mejor sus actividades, también se encarga de constatar que el tiempo de estimación concuerde con el tiempo real dedicado según la planeación y difunde estos los resultados con el fin de mejorar las próximas estimaciones.

• Entrenador (coach):Es la persona responsable general del proyecto, experto en dicha metodología, se encarga de corroborar que el proceso se lleve a cabo correctamente y si identifica desviaciones, reclama atención sobre las mismas, también guía al equipo para que este aplique las prácticas de esta metodología y en caso de que surja un problema debe de atajarlo rápidamente.    

• Gestor (Big boss):Se encarga de darle lo necesario al equipo para que este sea eficiente, resuelve los problemas que surgen en el proyecto, dirige las reuniones y es el vínculo de comunicación con el cliente con el fin de alcanzar los objetivos planteados.

• Consultor:Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto pudiendo así guiar al equipo para resolver un problema específico.

• Doomsayer (Augur de desastres):Es el responsable de buscar y difundir los riesgos que pueden surgir en el proyecto con una posible solución además de comunicar las malas noticias de manera sutil.

Artefactos

• Historias de Usuario

En estas se describe una funcionalidad del sistema y por lo tanto definen que es lo que se va a realizar, estas deben de ser cortas, negociables, independientes unas de otras y verificables.

• Prueba de aceptación

Esta prueba se realiza al producto final siguiendo protocolos específicos con el fin corroborar su optimo y completo funcionamiento según lo establecido, esta no la deben de llevar acabo los desarrolladores, con estas pruebas se obtiene un conocimiento más profundo acerca de cómo funciona el equipo.

• Tareas de Ingeniería

Estas especifican las actividades que se llevaran a cabo en cada una de las historias de usuario, se vinculan más al desarrollador debido a que permite tener un acercamiento con el código.

• Plan de Entregas

En este se establece un cronograma donde basándose en las historias de usuario, todos los integrantes del equipo hacen una estimación del tiempo y se acuerdan las entregas que se van a realizar. Luego de algunas iteraciones se recomienda realizar una reunión en donde se vuelva a ajusta este plan si es necesario.

• Tarjetas Crc (Clase – Responsabilidades –Colaboradores)

Por medio de estas se conoce de clases está conformado el sistema y entre ellas cuales tiene una interacción mutua. Estas se dividen en tres secciones: Nombre de la clase, responsabilidad y colaboradores.

• Pruebas Unitarias

Son pruebas que se realizan a cada módulo del sistema con el fin de verificar su correcto funcionamiento.

• Pruebas de Integración

Estas se realizan después de las pruebas unitarias, cuando los distintos módulos de los que se compone el sistema se juntan, y tienen la finalidad de verificar que todos estos funcionan correctamente juntos.

Tabla de Diferencias 

Scrum	XP
Dentro del equipo de Scrum no es posible realizar cambios entre iteraciones, en caso de que estos sean en verdad necesarios el sprint actual se finaliza y se comienza otro nuevo.	XP tiene flexibilidad a cambios entre iteraciones en caso de que estas ofrezcan una mejora y logren mayor eficiencia del producto.
Las iteraciones que se llevan a cabo tienen una duración de 2 a 4 semanas	Las iteraciones duran de 1a 2 semanas
Esta metodología se centra más en la correcta administración y productividad	Esta metodología se preocupa más por la ingeniería y la programación o creación del producto.
En Scrum, el cliente especifica la prioridad de desarrollo de las tareas, pero si el equipo nota que se pueden realizar mejoras estas se llevan a cabo.	En XP la prioridad del desarrollo de las tareas se lleva a cabo estrictamente según las prioridades del cliente.
Las validaciones que se realizan al software son siempre al final de cada Sprint, se realizan en el Sprint Review.	En esta metodología el software es validado durante todo el proceso de desarrollo debido a las pruebas que se redactan al principio de cada una de las actividades.
En está, la forma de trabajo en el equipo es individual.	En esta la forma de trabajo es en parejas.
Cuando se finaliza el Sprint y las tareas definidas en un principio en el Sprint Backlog son finalizadas y aceptadas por el Product Owner no se vuelven a modificar.	Las tareas  que se van terminando siguen siendo susceptibles a ser modificadas durante el transcurso de proyecto, incluso, después de que funcionen correctamente.
El Scrum Master es la única persona que puede autorizar cambios en el código.	Cualquier desarrollador puede modificar partes del código si así es necesario.

Conclusión

Se puede concluir que tanto la metodología SCRUM como la XP son muy parecidas pero cada una tiene diferentes particularidades por las cuales se caracterizan, son la forma en que se organizan y trabajan lo que hace que se note una diferencia entre estas como lo son las iteraciones que realizan y el tiempo que dedican a estas, así como los cambios y la facilidad que se tienen para implementarlos o la forma de codificación etc. es por esto que no se puede decir que una es mejor que la otra debió a que muchas personas se adaptan mejor a la organización de una metodología, por lo tanto las dos tienen la capacidad de ofrecer éxito y calidad como resultado al ser implementadas en los proyectos.   

Referencias

Bahit, E. (21 de Septiembre de 2011). www.desarrolloweb.com. Obtenido de https://www.desarrolloweb.com/articulos/artefactos-scrum.html

es.vaisala.com. (s.f.). Obtenido de http://es.vaisala.com/sp/services/projectservices/Pages/acceptancetesting.aspx

Jeffries, R. (23 de Mayo de 2011). jmbeas.es. Obtenido de http://jmbeas.es/guias/historias-de-usuario/

Valladarez, B. S. (2016). Metodología Ágil Programación Extrema XP.

Wells, J. D. (2001). oness.sourceforge.net. Obtenido de http://oness.sourceforge.net/proyecto/html/ch05s02.html

www.ecured.cu. (s.f.). Obtenido de https://www.ecured.cu/Programaci%C3%B3n_Extrema_o_XP

www.ids.com.mx. (2 de Diciembre de 2014). Obtenido de http://www.ids.com.mx/desarrollo-profesional/comunidad-ids/blog/scrum-4ta-parte-artefactos

Leyes de Lehman

Ejemplos de las Leyes de Lehman

Introducción

En este trabajo se mencionarán las ocho Leyes de Lehman las cuales son una serie de normas que se relacionan con la evolución que poseen los sistemas, generalizando el comportamiento que estas tienen, estarán acompañadas de un ejemplo el cual explica cómo se emplea dicha ley. 

1.- Cambio Continuo

Los sistemas deben de estar en constate actualización con el fin de volverlos más óptimos y eficientes, y que no se conviertan en sistemas inutilizables, un ejemplo se presenta claramente en los sistemas operativos tales como Android, iOS o Windows los cuales constantemente van realizando modificaciones a su sistema, es decir van sacando nuevas versiones de sí mismos.

2.- Complejidad creciente

Un sistema debe de ir creciendo, lo que involucra que este se vuelva más complejo al mismo tiempo de todos sus componentes, un claro ejemplo es YouTube el cual con el paso del tiempo ha ido agregando nuevas funcionalidades (modulos) a su sistema, como lo es la seccione de películas, nuevos campos de tendencias, crear playlist y compartirlos, etc.  

3.- Evolución prolongada de programa (autorregulación)

Esta ley dice que un sistema de mantenerse auto regulado por medio de normas previamente establecidas. Por ejemplo, cuando un sistema tiene que ajustar su funcionamiento con el fin de seguir proporcionando un óptimo servicio, tal es el caso cuando en un sistema operativo, en este caso Windows se les destinan más recursos a las actividades en primer plano que las que se encuentran en segundo plano para asi obtener un mejor rendimiento en las tareas que lo demandan.

4.- Conservación de la estabilidad organizativa

Esta denota que en la evolución de un sistema, el trabajo que se empleara deberá de permanecer fijo durante todo el ciclo de de vida de dicho sistema.Un buen ejemplo es en la programación XP, en donde se estipula que se de trabajar como máximo 40 hrs. Además de los otros factores los cuelas pueden limitar dicho tiempo.

5.- Conservación de la familiaridad

En el sistema los cambios realizados a este deben de ser pequeños con el fin de que tanto el usuario como los desarrolladores puedan seguir interactuando fácilmente con este, por ejemplo, Facebook, esta aplicación se va actualizando tanto en sus funcionalidades como en su interfaz, pero siempre el uso de esta es familiar para los usuarios por lo tanto no tienen problemas al utilizar la nueva versión.

6.-  Crecimiento Continuo

Es cuando en el sistema con el paso del tiempo se va  desarrollando, por ejemplo, Google, esta compañía constantemente está evolucionando, empezó con un motor de búsqueda y después agrego Gmail, Google Maps, Google Play, etc. Es un evidente ejemplo del crecimiento continuo respeto a software.

  

7.- Calidad decreciente

Un sistema se considera decreciente cuando este ya no se adapta a su entorno, por ejemplo, whatsapp, esta aplicación estaba disponible exclusivamente en Smartphone hasta apenas hace un tiempo que los desarrolladores lanzaron whatsapp web, en la cual por medio de un código QR, se puede sincronizar la aplicación con la página web y así poder manipularla desde un pc, en este ejemplo es evidente como este sistema comenzaba a tener calidad decreciente debido a su falta de adaptabilidad.

8.- Retroalimentación del sistema

Es cuando en un sistema se puede manifestar los errores que este tiene, por ejemplo, en YouTube, cuando tiene alguna falla en el sistema manda un código el cual puedes enviar al dicho sistema con el fin de que sea reparado, también existe la posibilidad en algunos sistemas de enviar sugerencias sobre este, para la mejora del sistema.

Conclusión

Como se puede observar las Leyes de Lehman estipulan varias medidas que se deben de seguir para conseguir un sistema funcional tanto internamente ósea en su estructura y módulos de los que se compone como externamente es decir el en el entorno que se encuentra, el cual permanezca en constante evolución, con el fin de que ofrezca a sus usuarios la mejor experiencia al manipularlo y esta sea trascendente.

Referencias 

amazonaws.com. (s.f.). Obtenido de ecaths1.s3.amazonaws.com/soportedesoftware/790345905.Evolucion-del-sw.pptx

Garzas, J. (25 de Julio de 2010). www.javiergarzas.com. Obtenido de http://www.javiergarzas.com/2010/07/leyes-evolucion-software.html

jummp.wordpress.com. (7 de febreo de 2014). Obtenido de https://jummp.wordpress.com/2014/02/07/leyes-de-lehman-introduccion-i/

Métodos Ágiles De Programación

Métodos Ágiles De Programación

Introducción 

En este ensayo se hablará sobre las nuevas metodologías agiles de programación, las cuales debido al entorno moderno que existe hoy día son las más apropiadas, se mencionara cómo funcionan y como por medio de sus 12 manifiestos permite crear software de calidad. También se hablará sobre los distintos tipos de metodologías que existen y las características que estas tienen, enfatizando en la metodología XP, la cual es la más reconocida, se indicara el proceso y las practicas que esta lleva acabo además de los distintos roles que se desempeñan en dicha metodología.

Desarrollo 

Los métodos agiles de programación se basan en la filosofía de que el cliente debe involucrarse en el desarrollo del sistema además de llevarse a cabo un desarrollo incremental con iteraciones cortas. Este tipo de metodología es apropiada para proyectos pequeños en los que se requiera de calidad llevando procesos de manera simple, todo esto es un periodo de tiempo corto. A diferencia de los métodos tradicionales, los cuales son empleados en proyectos más grandes los cuales necesiten tener un alto grado de precisión en el desarrollo de este.

Existen 12 manifiestos en los que se mencionan las características de la metodología ágil.

1.- Lo más importante es satisfacer al cliente por medio de entregas continuas para que así este pueda ver los avances.

2.-Esta metodología acepta cambios en la planificación en cualquier punto del proyecto.

3.- Se dan constantes entregas de software al cliente en un intervalo mínimo de tiempo, en donde este sea funcional.

4.- Tanto el cliente al quien se le esta desarrollando el software como el equipo deben de trabajar juntos durante todo el desarrollo.

5.-El proyecto se tiene que llevar acabo en un entorno agradable para todo el equipo y se les tiene que brindar todo el apoyo durante el proceso.

6.-La comunicación es cara a cara entre todos los miembros con el fin de compartir información.

7.-La forma de medir el progreso que hay en el desarrollo del proyecto es el software funcional.

8.- El proyecto se debe basar en un desarrollo sostenible, capaz de mantener un ritmo constante.

9.- Se debe poner especial atención en la técnica que se lleva acabo y mantener un buen diseño.

10.- Mantener un alto grado de simplicidad en todo el proceso.

11.- Debe de existir una auto organización entre todo el equipo.

12.-Durante el proceso de desarrollo el equipo debe de analizar si pueden optimizar sus técnicas con el fin ser más eficientes.

Existen varios tipos de metodologías simples una de las más importantes es la programación extrema la cual se enfoca principalmente en la capacidad para aceptar cambios y mantener un vínculo entre los integrantes con el fin de que el trabajo en equipo proporcione los mejores resultados  y en caso de que se requiera poder dar una retroalimentación entre miembros del equipo incluyendo al cliente el cual forma parte fundamental de este, además de lograr un buen ambiente de trabajo todo esto para poder ofrecer rápidas soluciones.

En la metodología XP se desempeñan distintos roles:

Programador: Es la persona que lleva a cabo la codificación y pruebas unitarias del sistema.

Cliente: Crea las historias de usuario para poder establecer los requerimientos de software y también las pruebas que se aplicaran al mismo.

Encargado de Pruebas: Escribe, ejecuta y publica los resultados que se arrojan al realizar las pruebas.

Encargado de seguimiento: Con el fin de mejorar la eficiencia del equipo esta persona proporciona la retro alimentación necesaria para que puedan desempeñarse mejor.

Entrenador: Se encarga de dirigir al equipo para que este realice los procesos correctos según la metodología XP.

Consultor: Persona externa al equipo a la cual se le consulta sobre temas en específico.

Gestor: Es el enlace entre el cliente y el equipo además de que se encarga de coordinar el trabajo que se desempeña en este.

El proceso que se debe de seguir en esta metodología es:

·    El cliente fija el valor de negocio a implementar.

·    El programador calcula el trabajo necesario para poder desarrollar el proyecto.

·    El cliente decide que se va a elaborar según sus intereses y el tiempo en el que lo desea.

·    El programador desarrolla lo que el cliente pido.

·    Se repite el proceso.

En esta metodología con el fin de alcanzar el mejor desempeño se llevan a cabo las siguientes prácticas:

El juego de planificación: entre el cliente y los desarrolladores proyectan los objetivos que se quieren alcanzar, con qué medios y en qué tiempo además se acuerdan las entregas en las que se van a estar proporcionando durante este proyecto.

Entregas pequeñas: Los programadores en no más de 3 meses deben de proporcionar entregas funcionales del sistema al cliente.

Metáfora: Por medio de una metáfora se explica cómo funcionara el sistema.

Diseño simple: El sistema se basará en un diseño simple que no comprometa la calidad.

Pruebas: Se realizan constantemente pruebas al sistema, previamente definidas por el cliente.

Refactorización: Con el fin de proporcionar un sistema de mayor calidad durante el desarrollo se modifica y mejora el código para depurarlo y simplificarlo.

Programación en parejas: La codificación se lleva a cabo entre dos personas para reducir los errores y ser más eficientes.

Propiedad colectiva del código: En cualquier momento pueden realizarse modificaciones al código por parte de cualquier programador.

Integración continua: Tan pronto se concluya una parte del código esta se deberá de integrar al sistema.

40 horas por semana: No se debe de trabajar más de 40 hora a la semana con el fin de no desmotivar al equipo.

Cliente in-situ: El cliente se deberá de encontrar disponible y presente durante todo el proceso.

Estándares de programación: Se debe de mantener el código legible entre los programadores siguiendo ciertos estándares.

También existen más tecnologías aparte de la XP aun que son menos reconocidas tales como:

SCRUM: se caracteriza principalmente por las iteraciones que lleva acabo llamadas Sprints las cuales tienes una duración de 30 días y el resultado de estas es mostrado cliente, y por las reuniones que realiza el equipo durante todo el proyecto con el fin de coordinarse.

Cristal Methologies: En esta metodología el trabajo en equipo es fundamental al igual que las personas que lo componen además de que se enfoca en reducir al máximo los artefactos que se producen.

Dynamic Systems Development Method: Se caracteriza por su proceso incremental y la coordinación entre el cliente y el equipo. Sugiere cinco fases: estudio vialidad, estudio del negocio, modelado funcional, diseño, construcción y finalmente la implementación.

Adaptive Software Development: Es iterativo se basa principalmente en los componentes de los cuales se conforma el software además de que acepta los cambios. Sugiere tres fases: especulación, colaboración y el aprendizaje.

Feature-Driven Development: Sus iteraciones son cortas y las fases que sugiere son el diseño y la implementación del sistema.

Lean Development: Se caracteriza por su mecanismo para implementar cambios de la manera más eficiente.

Conclusión 

Se concluye que las metodologías ágiles tales como la XP, SCRUM,Cristal Methologies, etc. empleando sus distintas practicas y desempeñando sus respectivos roles se vuelen la mejor opción para proyectos modernos y pequeños ejecutándose de una manera simple pero sin comprometer la calidad del sistema, por otra parte en esta metodología el cliente es una parte fundamental del desarrollo y además tiene la capacidad de ser más flexible es decir es tolerante a cambios en cualquier parte del proyecto a diferencia de los métodos tradicionales los cuales debido a su rígida estructura no permiten cambios, además de la extensa cantidad de documentación que se produce lo cual no pasa en las metodologías agiles, en estas la documentación es mínima al menos que en verdad sea necesaria será breve, todo esto llevándose a cabo en el menor tiempo posible, por lo tanto estas características vuelven a esta metodología una de las más eficientes en la actualidad.

Referencias 

HOSTING, O. (s.f.). okhosting.com. Obtenido de okhosting.com: http://okhosting.com/blog/metodologias-del-desarrollo-de-software/
José H. Canós, P. L. (s.f.). Métodologías Ágiles en el Desarrollo de Software.

spanishpmo.com. (28 de Octubre de 2011). Obtenido de spanishpmo.com: http://spanishpmo.com/index.php/los-12-principios-del-manifiesto-agil/

Soporte de Software

Soporte de Software

Introducción 

En este ensayo se hablará sobre el soporte de software, se mencionará como funciona, cómo y en donde se lleva a cabo además de quienes son las personas que brindan dicho servicio las cuales deben de ser metódicas y analíticas para proporcionarlo, por otro lado, se señalara cuál es la finalidad que este tiene.

Desarrollo 

El Soporte de Software es un servicio por el cual una organización proporciona asistencia de manera ágil y rápida al sistema ya sea uno que esa misma organización proporciono o un sistema externo.  Por medio de personal capacitado y especializado en dicho sistema. Este servicio se da de manera personalizada al software de cada usuario. Pudiendo así recibir correcciones en caso de que haya algún problema. Esto por medio de un mantenimiento.

Existen cuatro tipos de mantenimiento:

Correctivo: Se enfoca en el cambio o reparación de las fallas que hay en el funcionamiento del sistema.

Adaptativo: Se realizan modificaciones en el sistema posteriormente de su distribución para mantenerlo utilizable en un entorno diferente.

Perfectivo: Agrega o modifica alguna parte del sistema para hacerlo más efectivo

Preventivo: se realizan revisiones al sistema con el fin de prevenir errores o fallas futuras.

Todas estas actividades se realizan con la finalidad del óptimo funcionamiento del sistema haciéndolo así más seguro ante cualquier imprevisto.

Hoy en día existen varios medios por los cuales se puede brindar este servicio tales como vía telefónica o en línea, en los últimos años se ha presentado el soporte vía remota, en donde el técnico se conecta directamente al ordenador del cliente mediante una conexión web, lo cual permite que se lleve a cabo el soporte de una manera más rápida, fácil y segura permitiéndole al técnico diagnosticar el sistema del cliente más a detalle y resolverlo el problema en menor tiempo.

Por otro lado, está el soporte técnico el cual se enfoca más en brindarle ayuda al usuario del sistema, ofreciéndole consejos o dándole instrucciones de como debe usar dicho software con el fin de darle un completo uso y este se ejecute correctamente.

Las áreas en donde se desempeña el soporte de técnico son muy amplias, desde instituciones hasta empresas las cuales la mayoría ya brindan este servicio a los productos que ellos venden, en pocas palabras el soporte de técnico se da en cualquier lugar donde existan equipos que requieran de asistencia para su optimo uso.

Conclusión 

Se puede concluir que el soporte de Software ha ido evolucionando desde sus inicios con el fin de proporcionar una capacidad de respuesta más rápida y más eficiente ya sea en caso de que el problema sea propiamente en el sistema o sea sobre un incorrecto uso de parte del usuario es decir que este no sepa cómo manejar dicho sistema en este caso el soporte técnico tiene que indicarle como operarlo, en caso de que el error sea en el software, se le deberá aplicar algún tipo mantenimiento. Es así entonces que el soporte se ha vuelto fundamental en todas las áreas donde hay sistemas, con la finalidad de que estos funcionen correctamente y así poder aprovechar su máximo desempeño.

Referencias 

Dann Solano. (2 de Marzo de 2013). soportetecnico4ctsmec.blogspot.mx. Obtenido de soportetecnico4ctsmec.blogspot.mx: http://soportetecnico4ctsmec.blogspot.mx/2013/03/definicion-de-soporte-tecnico.html

Porto, Julián Pérez. (2012). Definiciones.de. Obtenido de Definiciones.de: http://definicion.de/soporte-tecnico/

www.softwaredoit.es. (s.f.). Obtenido de www.softwaredoit.es: https://www.softwaredoit.es/definicion/definicion-software-de-soporte.html

www.stieducacion.com. (s.f.). Obtenido de www.stieducacion.com: http://www.stieducacion.com/index.php/servicios/servicios-soporte-tecnico