# data[].attributes.body
Lean es una filosofía y un enfoque que hace hincapié en la eliminación de residuos o de no valor añadido trabajo a través de un enfoque en la mejora continua para agilizar las operaciones.
https://www.heflo.com/es/definiciones/lean/

# data[].attributes.body
es un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar
https://es.linkedin.com/pulse/metodolog%C3%ADa-y-marco-de-trabajo-la-gran-duda-gustavo-mart%C3%ADnez-v%C3%A1zquez

# data[].attributes.body
Un Squad es un grupo de 3 a 8 personas con una misión común y formado por diferentes perfiles. Son un equipo más pequeño y multidisciplinar, lo que permite ofrecer soluciones de forma más rápida y más completa, pero estos no son sus únicos puntos fuertes.
https://www.freshpeople.team/blog/6-razones-por-las-que-implementar-o-no-la-metodologia-de-squads#:~:text=%C2%BFQu%C3%A9%20son%20los%20Squads%3F,son%20sus%20%C3%BAnicos%20puntos%20fuertes.

# data[].attributes.body
Definición

Casi todos los equipos ágiles favorecen una estrategia de desarrollo incremental; en un contexto ágil, esto significa que cada versión sucesiva del producto es utilizable, y cada una se basa en la versión anterior agregando funcionalidad visible para el usuario. Estos se denominan incrementos "verticales" (es decir, diferencia entre versiones sucesivas del producto), a diferencia de la estrategia opuesta que entrega sucesivamente componentes técnicos completos: por ejemplo, crear un esquema de base de datos, luego crear reglas de negocio sobre eso, y solo entonces implementar una interfaz de usuario.
¿Qué es el desarrollo incremental? | Alianza ágil (agilealliance.org)

# data[].attributes.body
Planificar con anticipación cuánto tiempo te llevará finalizar una tarea te permite organizar de manera consciente cómo usarás tu tiempo y en qué trabajarás. Esto puede ayudar a reducir los pormenores del trabajo, que actualmente ocupan el 60 % de nuestro tiempo. En lugar de perseguir aprobaciones o buscar documentos, puedes asegurarte de tener al alcance todo lo que necesitas al momento de empezar a trabajar en tu bloque de tiempo.

¿Qué es el timeboxing? 14 ejemplos y casos de uso [2022] • Asana

# data[].attributes.body
El Definition of Done (Definición de hecho en español) es crucial para un equipo ágil. El DoD impulsa la calidad del trabajo y se utiliza para evaluar cuándo se ha completado una historia de usuario, además, asegura la transparencia y la calidad.
Definition of Done ⒹⓞⒹ - Qué es y Cómo hacerlo + 【Ejemplos & Tips】 (beagilemyfriend.com)

# data[].attributes.body
¿Qué es un standup diario?

Los standups diarios son reuniones en las que los equipos ágiles se conectan y alinean rápidamente con el trabajo completado y futuro. Y estas reuniones son realmente rápidas: la mayoría de los standups diarios solo duran unos 15 minutos. Los equipos se reúnen a la misma hora cada día de trabajo para turnarse para compartir lo que trabajaron el día anterior, lo que planean trabajar ese día y los obstáculos que se interponen en su camino. Si bien los standups diarios se han vuelto populares entre los equipos fuera de la
ingeniería y el desarrollo, nos centraremos en los standups
como eventos de scrum para los fines de esta guía.
¿Qué es un stand up diario? | Propósito, beneficios y mejores prácticas | ¡Ajá! software (aha.io)

# data[].attributes.body
es una reunión que se realiza al comienzo de cada Sprint donde participa el equipo Scrum al completo; sirve para inspeccionar el Backlog del Producto (Product Backlog ) y que el equipo de desarrollo seleccione los Product Backlog Items en los que va a trabajar durante el siguiente Sprint.
https://www2.deloitte.com/es/es/pages/technology/articles/ceremonias-scrum.html

# data[].attributes.body
El backlog de un producto es una lista de trabajo ordenado por prioridades para el equipo de desarrollo que se obtiene de la hoja de ruta y sus requisitos.
https://www.atlassian.com/es/agile/scrum/backlogs

# data[].attributes.body
La metodología Agile es un sistema de trabajo que está cambiando el desarrollo de proyectos de muchas empresas, entre ellas, Google, Amazon o Microsoft. Este nuevo concepto triunfa en todo el mundo y ha llegado para quedarse. ¿La clave de su éxito? Organizar y repartir el trabajo de una manera rápida y flexible entre diferentes equipos multidisciplinares.

# data[].attributes.body
Un sprint es un período breve de tiempo fijo en el que un equipo de scrum trabaja para completar una cantidad de trabajo establecida. Los sprints se encuentran en el corazón de las metodologías scrum y ágil, y hacer bien los sprints ayudará a tu equipo ágil a lanzar mejor software con menos quebraderos de cabeza.
https://www.atlassian.com/es/agile/scrum/sprints

# data[].attributes.attachment_link.readable_text
¿Qué son los sprints?

Un sprint es un período breve de tiempo fijo en el que un equipo de scrum trabaja para completar una cantidad de trabajo establecida. Los sprints se encuentran en el corazón de las metodologías scrum y ágil, y hacer bien los sprints ayudará a tu equipo ágil a lanzar mejor software con menos quebraderos de cabeza.

"Con scrum, un producto se basa en una serie de iteraciones llamadas sprints que dividen proyectos grandes y complejos en porciones minúsculas", sostiene Megan Cook, gestora de productos de grupo de Jira Software en Atlassian.

Muchos asocian los sprints de la metodología scrum con el desarrollo de software ágil, hasta tal punto que suelen pensar que las metodologías scrum y ágil son lo mismo, pero no es así. La metodología ágil constituye una serie de principios y la metodología scrum es un marco de trabajo para conseguir resultados.

Las numerosas similitudes que hay entre los valores ágiles y los procesos de scrum suponen una asociación justa. Los sprints ayudan a los equipos a seguir el principio de la metodología ágil de "entregar software de trabajo con frecuencia", así como vivir el valor ágil de "dar respuesta a un cambio por encima del seguimiento de un plan". Los valores de transparencia, inspección y adaptación de la metodología scrum son complementarios a los ágiles y centrales al concepto de sprints.

La guía de la metodología scrum constituye un trabajo preliminar sólido y teórico para este debate sobre los sprints. Nuestro objetivo consiste en arrojar un poco de luz sobre este tema ofreciendo prácticas recomendadas que nos han contado profesionales que llevan a cabo este trabajo cada día.

Cómo planificar y ejecutar sprints de la metodología scrum

Los que inventaron la metodología scrum pensaron en todo: si lo que quieres es planificar tu próximo sprint, tienes disponibles las reuniones de planificación de sprints. La planificación de sprints es un evento de colaboración donde el equipo responde a dos preguntas básicas: qué trabajo se puede llevar a cabo en este sprint y cómo se realizará el trabajo escogido.

Elegir los elementos de trabajo adecuados para un sprint es un esfuerzo de colaboración entre el propietario del producto, el experto en scrum y el equipo de desarrollo. El propietario del producto analiza el objetivo que debería conseguir el sprint y los elementos del backlog del producto que, una vez finalizados, contribuirían a alcanzar dicho objetivo.

A continuación, el equipo crea un plan sobre cómo crearán y finalizarán los elementos del backlog antes del fin del sprint. Los elementos de trabajo elegidos y el plan sobre cómo completarlos se conocen como el backlog del sprint. Al terminar de planificar un sprint, el equipo está listo para empezar a trabajar en el backlog del sprint, es decir, completará todos los elementos del backlog que tengan el estado "En curso".

En un sprint, el equipo comprueba durante el scrum diario, o reunión rápida, cómo progresa el trabajo. El objetivo de esta reunión es descubrir los impedimentos y retos que afectarían a la capacidad de los equipos para alcanzar el objetivo del sprint.

Después de un sprint, el equipo demuestra el trabajo que ha completado durante la revisión. De este modo, el equipo tiene la oportunidad de exponer su trabajo ante las partes interesadas y compañeros antes de poner en marcha la producción.

Completa tu ciclo de sprints con mi reunión favorita: la retrospectiva del sprint. De esta forma, tus equipos tienen la oportunidad de identificar áreas de mejora para el próximo sprint. Así estaréis preparados para el siguiente ciclo de sprints. ¡Adelante!

Qué hacer y qué no hacer

Aun conociendo los conceptos básicos, la mayoría de los equipos tendrán dificultades cuando empiecen a ejecutar sprints. Megan Cook completa este tema con algunas prácticas recomendadas y otras que conviene evitar, y que ella misma ha ido recopilando con los años.

Qué hacer:

Asegúrate de que el equipo defina y entienda el objetivo del sprint, y cómo se cuantificará el éxito. Esta es la clave para mantener a todos coordinados y avanzar hacia una meta común.

Asegúrate de que tienes un backlog bien administrado con tus prioridades y dependencias en orden. Esto puede suponer un gran reto que podría entorpecer el proceso si no se gestiona adecuadamente.

Comprueba que entiendas bien la velocidad y que esta refleje, por ejemplo, las bajas y las reuniones de equipos.

Utiliza la reunión de planificación de sprints para concretar hasta el más mínimo detalle del trabajo que hay que hacer. Anima a los miembros del equipo a esbozar las tareas de todas las historias, los errores y los elementos que se incluyen en el sprint.

Deja fuera el trabajo cuyas dependencias no puedas controlar, como el trabajo de otro equipo, los diseños y la aprobación legal.

Por último, una vez que se tome una decisión o se concrete un plan, asegúrate de que alguien registre esa información en la herramienta de colaboración o gestión de proyectos, como los tickets de Jira. De ese modo, en el futuro todos podrán ver con facilidad tanto cuál fue la decisión que se tomó como el razonamiento que llevo a ella.

Mientras te preparas para convertirte en todo un experto en scrum con estas recomendaciones, también debes tener en cuenta cosas que evitar:

Qué no hacer:

No incorpores demasiadas historias, excedas la estimación de la velocidad ni incluyas tareas que no puedan completarse en el sprint. Debes evitar que tanto tú como tu equipo os aboquéis al fracaso.

No te olvides de la calidad o de la deuda técnica. Asegúrate de incluir el tiempo necesario para el control de calidad y el trabajo que no esté relacionado con las funciones, como los errores y el estado de la ingeniería.

No permitas que el equipo tenga una idea poco precisa de lo que hay en el sprint. Concrétala y no te centres exclusivamente en avanzar rápidamente, ya que podrías cometer el error de olvidar que todos deben ir en la misma dirección.

Además, no asumas una gran cantidad de trabajo desconocido o de alto riesgo. Desglosa las historias que sean extensas o tengan un elevado grado de incertidumbre y no tengas miedo de dejar parte de ese trabajo para el siguiente sprint.

Si los miembros del equipo te comentan preocupaciones sobre la velocidad, la incertidumbre de algunas tareas o el tamaño mayor de lo esperado de algunos elementos de trabajo, no las pases por alto. Aborda el problema y realiza ajustes cuando sea necesario.

Optimiza tus sprints con la automatización

Cuando domines el funcionamiento de los sprints, podrás optimizar procesos con la automatización. En Jira, estas son tres de las reglas de automatización más habituales para sprints.

1. Envía un mensaje de Slack semanal con las incidencias que siguen abiertas en el sprint. Ir a la regla

2. Cuando finalice un sprint, asigna las incidencias pendientes al siguiente sprint. Ir a la regla

3. Cuando una incidencia pasa a "En curso" y el sprint está vacío, mueve la incidencia al siguiente sprint activo. Ir a la regla

Consulta estas reglas de automatización y centenares más en la Biblioteca de plantillas de Jira Automation.
Ir a la biblioteca
Más información sobre los sprints

Los sprints son tan conocidos (y eficaces) que, a menudo, se consideran el primer paso del camino hacia una mayor agilidad. Como hemos visto, para dominar los sprints es preciso dominar también una serie de conceptos de la metodología scrum y ágil que se basan los unos en los otros. Utiliza nuestros otros artículos sobre la metodología scrum para ampliar tus conocimientos y seguir acercándote a la metodología scrum y a todas sus bondades.

Para empezar con buen pie, puedes planificar tu sprint (e incorporar lo que se debe y no se debe hacer) con nuestra plantilla de scrum, que incluye todo lo que necesitas para planificar, supervisar y gestionar el trabajo de los sprints. Además, aprende a utilizar sprints en Jira Software.

# data[].attributes.attachment_link.title
Todo lo que necesitas saber sobre los sprints de scrum

# data[].attributes.attachment_link.description
Un sprint es un período breve de tiempo fijo en el que un equipo de scrum trabaja para completar una cantidad de trabajo establecida. Sigue leyendo para aprender a planificar y ejecutar sprints de scrum.

# data[].attributes.body
El diseño de software es el proceso por el que un agente crea una especificación de un artefacto de software, pensado para cumplir unos objetivos, utilizando un conjunto de componentes primitivos y sujeto a restricciones.
Diseño de software - Wikipedia, la enciclopedia libre

# data[].attributes.attachment_link.readable_text
El diseño de software es el proceso por el que un agente crea una especificación de un artefacto de software, pensado para cumplir unos objetivos, utilizando un conjunto de componentes primitivos y sujeto a restricciones. ​ El diseño de software se puede referir a "toda la actividad implicada en conceptualizar, enmarcar, implementar, poner en funcionamiento y, finalmente, modificar sistemas complejos" o "la actividad que sigue a la especificación de requisitos y precede a la programación, como en un proceso de ingeniería de software estilizado.​

Diseño de software normalmente implica problema solucionando y planeando una solución de software. Esto incluye ambos un componente de nivel bajo y diseño de algoritmo y un alto-nivel, diseño de arquitectura.

El diseño de software es el proceso de visionado y definición de soluciones software a uno o más conjuntos de problemas. Uno de los componentes principales del diseño de software es el análisis de requisitos del software (ARS, del inglés SRA). Se trata de una parte del proceso de desarrollo de software que enumera especificaciones empleadas en ingeniería de software. Si el software está "automatizado" o centrado en el usuario, el diseño de software puede implicar también el diseño de experiencia de usuario que utiliza un storyboard o guion gráfico para ayudar determinar esas especificaciones. Si el software es completamente automatizado (es decir, sin usuario o interfaz de usuario), un diseño de software puede ser tan sencillo como un diagrama de flujo o un texto describiendo una secuencia planeada de acontecimientos. También hay métodos semiestándares como el Lenguaje Unificado de Modelado (UML) y conceptos fundamentales de modelado. En cualquier caso, normalmente alguna documentación del plan resulta como producto del diseño. Además, un diseño de software puede ser independiente de la plataforma o específico de la plataforma, dependiendo de la disponibilidad de la tecnología utilizada para el diseño.

La diferencia principal entre análisis y el diseño de software es que la producción de un análisis de software se compone de problemas más pequeños para solucionar. Además, el análisis no tendría que ser diseñado de manera muy distinta por miembros de equipo diferente. En contraste, el diseño se enfoca a capacidades y, por tanto, múltiples diseños existen y existirán para el mismo problema. Según el entorno, el diseño también varía en función de si se está creando a partir de frameworks fiables o implementando con patrones de diseño adecuados. Ejemplos de diseño incluyen sistemas de operaciones, páginas web, dispositivos móviles o incluso el nuevo paradigma de computación en la nube.

El diseño de software es un proceso y un modelo. El proceso de diseño es una secuencia de pasos que habilita al diseñador para describir todos los aspectos del software a construir. La habilidad creativa, la experiencia, el sentido de qué hace a un "buen" software y el compromiso con la calidad son ejemplos de factores críticos para el éxito de un diseño competente. Es importante tener en cuenta aun así que el proceso de diseño no es siempre un procedimiento sencillo; el modelo de diseño puede ser comparado con los planos de una casa para un arquitecto. Se empieza representando la totalidad de la cosa que se va a construir (p. ej., un renderizado tridimensional de la casa); la cosa se va refinando lentamente para servir como guía a la hora de construir cada detalle (p. ej., la parte de fontanería). Del mismo modo, el modelo de diseño que se crea para el software proporciona una variedad de visiones distintas del software. Los principios básicos de diseño ayudan al ingeniero de software a navegar por el proceso de diseño. Davis sugiere un conjunto de principios de diseño de software que han sido adaptados y extendidos en la siguiente lista:​

El proceso de diseño no tendría que sufrir "visión de túnel." Un buen diseñador tendría que considerar enfoques alternativos, juzgando cada uno basándose en los requisitos del problema, en los recursos disponibles para hacer el trabajo.

El diseño tendría que ser rastreable por el modelo de análisis. Ya que un único elemento del modelo de diseño a menudo puede remontarse a múltiples requisitos, es necesario tener un medio para observar cómo los requisitos han sido satisfechos por el modelo de diseño.

El diseño no tendría que reinventar la rueda. Los sistemas se construyen utilizando un conjunto de patrones de diseño, muchos de los cuales probablemente han sido utilizados anteriormente. Estos patrones deberían ser escogidos como alternativa a la reinvención. Se dispone de poco tiempo y recursos limitados; tiempo de diseño tendría que invertirse en representar ideas verdaderamente nuevas integrando patrones que ya existan (siempre y cuándo esto sea posible).

El diseño debe "minimizar la distancia intelectual" entre el software y el problema tal y como existe en el mundo real. Esto es, la estructura del diseño de software debe, siempre que sea posible, imitar la estructura del dominio del problema.

El diseño tiene que exhibir uniformidad e integración. Un diseño es uniforme si resulta plenamente coherente. Para conseguir esto, las reglas de estilo y formato han de ser definidas para el equipo de diseño antes de que comience el trabajo de diseño. Un diseño está integrado si se ha tomado la molestia en definir interfaces entre componentes de diseño.

El diseño tendría que ser estructurado para adaptarse al cambio. Los conceptos de diseño que se exponen en la próxima sección, habilitan al diseño para conseguir este principio.

El diseño tendría que estar estructurado para degradarse suavemente, incluso cuándo los datos, los acontecimientos o las condiciones operativas son irregulares. El software bien diseñado nunca debería "explotar"; debe ser diseñado para adaptarse a circunstancias inusuales, y si tuviera que terminar su ejecución, habrá de hacerlo de la manera más grácil posible.

El diseño no es codificación, la codificación no es diseño. Incluso cuándo los diseños detallados de procesos están creados para componentes del programa, el nivel de abstracción del modelo de diseño es más alto que el del código fuente. Las únicas decisiones de diseño del nivel de codificación tendrían que referirse a pequeños detalles de implementación para habilitar la codificación del diseño de procesos.

La calidad del diseño tendría que ser evaluado cuando se está creando, no después. Una variedad de conceptos y medidas de diseño están disponibles para asistir al diseñador en la evaluación de la calidad durante el proceso de desarrollo.

El diseño tendría que ser revisado para minimizar los errores conceptuales (semánticos). A veces hay una tendencia a centrarse en minucias cuándo se revisa el diseño. El equipo de diseño tendría que asegurarse de que los elementos conceptuales importantes del diseño (omisiones, ambigüedad, incongruencias) han sido tratados antes de preocuparse por la sintaxis del modelo de diseño.

Los conceptos de diseño proporcionan al diseñador de software una base sobre la que se pueden aplicar métodos más sofisticados. El conjunto de conceptos fundamentales del diseño ha evolucionado. Son los siguientes:

1. Abstracción - la abstracción es el proceso o resultado de la generalización reduciendo el contenido de información de un concepto o un fenómeno observable, típicamente para retener información única que es pertinente para un propósito particular. Es el acto de Representar características esenciales sin incluir los detalles de fondo o explicaciones.

2. Refinamiento - es el proceso de elaboración. Una jerarquía se desarrolla descomponiendo una declaración macroscópica de función de un modo sensato hasta que se logre obtener declaraciones del lenguaje de programación. En cada paso, una o varias instrucciones de un programa dado se descomponen en instrucciones más detalladas. La abstracción y El Refinamiento son conceptos complementarios .

3. Modularidad - La arquitectura de software está dividida en componentes llamados módulos.

4. Arquitectura de software - se refiere a la estructura global del software y las maneras en que esa estructura proporciona integridad conceptual al sistema. Una buena arquitectura de software amortizará la inversión en cuanto al resultado deseado del proyecto, p. ej. en el rendimiento, la calidad, el programa y el coste.

5. Jerarquía de control - Un estructura de programa que representa la organización de un componente e implica una jerarquía de control.

6. Estructural Partitioning - La estructura de programa puede ser dividida horizontal y verticalmente. Las particiones horizontales definen ramas separadas de jerarquía modular para cada función importante. Las particiones verticales sugiere que el control y el trabajo tendrían que ser distribuidos de arriba abajo en la estructura de programa.

7. Estructura de datos - es una representación de la relación lógica entre los elementos individuales de los datos.

8. Procedimiento de software - centra en el procesamiento de cada módulo individualmente.

9. Ocultar Información- los módulos tendrían que ser especificados y diseñados de modo que la información contenida dentro de un módulo es inaccesible a otros módulos, que no tienen ninguna necesidad de conocer esa información.

En su modelo de objeto, Grady Booch menciona Abstracción, Encapsulación, Modularización y Jerarquía como principios fundamentales del diseño de software.​ El acrónimo PHAME (del inglés: Principles of Hierarchy, Abstraction, Modularisation, and Encapsulation) se utiliza a veces para referirse a estos cuatro principios fundamentales.​

Hay muchos aspectos a considerar en el diseño de una pieza de software. La importancia de cada consideración tendría que reflejar los objetivos y expectativas para los que el software está siendo creado. Algunos de estos aspectos son:

Compatibilidad - El software es capaz de operar con otros productos que están diseñado para interoperar con otros productos. Por ejemplo, una pieza de software puede ser compatible con una versión más vieja de sí misma.

Extensibilidad - Las capacidades nuevas pueden añadirse al software sin cambios importantes a la arquitectura subyacente.

Modularidad - El software resultante contiene componentes bien definidos e independientes que llevan a una mejor mantenibilidad. Los componentes podrían ser entonces implementados y probados en aislamiento antes de ser integrados en el sistema de software deseado. Esto permite la división de trabajo en un proyecto de desarrollo del software.

Tolerancia a los fallos - El software es resistente y capaz de recuperarse de los fallos de componente.

Mantenibilidad - Una forma de medir cómo se consiguen los arreglos de errores y las modificaciones funcionales. Una alta mantenibilidad puede ser producto de la modularidad y la extensibilidad.

Fiabilidad (durabilidad del Software) - El software es capaz de realizar una función bajo determinadas condiciones durante un periodo específico de tiempo.

Reusabilidad- La capacidad de utilizar algunos o todos los aspectos del software existente en otros proyectos con pocas o ninguna modificación.

Robustez - El software es capaz de operar bajo tensión o tolerar una entrada imprevisible o inexistente. Por ejemplo, puede ser diseñado con resistencia a condiciones malas de memoria.

Seguridad - El software es capaz de resistir a influencias y actos hostiles.

Usabilidad - La interfaz de usuario del software tiene que ser utilizable para su audiencia objetivo. Los valores por defecto para los parámetros tienen que ser escogidos de modo que sean una buena elección para la mayoría de los usuarios.​

Rendimiento - El software realiza sus tareas dentro de una ventana temporal que es aceptable para el usuario, y no requiere demasiada memoria.

Portabilidad - El software tendría que ser utilizable a través de un número de entornos y condiciones diferentes.

Escalabilidad - El software se adapta bien a un número creciente de datos o usuarios.

Lenguaje de modelado

Un lenguaje de modelado es cualquier lenguaje artificial que puede usarse para expresar información, conocimiento o sistemas en una estructura que está definida por un conjunto consistente de reglas. Estas reglas se utilizan en la interpretación de los componentes dentro de la estructura. Un lenguaje de modelado puede ser gráfico o textual. Ejemplos de lenguas de modelado gráfico para diseño de software son:

Architecture description language (ADL) es un lenguaje que se usa para describir y representar la arquitectura de software de un sistema de software.

Business Process Modeling Notation (BPMN) es un ejemplo de Lenguaje de modelado.

EXPRESS and EXPRESS-G (ISO 10303-11) es lenguaje de modelado estándar internacional de propósito general.

Extended Enterprise Modeling Language (EEML) se usa generalmente para modelado de procesos de negocio a través de varias capas.

Flowchart es una representación esquemática de un algoritmo o proceso.

Fundamental Modeling Concepts (FMC) es un sistema de modelado para sistemas software intensivo.

IDEF es una familia de lenguajes de modelado, entre los cuales destacan IDEF0 para modelado funcional y IDEF1X para modelado de información.

Jackson Structured Programming (JSP) es un método de programación estructurada basado en las correspondencias de las corrientes de datos y la estructura del programa.

LePUS3 es un lenguaje de diseño de descripciones orientado a objetos y un lenguaje de especificación formal que sirve sobre todo para modelar grandes programas orientados a objetos (Java, C++, C#) y patrones de diseño.

Unified Modeling Language (UML) es un lenguaje de modelado general para describir software en cuanto a su comportamiento y su estructura.

Alloy (specification language) es un lenguaje de propósito general para expresar restricciones de estructura complejas y comportamiento en un sistema de software.

Systems Modeling Language (SysML) es un nuevo lenguaje de modelado de propósito general para ingeniería de sistemas.

Un diseñador de software o arquitecto puede identificar un problema de diseño que ha sido visitado y quizás incluso solucionado por otros anteriormente. La plantilla o patrón que describe una solución a un problema común se conoce como patrón de diseño. La reutilización de tales patrones puede ayudar a agilizar el proceso de desarrollo del software.​

La dificultad de utilizar el término "diseño" en la relación a software es que en algunos sentidos, el código fuente de un programa es el diseño para el programa que produce. Hasta el punto en que esto es cierto, el "diseño de software" refiere al diseño del diseño. Edsger W. Dijkstra se refirió a este layering de niveles semánticos como la "novedad radical" de la programación,​ y Donald Knuth utilizó su experiencia escribiendo TeX para describir la inutilidad de intentar diseñar un programa antes de implementarlo:

La documentación de diseño de software puede ser revisada o presentada para permitir restricciones, especificaciones e incluso para ajustar requisitos antes de programar. La redefinición puede ocurrir después de revisar una simulación programada o prototipo. Es posible diseñar software en el proceso de programar, sin un plan o análisis de requisitos, ​ pero para proyectos complejos esto no sería factible. Un diseño por separado con anterioridad a programar permite a los diseñadores multidisciplinares y expertos colaborar con programadores altamente especializados en software útil y técnicamente seguro.

Referencias

1. Ralph, P. and Wand, Y. (2009). A proposal for a formal definition of the design concept. In Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., editors, Design Requirements Workshop (LNBIP 14), pp. 103-136. Springer-Verlag, p. 109 doi 10.1007/978-3-540-92966-6_6.

2. Freeman, Peter; David Hart (2004). "A Science of design for software-intensive systems". Communications of the ACM 47 (8): 19-21 [20]. doi:10.1145/1012037.1012054.

3. Davis, Un:"201 Principios de Desarrollo de Software", McGraw Cerro, 1995.

4. Booch, Grady; et al. (2004). Object-Oriented Analysis and Design with Applications (3rd ed.). MA, USA: Addison Wesley. ISBN 0-201-89551-X. Retrieved 30 January 2015.

5. Suryanarayana, Girish (November 2014). Refactoring for Software Design Smells. Morgan Kaufmann. p. 258. ISBN 978-0128013977. Retrieved 31 January 2015.

6. Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. .

7. Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. ISBN 978-0-470-14111-3.

8. Judith Bishop. "C# 3.0 Design Patterns: Use the Power of C# 3.0 to Solve Real-World Problems". C# Books from O'Reilly Media. "If you want to speed up the development of your .NET applications, you're ready for C# design patterns -- elegant, accepted and proven ways to tackle common programming problems. "

9. Dijkstra, E. W. (1988). "On the cruelty of really teaching computing science".

10. Ralph, P., y Varilla, Y. Una Propuesta para una Definición Formal del Concepto de Diseño. En, Lyytinen, K., Loucopoulos, P., Mylopoulos, J., y Robinson, W., (eds.), Ingeniería de Requisitos del Diseño: Una Perspectiva de Diez Años: Salmer-Verlag, 2009, pp. 103-136

# data[].attributes.attachment_link.title
Diseño de software - Wikipedia, la enciclopedia libre

# data[].attributes.attachment_link.description
El diseño de software es el proceso por el que un agente crea una especificación de un artefacto de software, pensado para cumplir unos objetivos, utilizando un conjunto de componentes primitivos y sujeto a restricciones.

# data[].attributes.body
es una explicación general e informal de una función de software escrita desde la perspectiva del usuario final. Su propósito es articular cómo proporcionará una función de software valor al cliente.
https://www.atlassian.com/es/agile/project-management/user-stories

# data[].attributes.attachment_link.readable_text
Resumen: una historia de usuario es una explicación general e informal de una función de software escrita desde la perspectiva del usuario final. Su propósito es articular cómo proporcionará una función de software valor al cliente.

Es tentador pensar que las historias de usuario son, en pocas palabras, requisitos del sistema de software. Pero no lo son.

Un componente clave del desarrollo de software ágil es poner a las personas en primer lugar, y las historias de usuarios ponen a los usuarios finales reales en el centro de la conversación. Las historias utilizan un lenguaje no técnico para ofrecer contexto al equipo de desarrollo y sus esfuerzos. Después de leer una historia de usuario, el equipo sabe por qué está compilando lo que está compilando y qué valor crea.

Las historias de usuario son uno de los componentes centrales de un programa ágil. Ayudan a proporcionar un marco centrado en el usuario para el trabajo diario, lo que impulsa la colaboración y la creatividad y mejora el producto en general.

¿Qué son las historias de usuario ágiles?

Una historia de usuario es la unidad de trabajo más pequeña en un marco ágil. Es un objetivo final, no una función, expresado desde la perspectiva del usuario del software.

Una historia de usuario es una explicación general e informal de una función de software escrita desde la perspectiva del usuario final o cliente.

El propósito de una historia de usuario es articular cómo un elemento de trabajo entregará un valor particular al cliente. Ten en cuenta que los "clientes" no tienen por qué ser usuarios finales externos en el sentido tradicional, también pueden ser clientes internos o colegas dentro de tu organización que dependen de tu equipo.

Las historias de usuario son unas pocas frases en lenguaje sencillo que describen el resultado deseado. No entran en detalles, ya que los requisitos se añaden más tarde, una vez acordados por el equipo.

Las historias encajan perfectamente en marcos ágiles como scrum y kanban. En el scrum, las historias de los usuarios se añaden a los sprints y se "queman" a lo largo del sprint. Los equipos de kanban introducen las historias de usuario en su backlog y las ejecutan siguiendo su flujo de trabajo. Es este trabajo sobre las historias de usuario lo que ayuda a los equipos de scrum a mejorar en la estimación y planificación del sprint, lo que conduce a un pronóstico más preciso y a una mayor agilidad. Gracias a las historias, los equipos de kanban aprenden a gestionar el trabajo en curso (WIP) y pueden perfeccionar aún más sus flujos de trabajo.

Las historias de usuario son también los componentes básicos de los marcos ágiles más grandes, como los epics y las iniciativas. Los epics son grandes elementos de trabajo divididos en un conjunto de historias, y varios epics constituyen una iniciativa. Estas estructuras más grandes garantizan que el trabajo diario del equipo de desarrollo contribuya a los objetivos de la organización incorporados en los epics y las iniciativas.
Más información sobre epics e iniciativas
¿Por qué crear historias de usuario?

Para los equipos de desarrollo nuevos en la metodología ágil, las historias de usuario a veces parecen un paso más. ¿Por qué no dividir el gran proyecto ( el epic) en una serie de pasos y seguir adelante? Pero las historias dan al equipo un contexto importante y asocian las tareas con el valor que estas aportan.

Las historias de usuario tienen varios beneficios clave:

Las historias centran la atención en el usuario. Una lista de tareas pendientes mantiene al equipo centrado en tareas que deben completarse, pero un conjunto de historias lo mantiene centrado en solucionar problemas para usuarios reales.

Las historias permiten la colaboración. Con el objetivo definido, el equipo puede colaborar para decidir cómo ofrecer un mejor servicio al usuario y cumplir con dicho objetivo.

Las historias impulsan soluciones creativas. Las historias fomentan que el equipo piense de forma crítica y creativa sobre cómo lograr mejor un objetivo.

Las historias motivan. Con cada historia el equipo de desarrollo disfruta de un pequeño reto y una pequeña victoria, lo que aumenta la motivación.

Trabajar con historias de usuario

Una vez que se ha escrito una historia, es hora de integrarla en tu flujo de trabajo. Por lo general, una historia la escribe el propietario del producto, el gestor del producto o el gestor del programa, y la envía para su revisión.

Durante una reunión de planificación de sprint o iteración, el equipo decide qué historias afrontará en ese sprint. Los equipos discuten los requisitos y la funcionalidad que requiere cada historia de usuario. Esta es una oportunidad para ponerse técnico y creativo en la implementación de la historia por parte del equipo. Una vez acordados, estos requisitos se añaden a la historia.

Otro paso común en esta reunión es calificar las historias en función de su complejidad o tiempo hasta su finalización. Los equipos usan las tallas de las camisetas, la secuencia de Fibonacci o el Planning Poker para hacer las estimaciones adecuadas. Una historia debe ser de un tamaño que pueda completarse en un sprint; por lo tanto, cuando el equipo establezca las especificaciones de cada historia, se deben asegurar de dividir las historias que superen ese horizonte de finalización.

Cómo escribir historias de usuario

Piensa en lo siguiente cuando escribas historias de usuario:

Definición de "Listo": la historia suele estar "lista" cuando el usuario puede completar la tarea descrita, pero debes asegurarte de definir lo que representa completarla.

Describe tareas o subtareas: decide qué pasos específicos deben completarse y quién es responsable de cada uno de ellos.

Perfiles de usuario: ¿para quién? Si hay varios usuarios finales, considera crear varias historias.

Pasos ordenados: escribe una historia para cada paso en un proceso más grande.

Escucha el feedback: habla con los usuarios y capta sus problemas o necesidades en lo que dicen. No es necesario tener que estar adivinando las historias cuando puedes obtenerlas de tus clientes.

Tiempo: el tiempo es un tema delicado. Muchos equipos de desarrollo evitan hablar sobre el tiempo, y en su lugar confían en sus marcos de trabajo de estimación. Dado que las historias deberían completarse en un sprint, aquellas que puedan necesitar semanas o meses deberían dividirse en historias más pequeñas o considerarse un epic independiente.

Una vez que las historias de usuario estén definidas de forma clara, debes asegurarte de que todo el equipo pueda verlas.

Plantilla y ejemplos de historias de usuario

Las historias de usuario suelen expresarse con una frase simple con la siguiente estructura:
"Como [perfil], [quiero] [para]."
Desglosemos esta estructura:

"Como [perfil]": ¿para quién desarrollamos esto? No solo buscamos un puesto, buscamos el perfil de la persona. Max. Nuestro equipo debería comprender quién es Max. Con suerte hemos entrevistado a muchos Max. Comprendemos cómo trabaja esa persona, cómo piensa y cómo se siente. Sentimos empatía por Max.

"Quiere": aquí describimos su intención, no las funciones que usan. ¿Qué es lo que están intentando lograr realmente? Esta descripción debería realizarse con independencia de las implementaciones; si describes algún elemento de la IU y no el objetivo del usuario, estás cometiendo un error.

"Para": ¿cómo encaja su deseo inmediato de hacer algo en la perspectiva general? ¿Cuál es el beneficio general que intentan lograr? ¿Cuál es el gran problema que debe resolverse?

Por ejemplo, las historias de usuario pueden tener este aspecto:

Como Max, quiero invitar a mis amigos, para que podamos disfrutar de este servicio juntos.

Como Sascha, quiero organizar mi trabajo, para poder sentir que tengo un mayor control.

Como gestor, quiero poder comprender el progreso de mis compañeros, para poder informar sobre nuestros éxitos y fallos.

Esta estructura no es obligatoria, pero resulta de ayuda para establecer una definición de "hecho". Cuando ese perfil puede alcanzar su valor deseado, la historia está completa. Recomendamos a nuestros equipos definir su propia estructura, y que no se desvíen de ella.

Introducción a las historias de usuario ágiles

Las historias de los usuarios describen el por qué y el qué que hay detrás del trabajo diario de los miembros del equipo de desarrollo; a menudo las historias de usuario se expresan de la siguiente manera: perfil + necesidad + propósito. Entender su papel como fuente de verdad para lo que el equipo está entregando, pero también el por qué, es clave para un proceso sin problemas.

Empieza por evaluar el siguiente gran proyecto o el más apremiante (por ejemplo, un epic). Divídelo en historias de usuario más pequeñas y trabaja con el equipo de desarrollo para mejorarlo. Una vez que tus historias están fuera, donde todo el equipo puede verlas, ya tienes todo listo para empezar a trabajar.

# data[].attributes.attachment_link.title
Historias de usuario | Ejemplos y plantilla | Atlassian

# data[].attributes.attachment_link.description
Resumen: una historia de usuario es una explicación general e informal de una función de software escrita desde la perspectiva del usuario final. Su propósito es articular cómo proporcionará una función de software valor al cliente. Es tentador pensar que las historias de usuario son, en pocas palabras, requisitos del sistema de software.

# data[].attributes.body
El software de gestión de proyectos es un multiplicador de fuerzas. Le ayuda a organizar la gestión del tiempo y de los recursos, a crear informes sobre el rendimiento de la empresa y de los empleados, y a tener una mejor idea de lo que funciona y lo que no. El software de gestión de proyectos también puede simplificar la colaboración en equipo para que sea más fluida que nunca.
Los 10 mejores programas y herramientas de gestión de proyectos de 2023 (top10.com)

# data[].attributes.attachment_link.readable_text
Los listados que aparecen en este sitio web son de compañías de las cuales este sitio web recibe compensación. Esto influye en dónde, cómo y en qué orden aparecen dichos listados en el sitio web.

# data[].attributes.attachment_link.title
Los 10 mejores programas y herramientas de gestión de proyectos de 2023

# data[].attributes.attachment_link.description
Comparamos y revisamos los mejores programas y herramientas de gestión de proyectos para ayudarle a tomar la mejor decisión para su empresa en crecimiento.

# data[].attributes.body
hace referencia a una serie de prácticas utilizadas en el desarrollo de software para ejecutar el desarrollo, la entrega, el feedback y la gestión de calidad de forma simultánea y cada poco tiempo, de acuerdo con un proceso repetitivo. De esta forma, se gana en eficiencia y el cliente puede recibir el producto con mucha más prontitud, incluso cuando todavía no está terminado. La entrega continua genera un feedback constante para el desarrollador procedente de pruebas automatizadas que sirven, en general, para comprobar la estructura después de cada cambio introducido en el código fuente.
https://www.ionos.mx/digitalguide/paginas-web/desarrollo-web/continuous-delivery/

# data[].attributes.attachment_link.readable_text
Continous delivery (entrega continua en español) es un concepto bastante innovador de desarrollo de software que cada vez se escucha con más frecuencia. Gracias a esta práctica, las fases de producción que incluyen el desarrollo, el control de calidad y la entrega, no son definitivas, sino que se repiten de forma automatizada una y otra vez durante todo el proceso de desarrollo a través de un pipeline de continuous delivery. La principal ventaja es que, de esta manera, un software puede someterse cada poco tiempo a controles de calidad en cada una de sus fases de desarrollo, permitiendo realizar entregas, aunque el equipo siga trabajando en el desarrollo del producto final. Además, hay un feedback constante que procede del pipeline, lo que nos permite mejorar el software de forma inmediata tras cada modificación introducida en el código fuente.

Continuous delivery hace referencia a una serie de prácticas utilizadas en el desarrollo de software para ejecutar el desarrollo, la entrega, el feedback y la gestión de calidad de forma simultánea y cada poco tiempo, de acuerdo con un proceso repetitivo. De esta forma, se gana en eficiencia y el cliente puede recibir el producto con mucha más prontitud, incluso cuando todavía no está terminado. La entrega continua genera un feedback constante para el desarrollador procedente de pruebas automatizadas que sirven, en general, para comprobar la estructura después de cada cambio introducido en el código fuente.

Podemos resumir el continuous delivery como un proceso recíproco que integra y automatiza el desarrollo, la entrega, el feedback y la gestión de calidad. El resultado es que podemos simplificar las fases de trabajo para que nos lleven menos tiempo y se completen de forma más eficiente.

Las ventajas del continuous delivery

Antes, el desarrollo de software funcionaba de una manera diferente: el producto final solo se entregaba si todas las funcionalidades estaban totalmente desarrolladas, funcionaban a la perfección y no se detectaban fallos importantes cuando se realizaban las pruebas de calidad. Así que el desarrollador tenía que entregar posteriormente parches o actualizaciones cada cierto tiempo. Gracias al continuous delivery, el cliente recibe el producto en una fase más temprana del desarrollo en la que todavía no ha sido terminado. Esta pre-entrega suele incluir la funcionalidad estructural del software para que el cliente pueda probarla en un entorno real. De esta manera, el propio cliente (o el tester de software) juega un papel muy importante dentro del proceso de control de calidad.

Gracias al feedback recibido, el desarrollador puede mejorar las funcionalidades del producto durante la fase de desarrollo. Además, recibe información muy valiosa que le aporta una idea clara sobre qué funcionalidad debería desarrollar a continuación. Antes de que existiera el continuous delivery, este proceso era realmente tedioso y, a menudo, dejaba descontentas a las dos partes: por un lado, el cliente normalmente espera que un producto final cumpla con sus requisitos y deseos y, por otro, el desarrollador todavía no sabe exactamente cuáles son esos requisitos y deseos. Si se entabla una comunicación sobre el estado de desarrollo del producto en una fase más temprana, es más fácil tener en cuenta los requisitos del cliente y no cometer errores. Es posible ilustrar en forma de ciclo este principio:

Como muestra la imagen, las tres áreas que incluyen el desarrollo, el control de calidad y la producción no se reemplazan por un único proceso, sino que están constantemente interconectadas. De esta forma, un producto pasa por cada una de las fases individuales repetidamente y recibe mejoras continuas. Cuando tenemos que trabajar con muchos clientes al mismo tiempo, es imposible conseguir algo así si no contamos con procesos automatizados. Y en este punto es precisamente en el que interviene la entrega continua ya que se encarga de automatizar todo el proceso.

Gracias al continuous delivery, es posible comprobar los procesos y mejoras implementados sobre el software (es decir, todos los cambios realizados sobre el código fuente) en tiempo real con el fin de conseguir un feedback. Si un cambio genera efectos secundarios no deseados, será posible detectarlos rápidamente, lo que te permitirá implementar las acciones necesarias en una fase temprana del desarrollo. Este punto es realmente una mejora importante porque facilita, por ejemplo, la detección de bugs dentro del código. Sin la entrega continua, detectar dónde se encuentra el error se convierte en un trabajo realmente tedioso.

Hasta que llega al cliente, el software está en una fase intermedia, el pipeline de continuous delivery. En este pipeline se llevan a cabo pruebas manuales y automáticas. Cada fase de pruebas conlleva la aparición de una nueva versión del software (que suele llamarse "versión beta" o en algunas ocasiones "Nightly Build", es decir la última versión creada de forma automática) que, a su vez, entra en el pipeline. Hasta que se hayan pasado todas las pruebas y se reciba un feedback positivo, no se crea una versión "estable" y no se libera oficialmente el producto (este proceso se conoce como "liberación" y también incluye a la propia aplicación publicada). Así aumentan considerablemente las probabilidades de que el cliente reciba un producto sin bugs.

La principal ventaja del continuous delivery es que el proceso automatizado beneficia tanto al cliente como al desarrollador. Para el cliente, la ventaja radica en que el producto estará disponible más rápido y, normalmente, no presentará errores. Para los desarrolladores, implementar pruebas de campo resulta mucho más efectivo que llevar a cabo pruebas durante la fase de testeo beta porque obtienen información y orientaciones mucho más valiosas. Todo el proceso de desarrollo adquiere una mayor flexibilidad y se minimiza el riesgo de publicar software con bugs.

Ventajas

Desventajas

Es mucho más fácil encontrar y eliminar los errores presentes en el software durante la etapa de desarrollo.

Factor de costo: es necesario contar con un servidor potente y fiable de integración de datos para llevar a cabo las pruebas automatizadas y conseguir una liberación correcta y segura del producto.

En el pasado, el desarrollo de software requería muchísimo esfuerzo. Gracias al continuous delivery, los desarrolladores pueden concentrarse exclusivamente en el desarrollo.

Las pruebas automatizadas tienen que funcionar a la perfección y no presentar errores de código. En caso contrario, pueden ocasionar graves daños al ser ejecutadas.

Gracias al pipeline de continuous delivery es mucho más sencillo para los desarrolladores llevar a cabo la resolución de problemas.

Requiere que haya una buena coordinación dentro del equipo porque los cambios introducidos en el código deben compilarse de forma eficiente y con una determinada frecuencia.

Otros procesos de prueba (como las pruebas alfa y beta) conllevan más costes asociados.

Requiere una buena y continua comunicación con los clientes y sus sistemas de destino.

Se pueden dedicar más recursos a la etapa conceptual que a la técnica durante el control de calidad para mejorar el software.

El cliente espera que haya mejoras y actualizaciones continuamente. Es difícil poder "pausar" el proyecto de desarrollo.

Normalmente el desarrollo de software se consigue de forma más rápida porque el proceso de liberación automatizado reduce la carga de trabajo de los desarrolladores y también la cantidad de descansos que deben tomar.

A la hora de implementar innovaciones, mejoras o modificaciones al producto, sigue siendo necesario hacerlo manualmente. Si se quiere automatizar este proceso, es necesario recurrir al continuous deployment.

Gracias a que las publicaciones de software ocurren más rápido y más a menudo, se recibe más feedback lo que se traduce en más mejoras.

El cliente tiene que estar dispuesto a utilizar el software cuando todavía se encuentra en una fase de desarrollo. Además, tiene que poner de su parte y devolvernos su feedback.

Los desarrolladores tienen que soportar menos presión a la hora de realizar cambios en el código fuente porque los errores se encuentran mucho más rápido. Esto sirve como motivación e inspiración para el trabajo.

Las fases del pipeline de continuous delivery

Cuando se produce una modificación en el código, se activa el pipeline de continuous delivery y se ejecutan las pruebas. A continuación, te mostramos las fases que atraviesa:

1. Fase de commit (Commit Stage): en esta primera fase de prueba se ejecutan tests de la versión del software, se desarrollan sus componentes y, cuando es necesario, se compilan. Además, se llevan a cabo las pruebas unitarias pertinentes. Si se superan con éxito todas las pruebas, la fase se da por finalizada. En este momento, se compilan y se almacenan en el repositorio los artefactos binarios de los componentes de software. Por todo lo anterior, se trata de un paquete que afecta decisivamente a la funcionalidad del pipeline porque determina el estado en el que se encuentra el software. Además, este paquete incluye todos los datos que serán instalados en un momento posterior en el sistema de destino. Los resultados de las pruebas en la fase de commit pueden asignarse de esta manera a las modificaciones concretas realizadas sobre el código fuente, que es precisamente una de las ventajas más significativas de la entrega continua.

2. Fase de aceptación (Acceptance Test Stage): en la segunda fase de prueba se ejecutan los tests de aceptación. Estamos hablando de las pruebas de integración (para comprobar si la interacción entre los componentes funciona) y las pruebas necesarias del sistema (para comprobar si el software funciona del lado del usuario). Además, existen otras pruebas opcionales que forman parte de la fase de aceptación, como pruebas de rendimiento y otros tests que ponen a prueba requisitos no funcionales del software. Durante la fase de aceptación, se vuelve a utilizar la compilación ejecutada en la fase previa que pasa a ser instalada en un entorno de pruebas adecuado.

3. En caso de que se constaten errores o complicaciones durante alguna de las fases comentadas, se creará documentación al respecto y, cuando sea necesario, se deberá enviar feedback al desarrollador. Puede enviarse mediante correo electrónico, programas de mensajería o herramientas especiales (que comentaremos más adelante). Cada vez que se produce una modificación en el código, el pipeline se pone en funcionamiento por lo que los mensajes de error siempre hacen referencia a la última modificación. Así, el desarrollador puede reaccionar con rapidez y de forma eficiente para arreglar los bugs o el código defectuoso.

4. Las pruebas manuales se realizan en función de las necesidades concretas de cada caso. A la hora de realizar estas pruebas, el pipeline vuelve a utilizar la compilación creada en la primera fase y la reinstala en un entorno de pruebas adecuado.

5. Si se completan todas las pruebas y el feedback recibido es positivo, ha llegado el momento de instalar el paquete manualmente en el sistema de destino. Normalmente, esto se hace con un solo clic. Es posible automatizar este paso a través del continuous deployment.

Continuous integration vs. continuous delivery

Dentro del mismo contexto en el que encontramos el término continuous delivery, aparece a menudo el término continuous integration. No obstante, hay una diferencia muy importante que afecta al alcance de uno y otro; cuando hablamos de continuous integration estamos haciendo referencia a la automatización del proceso de pruebas. Por lo tanto, el pipeline es un componente compartido con el continuous delivery. En cambio, el continuos delivery es un término que abarca mucho más, concretamente, abarca el proceso de liberación del software como un proceso automatizado. Por lo tanto, la entrega continua complementa al modelo de continuous integration e involucra al usuario final ya que entrega el producto y, simultáneamente, ejecuta las pruebas pertinentes.

Como desarrollador, decidir si basta con utilizar la integración continua o si es preferible ampliar el proceso de desarrollo e incluir el continuous delivery, dependerá de la planificación del desarrollo, del equipo de desarrollo y de la base de clientes. En la siguiente tabla comparamos los dos conceptos:

Continuous integration (CI)

Continuous delivery (CD)

Proceso de pruebas automatizado que revisa en profundidad cada modificación realizada en el código fuente.

Abarca más que el proceso de pruebas e incluye al proceso de entrega. Las nuevas características y las modificaciones realizadas en el código llegan automáticamente al usuario final.

El equipo tiene que ejecutar pruebas automatizadas cada vez que se incluye una nueva característica, mejora o se produce una modificación en el código.

Las pruebas tienen que ser realmente eficaces en el CD porque los resultados se entregan directamente al usuario final.

Requiere un servidor de integración dedicado y continuo que controle y ejecute las pruebas automatizadas.

La instalación en el sistema de destino también debe ser lo más automatizada posible, lo que plantea mayores exigencias al servidor.

Los desarrolladores tienen que fusionar las modificaciones del código con mucha frecuencia y de forma continua.

Los desarrolladores tienen que mantener una buena comunicación con el cliente y saber explicar de forma clara cómo funciona el software.

Requiere un uso relativamente elevado de recursos si se quiere garantizar la calidad del producto en el momento de la entrega.

En el caso del CD el esfuerzo es aún mayor pero el producto puede ser entregado mucho antes tras haber sido sometido a pruebas "reales".

El desarrollo en sí es más eficiente, pero es necesario pausarlo más a menudo debido a las liberaciones manuales.

Permite realizar un desarrollo continuo porque el proceso de liberación está automatizado en gran medida.

Las continuous delivery tools más conocidas

Existen varios programas que nos ayudarán a comenzar a trabajar incorporando la entrega continua. Os presentamos cuatro de los más conocidos.

Jenkins

Jenkins es una aplicación web que facilita la integración continua de los componentes del software. Jenkins está escrito en Java, se ejecuta en un contenedor EJB y dispone de varias herramientas de build (Apache Ant, Maven/Gradle, CVS, Subversion, Git, etc.) y, por supuesto, de los procesos de pruebas automáticas tan importantes en el caso del continuous delivery (Junit, Emma). Existen plugins opcionales que sirven para garantizar la compatibilidad con otros compiladores. Gracias a su interfaz basada en REST, otros programas pueden acceder a Jenkins. Jenkins es un programa gratuito de código abierto. Está recomendado especialmente para principiantes porque su interfaz y las funcionalidades que ofrece son muy intuitivas y fáciles de usar.

Echa un vistazo a nuestro tutorial de Jenkins sobre el funcionamiento de la aplicación paso a paso.

CircleCI

CircleCI también es una aplicación web para continuous integration, delivery and deployment. CircleCI funciona preferiblemente con GitHub, GitHub Enterprise y Bitbucket. Además, la plataforma ofrece muchas funcionalidades prácticas como la gestión de pedidos, gestión de recursos, docker support, soporte de todos los lenguajes de programación conocidos, almacenamiento seguro en caché, análisis de datos con estadísticas y completos conceptos de seguridad. CircleCI recibió el premio "Leader in Continuous Integration" de Forrester en 2017. El primer contenedor es gratuito y a partir del segundo el precio es de 50 $ por contenedor al mes.

Microsoft Team Foundation Server

Microsoft Team Foundation Server (TFS) es una herramienta colaborativa para proyectos de software que tienen que planificarse, desarrollarse y finalmente ser gestionados de manera conjunta. TFS es el sucesor no oficial de Microsoft's Visual SourceSafe. Para permitir el trabajo colaborativo en los proyectos de software, TFS soporta varios procesos de desarrollo, incluido el CMMS, el desarrollo de software ágil y Scrum. Además, TFS está vinculado e integra programas de Office muy conocidos como Word y Excel para que no tengas que salir de TFS y abrir otro programa.

Existen varias características que te permiten crear un pipeline para continuous integration, delivery and deployment. Lo que hace TFS básicamente es dividir el proceso completo en varios apartados: control de versiones, build, reports y administración de usuario.

Los equipos de hasta 5 personas pueden utilizar de forma gratuita la versión Express. Los equipos más grandes deberán hacerse con la versión comercial que tiene un precio aproximado de 6 euros por usuario al mes. Pero normalmente esto conlleva la obligación de comprar una licencia de servidor. También es posible hacerse con TFS sin suscripción mensual, aunque para ello tienes que contactar con tu distribuidor local. El precio se encuentra entre los 500 y los 700 euros.

Codeship

Codeship es una plataforma SaaS de integración continua (y de entrega) que se adapta a las necesidades particulares de cada usuario. Codeship soporta GitHub, Bitbucket y GitLab. Las funcionalidades disponibles dependen del plan contratado. Por ejemplo, en su versión gratuita, Codeship ofrece un entorno CI predefinido y flujos de trabajo CI/CD. Además, la versión gratuita permite realizar un almacenamiento de caché eficiente y pruebas de builds simultáneas en contenedores compartidos y preconfigurados. El plan gratuito incluye 100 builds al mes, un continuous build y un pipeline de pruebas. Destacamos el hecho de que no hayan establecido un límite de proyectos, usuarios o equipos máximos permitidos.

Si queremos sacarle más partido a Codeship, podemos comprar el plan "Codeship Basic", que cuesta aproximadamente 45 euros al mes y va incrementando su precio en función del tamaño del equipo. Existe también otra versión de pago, la "Codeship Pro", que aporta una funcionalidad adicional tutorial para docker, el "control completo" sobre el entorno de build, los builds locales y un mejor control del flujo de trabajo. Además, ofrece muchas herramientas que ayudan a ganar en eficiencia y transparencia. El precio varía en función del número de builds paralelos, pero es aproximadamente de 70 euros mensuales.

# data[].attributes.attachment_link.title
Continuous Delivery - Pipelines en el desarrollo de software

# data[].attributes.attachment_link.description
Continous delivery hace referencia a una serie de prácticas de desarrollo de software para automatizar procesos, haciendo más eficiente el trabajo.

# data[].attributes.body
El desarrollo de software, es una de las ramas de la ingeniería que se en enfoca principalmente a lo que es la creación de sistemas informáticos… pero ok, todo eso ya lo sabes, no necesito decirte qué es el desarrollo de software en esta instancia. De hecho está de más que te explique pues si estás aquí es porque vienes a buscar herramientas de desarrollo de software y es precisamente lo que vamos a ver a continuación.
Herramientas de Desarrollo de Software | Software de Desarrollo (okhosting.com)

# data[].attributes.attachment_link.provider_name
OK HOSTING | Hospedaje Web, Dominios, Desarrollo de Software, Marketing Online, SEO

# data[].attributes.attachment_link.readable_text
El desarrollo de software, es una de las ramas de la ingeniería que se en enfoca principalmente a lo que es la creación de sistemas informáticos ... pero ok, todo eso ya lo sabes, no necesito decirte qué es el desarrollo de software en esta instancia. De hecho está de más que te explique pues si estás aquí es porque vienes a buscar herramientas de desarrollo de software y es precisamente lo que vamos a ver a continuación.

El desarrollo de software, también conocido como el ciclo del software, se compone por diversas etapas que dependen precisamente de qué es lo que se está llevando a cabo, cada una de esas etapas cuenta con distintas Herramientas de Desarrollo de Software y hoy vamos a ver cada una de ellas, para que sin importar en que fase de desarrollo te encuentres, tengas la posibilidad de usar distintas herramientas de software que te faciliten la vida en gran manera.
Las etapas del desarrollo del software más establecidas o comunes, son las siguientes:
1. Modelaje
2. Desarrollo
3. Pruebas
4. Depurado
5. Diseño

Ahora bien, cada una de las etapas llevadas a cabo en el desarrollo de software, cuenta con sus distintas herramientas. Estas herramientas tienen como finalidad, el disminuir el estrés y los tiempos de cada fase, para además mejorar los resultados obtenidos y dar mejores propuestas al cliente. Además de que claro, el nivel de satisfacción con el uso de herramientas es mucho mayor que sin ellas. Por eso a continuación, vamos a ver las mejores herramientas para el desarrollo de software en cada una de las etapas o fases que conlleva el proceso.

Herramientas para Modelado de Software

El modelado de software es el primer paso antes de desarrollar cualquier tipo de sistema. Normalmente el modelado se basa en la creación de Diagramas que explican el funcionamiento del software a desarrollar, eso hablando de algún ejemplo básico. Regularmente se utilizan los diagramas UML, los cuales permiten que mediante un diseño abstracto, los desarrolladores y el cliente definan el sistema, su funcionamiento y sus funcionalidades. A continuación, algunas de las herramientas de modelado de software, que te permitirán crear los famosos diagramas UML.

* Diagramas UML Online de Lucidchart. Una de las mejores opciones hoy en día para la creación de Diagramas UML, es el servicio online de Lucidchart. Este sitio web, nos da la posibilidad, no solamente de crear los diagramas en linea, si no además, de trabajar en conjunto con un equipo de desarrolladores o más personas de forma simultanea. Con la ventaja de que los diagramas UML que se realicen en linea, pueden ser descargados y abiertos de forma offline con el programa Visio, uno de los tradicionales para la creación de los Diagramas UML.Por si fuera poco, Lucidchart nos da la posibilidad de compartir los diagramas elaborados en linea, ya sea con nuestros compañeros de equipo o realmente donde te de la gana. Son parte de las cosas que obtendrás con el servicio de Lucidchart para la creación de tu diagrama UML.

* Herramienta UML de Altova. Con un diseño mucho más tradicional, un trabajo visual bastante retro y amigable para los que llevamos años trabajando el desarrollo de software, tenemos la Herramienta de modelado de Altova. Destaca principalmente por ser una herramienta de modelo visual y dinámica, la cuál te irá llevando de la mano en el proceso de creación de tus diagramas UML. Por si esto fuera poco, permite lo que es la generación de código UML, algo que algunas herramientas de modelado software no ofrecen.Además, con Altova y su herramienta UML, podrás hacer lo que es la transformación de código en diagramas UML, aplicando la ingeniería inversa de la cual seguramente ya haz escuchado y por supuesto podrás tener a tu alcance toda la documentación que necesitas para trabajar sin ningún problema.

* MagicDraw UML. A diferencia de las dos primeras, MagicDraw UML, es una de las herramientas CASE para el diseño de diagramas UML. Más específicamente el sistema No Magic que se puede encontrar dentro de ella. El objetivo de MAgicDraw, como herramienta CASE, no es solamente crear diagramas UML, estos los estaremos viendo más adelante, pero si ya sabes lo que son las herramientas CASE, entonces adelante, deberías proceder a descargarla. Pues básicamente se trata de una herramienta de desarrollo, análisis y diseño bastante completa que seguramente no querrás dejar de utilizar.

Herramientas de Desarrollo de Software

Una ves que ya contamos con lo que son los Diagramas UML en la parte del modelado de software, es momento de pasar al desarrollo. Aunque no lo creas, esta etapa es de las más laboriosas y complicadas, dependiendo claro de tu equipo de trabajo, pero también del lenguaje de programación que estés dispuesto a utilizar. Pero por ejemplo, para la mayoría de los lenguajes conocidos, contamos con sus respectivos IDE. Si eres de los que apenas estudiaron desarrollo de sistemas informáticos esta década, se sonará familiar el IDE Netbeans de Java. Pues estos Ambientes de Desarrollo Integrados, también se encuentran disponible para otros lenguajes de programación.

Entre estos lenguajes de programación con IDE disponible, se encuentra: .Net de Microsoft, C y PHP. Así que tendrás la comodidad de contar con un ambiente amigable, que te permitirá escribir código y analizarlo para mostrarte en que parte de la sintaxis estás incorrecto. Además permiten compilar el código escrito para posteriormente realizar pruebas y hacer las respectivas depuraciones. Todo esto con elementos visuales y amigables que permitirán que no te sientas solo al momento de estar desarrollando en cualquiera de estos lenguajes de programación.

Así que dependiendo del lenguaje que elijas, te recomiendo buscar su IDE o algún tipo de IDE, un ambiente que haga que el desarrollo sea amigable.

Herramientas para Hacer Pruebas del Desarrollo de SW

La tercera etapa del proceso de desarrollo de software, son las pruebas. Digamos que una ves que ya llevas la implementación en un buen avance o incluso aunque no lleves casi nada, siempre querrás realizar algunas pruebas de código, para verificar que lo que estas haciendo o las funciones que estás agregando funcionen. Es por eso que siempre será necesario, contar con herramientas para desarrolladores que les permitan ejecutar el código en modo prueba. Toma en cuenta que si haz estado trabajando con un ambiente IDE, posiblemente este mismo ya cuente con la posibilidad de hacer pruebas a tu software. Por ejemplo, si haz estado trabajando con Eclipse o Netbeans, que son IDE's de lenguaje Java, ambas plataformas cuentan con la posibilidad de hacer pruebas directamente en el ambiente, pero si no es así, entonces checa los que tenemos a continuación.

* Selenium. Posiblemente una de las mejores plataformas para hacer pruebas que podrás encontrar. Originalmente Selenium es un IDE, sin embargo en web podemos encontrar lo que es la herramienta para hacer pruebas. Afortunadamente el lenguaje de Selenium es compatible con lenguajes muy conocidos como Java, C#, Ruby, Groovy, Perl, Php y Python. Por lo que sin importar cual es el lenguaje con el cual haz trabajado, podrás hacer las pruebas debidas para el desarrollo que estás llevando a cabo.A diferencia de otras herramientas, Selenium es una herramienta para desarrollo web, pues la podemos utilizar en linea sin necesidad de descargarla y hacer nuestras pruebas correspondientes.

* JMeter. Seguramente la J al principio te dirá de que lenguaje se trata. Bueno, pues Jmeter es una aplicación de escritorio desarrollada en Java, utilizada principalmente para el testeo de aplicaciones web en un ambiente local. Es decir, no tienes que andar montando nada en un servidor web aún, con el código que tienes, simplemente trabaja con Jmeter y ejecuta las pruebas que requieras. Tendrás además la ventaja de que Jmeter se ejecuta bajo los siguientes protocolos HTTP, HTTPS, SOAP, JDBC, LDAP, JMS, Mail - POP3(S) and IMAP(S). Así que seguramente te será de gran ayuda para la ejecución de pruebas.

* Testlink. Si ya andábamos hablando de Jmeter y de Selenium, sin duda no podíamos dejar de lado a Testlink. Esta es una herramienta para mejorar la calidad de nuestras pruebas, que tiene la ventaja de ser Open source, así que no te costará nada proceder a descargarla. Su objetivo es crearnos un ambiente de pruebas más productivo y no solamente el tradicional "funciona" o "no funciona". De hecho, al ejecutar nuestras pruebas con Testlink, podemos dar solución a algunas preguntas enfocadas a nuestro código fuente como los requisitos que necesitamos, qué tipo de test queremos ejecutar, cuanto es lo que se ha progresado, si se necesitan hacer cambios o que tipos de pruebas deseamos hacer.Todo esto, con la ventaja que una plataforma como Testlink, nos da para hacer la ejecución de pruebas.

Herramientas para Depurar Código

La Depuración, es un proceso que posiblemente a muchos no nos enseñaron en la universidad. La realidad es que este paso se hace de forma intuitiva teniendo el conocimiento del lenguaje bajo el cual estamos trabajando. Y su objetivo es que durante la ejecución de los procesos, tengamos la habilidad para encontrar los errores del código y tratemos de solucionarlo. Básicamente no es como la compilación, donde el sistema te dice donde están tus errores, el debugger es una de esas herramientas para el desarrollo de sistemas, que necesita que tu al momento de ver el error, trates de corregirlo. Obviamente lo puedes intentar una y otra ves. Así que vamos a ver, cuales son algunas de las mejores herramientas del software para depurar código.

* GNU Debugger. Uno de los principales depuradores y que seguramente ya conoces, pues es proveniente de GNU, es este. Tiene la habilidad principalmente de ser portable y de tener compatibilidad con algunos lenguajes de programación que son comúnmente utilizados, tales como C, C++ o Fortran. Se podría decir que GNU Debugger es una software para desarrollar apps que te ayudará en el proceso de depuración en tiempo real. Con la ventaja de que durante la depuración, tendrás la posibilidad de cambiar valores a lo que se está ejecutando, de esta forma se convierte en una de las herramientas para programadores más indispensable.

* Debugger de Firefox y Chrome. Posiblemente una de las mejores opciones como Debugger y que muchos profesionales utilizamos, son las herramientas que nos ofrece Firefox y Google Chrome. Obviamente este par de herramientas están limitadas al uso de pruebas dentro del desarrollo en web. Así es, básicamente es software para desarrollo web, el cual permitirá que puedas depurar tus aplicaciones en tiempo real. Aunque claro, a diferencia de otros depuradores, los cambios solamente serán visuales al momento, puesto que los cambios que hagas no afectarán al código original, lo cuál permitirá que realices las pruebas que consideres necesarias sin limitaciones realmente. Pues no pones en riesgo tu código al modificar valores.

Herramientas para el Diseño de Software

Actualmente, el software que se desarrolla, cuenta con una interfaz gráfica. Recordemos que hace muchos años el software se manejaba bajo el Sistema MSDos, obviamente todo evoluciona y los programas para crear aplicaciones también, refiriéndome principalmente a los Ambientes IDE. Por esta razón, una de las etapas finales del desarrollo de software es el diseño, para lo cuál podemos utilizar algunas herramientas de diseño de software y de diseño tradicionales o bien las mismas plataformas IDE en ocasiones nos pueden proporcionar el diseño que necesitamos. Por eso a continuación veremos algunas opciones de diseño de software, que seguramente querrás usar.

* Plataformas IDE. Hoy en día, los ambientes IDE no solamente están diseñados para escribir código, hacer pruebas, y depuraciones, si no que además, nos permiten disfrutar de la posibilidad de diseñar una interfaz para nuestra aplicación. Obviamente todo es muy simple, ventanas tradicionales, botones sencillos pero funcionales, un esquema visual bastante conocido por todos los programadores, desarrolladores e incluso los licenciados que utilizan este tipo de software. Pues ese es el único detalle de utilizar el aspecto gráfico de un ambiente IDE, que la interfaz no es la mejor, realmente pudieras hacer algo mas sobresaliente si utilizaras herramientas de diseño gráfico profesionales.Algunas de las plataformas IDE que permiten una buena interfaz gráfica, son Eclipse y Visual Estudio, nadamás para que te des una idea por si gustas de utilizar alguna de ellas.

* Herramientas de Diseño Gráfico. Es por demás que te explique lo espectaculares que pueden llegar a ser estas herramientas. En realidad con ellas podrás armar no solamente la interfaz de un bonito programa, incluso puedes armar lo que son sitios web completos, en caso de que el software que estés desarrollando sea algo en Web. La ventaja de estas herramientas profesionales como Photoshop o Corel Draw, es que se adaptan a muchos lenguajes de programación, permitiéndote obtener el código fuente del diseño para implementarlo desde cualquier plataforma que estés utilizando.

Bien, pues ya vimos algunas de las mejores herramientas para lo que es el diseño de software en sus distintas etapas. Sin embargo hay herramientas mucho más especificas que incluso nos permiten automatizar algunos de los pasos que acabamos de enlistar. Básicamente son plataformas que te llevan de la mano en la creación del software, para que no tengas problemas en ningún momento, para evitar el estrés y principalmente para que el producto final tenga una mucho mayor calidad.

Software para Desarrollo Web

Como les comentaba, hace un momento acabamos de pasar por lo que son las aplicaciones para desarrolladores, en básicamente cada una de las fases de los procesos de desarrollo de software. Sin embargo ahora veremos otro tipo de software para desarrollo de aplicaciones. Se trata más que nada, de plataformas, las cuales nos permiten ir paso a paso en lo que son la creación de aplicaciones web. Vamos a ver, algunas de las mejores herramientas para desarrolladores web, que seguramente necesitarás para trabajar más cómodamente y que sin duda harán que tu eficiencia mejore.

* Chrome Developer Tools. Seguramente ya tienes una idea de para que sirve esta fabulosa herramientas de Chrome. Es uno de los programas para hacer depuraciones más eficientes. Si eres de esos desarrolladores web que se la pasan depurando el código y viendo su funcionamiento en tiempo real. Seguramente Chrome Developer Tools será para tí. Pues entre las ventajas que nos proporciona, destaca la posibilidad de hacer ediciones en tiempo real en el DOM (HTML)/CSS y sobretodo te permitirá aprender más sobre la ejecución de las aplicaciones web en tu navegador.Por supuesto que una de las principales ideas de Chrome Developer Tools, es que puedas encontrar cualquier tipo de problema que se genere en el diseño y por supuesto abre la puerta a la optimización del código. Considerando que los cambios los puedes hacer en tiempo real o bien hacer solamente pruebas, sin duda es una herramienta que querrás probar.

* Grunt. Seguramente si eres de los que además de los programas para desarrollo web utilizan Javascript en abundancia, entonces Grunt es para tí. Se trata de una aplicación que nos permitirá automatizar las tareas que deseemos realizar mediante javascripts. De inicio, Grunt nos ofrece la posibilidad de automatizar algunas tareas sencillas y comunes, las cuales recomienda por default, sin embargo si tienes un nivel más avanzado, seguramente querrás automatizarlas por tu cuenta de acuerdo a tus necesidades.Grunt es una de las herramientas de programación web más fáciles de usar y además cuenta con una gran comunidad para todas esas dudas que tengas. Por supuesto encontrarás grandes consejos de personas que utilizan la herramienta al igual que tu y que van descubriendo cosas nuevas de su funcionamiento.

* LiveReload. Como su nombre en Español lo indica, LiveReload es una de las herramientas para el desarrollo web, que da pié a la posibilidad de ahorrar una gran cantidad de tiempo y trabajo. Pues si contamos con LiveReload instalado, ya no tendremos la necesidad de estar recargando la página para visualizar los cambios. LiveReload tiene como función principal, el recargar la página de forma automática, una vez que se haya modificado algo, de esta forma te ahorrarás muchos clics y se te actualizará tu desarrollo web en automático.Del mismo modo que con Grunt, LiveReload cuenta con un perfil de GitHub, donde no solamente podrás echar un vistazo al código fuente, si no que además tendrás la posibilidad de hacer propuestas para el desarrollo y mantenimiento del programa. Por supuesto la comunidad es grande y lo puedes comprobar en su cuenta de Twitter, la cuál si piensas utilizar LiveReload, deberías seguir a como de lugar.

* Mocha. La cuarta de las herramientas de desarrollo web, es un Framework, que tiene como objetivo el que puedas hacer pruebas de Javascript, que aunque suene algo nada extraordinario, la verdad es que te ahorrará mucho tiempo y dolores de cabeza. Trabaja con lo que es Node.js y dentro del mismo navegador, permitiendo la asincronía de una forma tan eficiente, que permite que sus reportes sean mucho mas precisos.Por supuesto que Mocha, además de su perfil en GitHub donde podrás encontrar todo el código fuente, cuenta con una muy buena comunidad en Twitter y Google+, así que si deseas conocer más desarrolladores que utilicen la herramienta, será muy fácil encontrarlos.

* Karma. De los creadores de AngularJS, llega Karma, un test tunner de javascripts, donde no solamente podrás hacer pruebas en tiempo real, si no que además, si trabajaste con Mocha en un determinado momento, con Karma podrás ejecutar sus pruebas fácilmente, por lo que la retroalimentación se realizará en tiempo real.Del mismo modo que las anteriores herramientas de desarrollo web, con Karma podrás ver el código fuente en su perfil de GitHub y su gran comunidad la podrás encontrar en su perfil de Twitter.

Estas son algunas de las herramientas de Software libre para los desarrolladores web. Te permitirán optimizar tiempos, hacer pruebas mas eficiencias, depurar tu código con una eficacia espectacular y sobretodo, permitirá que tus tiempos de desarrollo sean menores en todos los aspectos, personalmente ese es uno de los puntos más a favor, ahora solo cuéntanos cual de estas herramientas es la que más utilizas o la que estás tentado a probar.

Herramientas para el Desarrollo de Páginas Web

La creación de páginas web, viene en aumento a la par con la tecnología y la era en la que nos encontramos. De hecho hay un dicho que dice, que si no estás en internet, entonces no existes. Y una forma muy profesional de aparecer, es mediante un sitio web. Es por eso que a continuación, veremos algunas de las herramientas para el diseño de páginas web, aclarando que por diseño no nos referimos a diseño gráfico, si no al armado de éstas. Así que presta atención, pues seguramente alguna de estas herramientas para diseñadores web, te será de gran ayuda en un futuro.

* Adobe Dreamweaver. Si naciste en los años 80's y te fuiste inclinando hacia lo que es el Diseño de páginas web, entonces seguramente conoces de arriba a abajo esta herramienta de diseño web, me refiero a Dreamweaver. Posiblemente si naciste en los 90's, te suene pero no la hayas manejado tanto, puesto que han salido otras herramientas de diseño con el paso de los años, que pueden llegar a ser mas intuitivas aunque limitadas.

Entonces hablemos de lo que es Dreamweaver. Se trata de una plataforma de trabajo en código, para la creación de sitios web. Permite desarrollar páginas web desde cero, osea con ninguna linea de código, pero también te da la facilidad de utilizar complementos como hojas de estilo CSS, Javascripts, acoplarse incluso con PHP o ASP, en fin, si describo de principio a fin sus virtudes realmente no terminaré jamás.

Lo que si te puedo decir, es que Dreamweaver es una de las herramientas para diseño de páginas web o incluso para la creación de pequeñas secciones en determinados sitios web, por ejemplo. Supongamos que utilizas la plataforma wordpress para la creación de tus páginas, sabemos que es limitado en cierta forma, pero WordPress es tan amigable que nos permitiría mostrar una página hecha en Dreamweaver, en cualquier sección del sitio. Para eso necesitarás algún componente especial como Visual Composer por ejemplo. Así que en Dreamweaver puedes crear una Landing Page muy bien optimizada y diseñada, que te permitirá incluso optimizar tu sitio de forma considerable, almenos es una de las utilidades que personalmente le doy a una herramienta diseño web como Dreamweaver.

* Microsoft Expressions Web. Otro de los programas para desarrolladores en web que sin duda se deben recomendar, es Microsoft Expressions Web. Esta herramienta, al igual que Dreamweaver, nos permite trabajar en doble panel, una con el código hecho a mano y la otra con WYSIWYG. Una de las principales ventajas de Microsoft Expressions Web, es que cuenta con plantillas predeterminadas, lo cuál puede hacerte la vida más facil en el proceso de desarrollo de un sitio web. Aunque aclaro, esto no significa que Microsoft Expressions Web sea una aplicación tan fácil de utilizar, en realidad no es una herramienta que te permita arrastrar y pegar y al igual que en Dreamweaver necesitas algunas bases de conocimiento.

Lo que si podemos destacar de Microsoft Expressions Web, por encima de otras herramientas para el diseño en web, es que tiene un pequeño cierto enfoque hacia el SEO. Nos ofrece algunas opciones para mejorar el rastreo y la optimización interna del sitio, algo que habla bien del producto, aunque claro, debes saber SEO... mmm de verdad, debes... de lo contrario en lugar de beneficiarte te puedes perjudicar.

* Coda 2. Si se trata de ir más allá y de diseñar un sitio web basado en una hoja de estilos, entonces Coda 2 es la solución o bien, la alternativa que estás buscando. Coda es una herramienta exclusiva para Mac, (bendita fortuna) y trabaja mediante un esquema que hará que no te tengas que mover de tu ventana en ningún momento para hacer absolutamente nada, pues su panel lateral es tan maravillosamente increíble que sin duda no tendrás la necesidad de ir a otro lugar.

Posiblemente si comparamos el aspecto visual de Coda 2 con Dreamweaver, se puede quedar corto. Sin embargo cuando lo que te importa en realidad es la codificación y no tanto lo visual, entonces Coda 2 es un líder nato. Su sistema basado en HTML y hojas de estilo CSS, te permitirá obtener los resultados que buscas, pues todo lo visual como sabrás, se puede hacer desde una hoja de estilos, sin necesidad de agregar botones extraños e imágenes que carguen tu sitio web.

* Amaya. Si, lo se... nos hacia falta una herramienta de software libre para diseño y por eso les presentaré a Amaya. Se trata de una herramienta de desarrollo web, que trabaja mediante WYSIWYG. Si bien ya lleva años en el mercado actual, su popularidad no es tanta debido a la competencia de los 3 primeros que te mencioné y de otras plataformas como WordPress que ha dominado al mundo. Sin embargo Amaya es tan buena, que no importa si tienes Linux, Windows o Mac, la podrás ejecutar sin ningún problema, por lo que igualmente tus trabajos y proyectos los podrás abrir desde cualquier computadora.

De hecho, una de las principales ventajas de Amaya, es que se podría considerar como una herramienta diseñada para principiantes, trabaja bajo un esquema muy amigable y utiliza lenguajes como HTML, CSS y XML. Lo que sin duda le facilitará la vida a muchos.

* Bluefish. Posiblemente un poco más avanzado, el dilema de Bluefish es que si necesitas conocimientos en lenguajes de programación, así que si no conoces muy bien de ello, pues es mejor dejarlo pasar. Sin embargo debes saber que Bluefish es una de las herramientas de software libre para diseño, al igual que Amaya, pero con la ventaja de que Bluefish es compatible con una gran cantidad de lenguajes, entre los cuales encontramos: HTML, XHTML, CSS, XML, PHP, C, C ++, JavaScript, Java, Google Go, Vala, Ada, C, SQL, Perl, ColdFusion, JSP, Python, Ruby y varios más, solamente por mencionar algunos de los más conocidos.

La ventaja también de Bluefish, es que no importa desde que computadora trabajes, es compatible con cualquier sistema operativo prácticamente y podrás trabajar mediante una codificación inteligente, que si bien no es lo mismo que otras plataformas mas sencillas, si nos ofrece un gran sistema si sabes sobre lenguajes de programación.

Conclusiones

Como te puedes dar cuenta el Software de programación también es muy utilizado, no creas que se trabaja bajo un bloc de notas y a lo que Dios nos quiere dar a entender. Pudimos ver algunas buenas herramientas para el diseño de software, en su gran mayoría herramientas Open Source, sobretodo cuando se trata de herramientas para web. Sin embargo en lo que respecta a las metodologías de desarrollo de software, las primeras 5 segmentaciones que vimos fueron fabulosas. Así que sin importar si trabajas bajo este esquema o si tienes en mente basarte en alguna de las metodologías de desarrollo de software populares, debes saber que todas y cada una de ellas te llegarán a servir en un determinado momento.

Ahora cuéntanos, ¿Que herramienta es la que más utilizas? y ¿Cuál de todas es la que te gustaría aprender a utilizar?. Compártelo con tus amigos y conocidos, para que sepan un poco más acerca de cada herramienta de desarrollo de software de las que hablamos el día de hoy.

# data[].attributes.attachment_link.title
Herramientas de Desarrollo de Software | Software de Desarrollo

# data[].attributes.attachment_link.description
El desarrollo de software, es una de las ramas de la ingeniería que se en enfoca principalmente a lo que es la creación de sistemas informáticos ... pero ok, todo eso ya lo sabes, no necesito decirte qué es el desarrollo de software en esta instancia.

# data[].attributes.body
La integración continua es una práctica de desarrollo de software mediante la cual los desarrolladores combinan los cambios en el código en un repositorio central de forma periódica, tras lo cual se ejecutan versiones y pruebas automáticas. La integración continua se refiere en su mayoría a la fase de creación o integración del proceso de publicación de software y conlleva un componente de automatización y un componente cultural
https://aws.amazon.com/es/devops/continuous-integration/

# data[].attributes.headline
Modelos de Procesos de Desarrollo de Software

# data[].attributes.subject
Modelos de Procesos de Desarrollo de Software

# data[].attributes.body
define modelo de proceso de software como “Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto, un modelo de procesos del software es una abstracción de un proceso real
http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S2227-18992021000100037

# data[].attributes.attachment_link.readable_text
Artículo original

Modelos de Desarrollo de Software

Software Development Models

Facultad 1. Departamento de Inteligencia Computacional. Universidad de las Ciencias Informáticas. Carretera a San Antonio de los Baños, km 2 ½, Torrens, Boyeros, CP. 19370 La Habana, Cuba.

Centro de Software Libre. Universidad de las Ciencias Informáticas. Carretera a San Antonio de los Baños, km 2 ½, Torrens, Boyeros, CP. 19370 La Habana, Cuba.

El desarrollo de software ha sido históricamente cuestionado debido a problemas asociados a sus resultados finales. Estos inconvenientes dieron origen al concepto de "crisis del software" en 1968, que prácticamente surgió conjuntamente con la creación del software. Una parte importante de la ingeniería de software es el desarrollo de metodologías y modelos para lograr sistemas más eficientes y de mayor calidad, con la documentación necesaria en perfecto orden y en el tiempo requerido. Existen diferentes modelos y metodologías que han sido utilizados en los últimos años como herramientas de apoyo para el desarrollo del software. La interrogante principal está en conocer cuál modelo utilizar en el prdeoceso de desarrollo de software de un proyecto. Para darle solución a este problema se define como objetivo de la investigación proponer alternativas viables a la hora de seleccionar un modelo para el desarrollo de software teniendo en cuenta las características del proyecto.

Palabras clave: modelo; proceso de desarrollo de software; proyecto

Software development has been historically questioned due to problems associated with its final results. These drawbacks gave rise to the concept of "software crisis" in 1968, which practically arose in conjunction with the creation of software. An important part of software engineering is the development of methodologies and models to achieve more efficient and higher quality systems, with the necessary documentation in perfect order and in the time required. There are different models and methodologies that have been used in recent years as support tools for software development. The main question is to know which model to use in the software development process of a project. To give solution to this problem is defined as research objective, propose viable alternatives when selecting a model for software development taking into account the characteristics of the project

Keywords: model; software development process; project

INTRODUCCIÓN

El desarrollo de software ha sido históricamente cuestionado debido a problemas asociados a sus resultados finales, entre los que se encuentran que: los sistemas no responden a las expectativas de los usuarios, los programas fallan con cierta frecuencia, los costos del software son difíciles de prever y normalmente superan las estimaciones, la modificación del software es una tarea difícil y costosa, entre muchas otras como que: el software se suele presentar fuera del plazo establecido y con menos prestaciones de las consideradas inicialmente. Solo una pequeña parte de los proyectos de software desarrollados terminan dentro de plazos y costos, y cumplen los requerimientos acordados (Pressman, 1993).

Estos inconvenientes dieron origen al concepto de "crisis del software" que prácticamente surgió conjuntamente con la creación del software. Es un término informático acuñado en 1968, en la primera conferencia organizada por la OTAN (Organización del Tratado del Atlántico Norte) sobre desarrollo de software, y residía en la complejidad de construir sistemas de software, y también en los cambios constantes a los que debía someterse el software para adaptarse a las necesidades cambiantes de los usuarios y a las innovaciones tecnológicas (Naul-Rander, y otros, 1968).

En esta conferencia se pretendía acordar las bases para una ingeniería de construcción de software. Según Fritz Bauer se necesitaba "establecer y usar principios de ingeniería orientados a obtener software de manera económica, que sea fiable y funcione eficientemente sobre máquinas reales" (Peter, y otros, 1968). Sin embargo, dicho planteamiento además debía incluir otros aspectos, tales como: la mejora de la calidad del software, satisfacción del cliente, mediciones y métricas. A partir de aquí empieza a usarse el término Ingeniería del Software, para expresar el área de conocimiento que se estaba desarrollando en torno a las problemáticas que ofrecía el software (Pons-Giandini, y otros, 2010).

Una parte importante de la ingeniería de software es el desarrollo de metodologías y modelos. En la actualidad ha habido muchos esfuerzos que se han encaminado al estudio de los métodos y técnicas para lograr una mejor aplicación de las metodologías y lograr sistemas más eficientes y de mayor calidad con la documentación necesaria en perfecto orden y en el tiempo requerido (Rumbaugh-Jacobson, y otros, 2000). La experiencia ha demostrado que los proyectos exitosos son aquellos que son administrados siguiendo una serie de procesos que permiten organizar y luego controlar el proyecto, considerando válido destacar que aquellos procesos que no sigan estos lineamientos corren un alto riesgo de fracasar (Pons-Giandini, y otros, 2010).

Existen diferentes modelos y metodologías que han sido utilizados en los últimos años como herramientas de apoyo para el desarrollo del software. Teniendo en cuanta los elementos anteriores surge como interrogante ¿cuál modelo utilizar en el proceso de desarrollo de software de un proyecto? Seguidamente se hace referencia a varios autores que analizan el tema, todos con el objetivo de proponer alternativas viables a la hora de seleccionar un modelo para el desarrollo de software teniendo en cuenta las características del proyecto.

MÉTODOS O METODOLOGÍA COMPUTACIONAL

Sommerville define modelo de proceso de software como " Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto, un modelo de procesos del software es una abstracción de un proceso real (Sommerville, 2005).

Los modelos genéricos no son descripciones definitivas de procesos de software; son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software (Pons-Giandini, y otros, 2010). Algunos de los modelos más conocidos son:

Prototipo

Ventajas

Desventajas

Períodos de desarrollo largos.

Desarrollo en espiral

Ventajas

Desventajas

Modelo RAD

Ventajas

Desventajas

Modelo en cascada

Ventajas

Desventajas

RESULTADOS Y DISCUSIÓN

CONCLUSIONES

El estudio de los modelos para el proceso de desarrollo del software contribuyó a determinar que los modelos son actividades que están relacionadas con la especificación del software (el análisis y diseño), el desarrollo (codificación), la elaboración de pruebas que evidencien la calidad del software y la implementación del producto en su entorno real.

La comparación entre los modelos de desarrollo de software permitió definir un nivel de efectividad teniendo en cuenta algunos criterios de selección. Esta comparación será muy útil cuando se desee seleccionar un modelo, considerando además las características del software y del equipo de proyecto.

REFERENCIAS

Pressman, Roger. Ingeniería de Software. Un enfoque práctico. sd: Editorial Mc Graw Hill. 1993. [ Links ]

Peter, Naur; Randell, Brian (ed.). Software Engineering: Report on a conference sponsored by the Nato Science Committee, Garmisch, Germany, 7th to 11th October 1968. [ Links ]

Pons, Claudia; Giandini, Roxana; Pérez, Gabriela. Desarrollo de Software Dirigido por Modelos. Teorías, Metodologías y Herramientas. McGraw-Hill Education, 2010, p. 978-950. [ Links ]

Rumbaugh, James; Jacobson, Ivar; Booch, Grady. El proceso unificado de desarrollo de software. Addison-Wesley. Madrid, España, 2000. [ Links ]

Sommerville, Ian. Ingeniería del software. Pearson Educación, 2005. [ Links ]

Salazar, O., Aguirre, F., Osorio, J., Herramientas para el desarrollo rápido de aplicaciones web. Scientia et technica, 2011, p. 254-258 [ Links ]

Boehm, Barry W., A spiral model of software development and enhancement. Computer, 1988, vol. 21, no 5, p. 61-72. [ Links ]

Royce, Winston W. Managing the development of large software systems: concepts and techniques. Proceedings of the 9th international conference on Software Engineering. IEEE Computer Society Press, 1987. p. 328-338. [ Links ]

Laboratorio Ing. Soft., Ingeniería de software 2, Departamento de Informática, 2002 [ Links ]

Saurith, A., Estay-Niculcar, C., Análisis y Diseño Integral de Sistemas y Requerimientos. Fundación Universitaria Iberoamericana. Barcelona, España, 2010. 167 pp. [ Links ]

# data[].attributes.attachment_link.description
Artículo original Modelos de Desarrollo de Software Software Development Models Facultad 1. Departamento de Inteligencia Computacional. Universidad de las Ciencias Informáticas. Carretera a San Antonio de los Baños, km 2 ½, Torrens, Boyeros, CP. 19370 La Habana, Cuba. Centro de Software Libre. Universidad de las Ciencias Informáticas.

# data[].attributes.body
DevOps es un marco de trabajo y una filosofía en constante evolución que promueve un mejor desarrollo de aplicaciones en menos tiempo y la rápida publicación de nuevas o revisadas funciones de software o productos para los clientes.
https://www.netapp.com/es/devops-solutions/what-is-devops/

# data[].attributes.body
requerimientos de software son simplemente una descripción de lo que un programa de software en particular debe hacer. Actúan como pautas para que los desarrolladores creen un producto funcional que satisfaga las necesidades de los usuarios
https://www.northware.mx/blog/requerimientos-en-el-desarrollo-de-software-y-aplicaciones/

# data[].attributes.body
Design thinking es una metodología de diseño de resolución de problemas que te permite desarrollar soluciones centradas en las personas.
https://asana.com/es/resources/design-thinking-process

# data[].attributes.body
La prueba de software es el proceso de evaluar y verificar que un producto o aplicación de software hace lo que se supone que debe hacer. Los beneficios de las pruebas incluyen la prevención de errores, la reducción de los costos de desarrollo y la mejora del rendimiento.
https://www.ibm.com/mx-es/topics/software-testing

# data[].attributes.attachment_link.readable_text
¿Qué es una prueba de software?

La prueba de software es el proceso de evaluar y verificar que un producto o aplicación de software hace lo que se supone que debe hacer. Los beneficios de las pruebas incluyen la prevención de errores, la reducción de los costos de desarrollo y la mejora del rendimiento.

Plan de gestión de pruebas

Hay muchos tipos diferentes de pruebas de software, cada una con objetivos y estrategias específicos:

Pruebas de usabilidad: valida qué tan bien un cliente puede usar un sistema o una aplicación web para completar una tarea.

En cada caso, la validación de los requisitos básicos es una evaluación crítica. Igual de importante, las pruebas exploratorias ayudan a un tester o equipo de pruebas a descubrir escenarios y situaciones difíciles de predecir que pueden conducir a errores de software.

Incluso una aplicación simple puede estar sujeta a una gran cantidad y variedad de pruebas. Un plan de gestión de pruebas ayuda a priorizar qué tipos de pruebas proporcionan el mayor valor, dado el tiempo y los recursos disponibles. La efectividad de las pruebas se optimiza ejecutando la menor cantidad de pruebas para encontrar la mayor cantidad de defectos.

Las pruebas de software llegaron junto con el desarrollo de software, que tuvo sus inicios justo después de la segunda guerra mundial. Al informático Tom Kilburn se le atribuye la escritura de la primera pieza de software, que debutó el 21 de junio de 1948 en la Universidad de Manchester en Inglaterra. Realizó cálculos matemáticos utilizando instrucciones de código de máquina.

La depuración era el principal método de prueba en ese momento y lo siguió siendo durante las siguientes dos décadas. En la década de 1980, los equipos de desarrollo miraban más allá de aislar y corregir errores de software para probar aplicaciones en entornos del mundo real. Estableció el escenario para una visión más amplia de las pruebas, que abarcaba un proceso de control de calidad que formaba parte del ciclo de vida del desarrollo de software.

"En la década de 1990, hubo una transición de las pruebas a un proceso más completo llamado garantía de calidad, que cubre todo el ciclo de desarrollo de software y afecta los procesos de planificación, diseño, creación y ejecución de casos de prueba, soporte para casos de prueba existentes y entornos de pruebas", dice Alexander Yaroshko en su publicación en el sitio para desarrolladores de uTest.

"Las pruebas habían alcanzado un nivel cualitativamente nuevo, lo que condujo a un mayor desarrollo de metodologías, la aparición de herramientas poderosas para gestionar el proceso de pruebas y herramientas de automatización de pruebas".
Pruebas continuas
Tradicionalmente, las pruebas de software se han separado del resto del desarrollo. A menudo se lleva a cabo más adelante en el ciclo de vida del desarrollo de software después de la etapa de creación o ejecución del producto. Es posible que un tester solo tenga una pequeña ventana para probar el código, a veces justo antes de que la aplicación salga al mercado. Si se encuentran defectos, puede haber poco tiempo para volver a codificar o volver a probar. No es raro lanzar el software a tiempo, pero con errores y correcciones necesarias. O un equipo de pruebas puede corregir errores pero perder una fecha de lanzamiento.

Hacer actividades de prueba al principio del ciclo ayuda a mantener el esfuerzo de prueba al principio en lugar de después del desarrollo. Las pruebas de software anticipadas también significan que los defectos son menos costosos de resolver.

Muchos equipos de desarrollo ahora usan una metodología conocida como prueba continua. Es parte de un enfoque de DevOps, donde el desarrollo y las operaciones colaboran durante todo el ciclo de vida del producto. El objetivo es acelerar la entrega de software mientras se equilibran los costos, la calidad y el riesgo. Con esta técnica de prueba, los equipos no necesitan esperar a que se cree el software antes de que comience la prueba. Pueden ejecutar pruebas mucho antes en el ciclo para descubrir defectos antes, cuando resultan más fáciles de corregir.

Desarrollo de software

Pocos pueden argumentar en contra de la necesidad de un control de calidad al desarrollar software. Los retrasos en las entregas o los defectos del software pueden dañar la reputación de una marca, lo que provoca la frustración y la pérdida de clientes. En casos extremos, un error o defecto puede degradar los sistemas interconectados o causar fallas graves.

Considere la posibilidad de que Nissan tenga que retirar más de Los números hablan por si mismos. Las fallas de software en los EE. UU. costaron a la economía 1 millón de automóviles debido a un defecto de software en los detectores del sensor de la bolsa de aire. O un error de software que provocó el fracaso del lanzamiento de un satélite militar de 1,200 millones de USD. USD 1.1 billones en activos en 2016. Además, impactaron a 4.400 millones de clientes.

Aunque las prueba cuestan dinero, las empresas pueden ahorrar millones por año en desarrollo y soporte si cuentan con una buena técnica de prueba y procesos de control de calidad. Las primeras pruebas de software descubren problemas antes de que un producto salga al mercado. Cuanto antes reciban los equipos de desarrollo los comentarios de las pruebas, antes podrán abordar problemas como:

Defectos arquitectónicos

Malas decisiones de diseño

Funcionalidad no válida o incorrecta

Vulnerabilidades de seguridad

Problemas de escalabilidad

Cuando el desarrollo deja un amplio espacio para las pruebas, mejora la confiabilidad del software y las aplicaciones de alta calidad se entregan con pocos errores. Un sistema que cumple o incluso supera las expectativas del cliente genera potencialmente más ventas y una mayor cuota de mercado.

Las pruebas de software siguen un proceso común. Las tareas o pasos incluyen la definición del entorno de prueba, el desarrollo de casos de prueba, la escritura de guiones, el análisis de los resultados de la prueba y el envío de informes de defectos.

Las pruebas pueden llevar mucho tiempo. Las pruebas manuales o bajo demanda pueden ser suficientes para compilaciones pequeñas. Sin embargo, para sistemas más grandes, las herramientas se utilizan con frecuencia para automatizar tareas. Las pruebas automatizadas ayudan a los equipos a implementar diferentes escenarios, probar diferenciadores (como mover componentes a un entorno de nube) y obtener comentarios rápidamente sobre lo que funciona y lo que no.

Un buen enfoque de prueba abarca la interfaz de programación de aplicaciones (API), la interfaz de usuario y los niveles del sistema. Además, cuantas más pruebas se automaticen y se ejecuten antes, mejor. Algunos equipos desarrollan herramientas de automatización de pruebas internas. Sin embargo, las soluciones de los proveedores ofrecen funciones que pueden optimizar las tareas clave de gestión de pruebas, como:

Prueba continua: los equipos de proyecto prueban cada compilación a medida que está disponible. Este tipo de prueba de software se basa en la automatización de pruebas que se integra con el proceso de implementación. Permite que el software se valide en entornos de prueba realistas en una etapa más temprana del proceso, lo que mejora el diseño y reduce los riesgos.

Gestión de la configuración: las organizaciones mantienen de forma centralizada los activos de prueba y realizan un seguimiento de las compilaciones de software para probar. Los equipos obtienen acceso a activos como código, requisitos, documentos de diseño, modelos, scripts de prueba y resultados de prueba. Los buenos sistemas incluyen autenticación de usuarios y seguimientos de auditoría para ayudar a los equipos a cumplir con los requisitos de conformidad con un mínimo esfuerzo administrativo.

Virtualización de servicios: es posible que los entornos de prueba no estén disponibles, especialmente en las primeras etapas del desarrollo del código. La virtualización de servicios simula los servicios y sistemas que faltan o que aún no se han completado, lo que permite a los equipos reducir las dependencias y realizar pruebas antes. Pueden reutilizar, implementar y cambiar una configuración para probar diferentes escenarios sin tener que modificar el entorno original.

Seguimiento de defectos o errores: la supervisión de defectos es importante tanto para los equipos de prueba como para los de desarrollo para medir y mejorar la calidad. Las herramientas automatizadas permiten a los equipos realizar un seguimiento de los defectos, medir su alcance e impacto y descubrir problemas relacionados.

Métricas e informes: los informes y la analítica permiten a los miembros del equipo compartir el estado, los objetivos y los resultados de las pruebas. Las herramientas avanzadas integran las métricas del proyecto y presentan los resultados en un panel. Los equipos ven rápidamente el estado general de un proyecto y pueden supervisar las relaciones entre las pruebas, el desarrollo y otros elementos del proyecto.

Descubra las formas en que Skytap utiliza IBM Cloud para desarrollar y probar aplicaciones web.

Descubra cómo este cliente acelera los informes en un 95 % con la ayuda del software IBM Rational y SAP.

Pruebas continuas

En esta guía esencial, descubra cómo las pruebas continuas integradas aceleran el desarrollo de aplicaciones.

¿Qué es el desarrollo de software?

Conozca los conceptos básicos del desarrollo de software y cómo ayuda a las empresas a innovar y competir.

Pruebas continuas para principiantes

Explore por qué adoptar las funciones adecuadas y las mejores prácticas para lograr pruebas continuas puede respaldar su transformación de DevOps.

IBM Developer Blog

Siga los últimos acontecimientos con IBM Developer y manténgase informado.

IBM Servers & Storage Blog

Siga los últimos acontecimientos con IBM DevOps y manténgase informado.

Este video explica qué es la prueba continua, cómo se hace hoy y ofrece ideas acerca de cómo hacer pruebas en el futuro.

# data[].attributes.attachment_link.title
¿Qué es la prueba de software y cómo funciona? | IBM

# data[].attributes.attachment_link.description
La prueba de software es el proceso de evaluar y verificar que un producto o aplicación de software hace lo que se supone que debe hacer. Los beneficios de una buena prueba incluyen la prevención de errores y la mejora del rendimiento.

# data[].attributes.body
Extreme Programming es una metodología de desarrollo que pertenece a las conocidas como metodologías ágiles, cuyo objetivo es el desarrollo y gestión de proyectos con eficacia, flexibilidad y control.
https://www.iebschool.com/blog/que-es-el-xp-programming-agile-scrum/

# data[].attributes.body
El enfoque ágil para el desarrollo de software busca distribuir de forma permanente sistemas de software en funcionamiento diseñados con iteraciones rápidas.  Se trata más bien de una forma de pensar en la colaboración y los flujos de trabajo, y define un conjunto de valores que guían nuestras decisiones con respecto a lo que hacemos y a la manera en que lo hacemos.
https://www.redhat.com/es/devops/what-is-agile-methodology

En concreto, las metodologías ágiles de desarrollo de software buscan proporcionar en poco tiempo pequeñas piezas de software en funcionamiento para aumentar la satisfacción del cliente.

# data[].attributes.attachment_link.readable_text
El enfoque ágil para el desarrollo de software busca distribuir de forma permanente sistemas de software en funcionamiento diseñados con iteraciones rápidas.

Sin embargo, la frase "metodología ágil" es engañosa porque implica que el enfoque ágil es la única forma de abordar el desarrollo de software. La metodología ágil no hace referencia a una serie de indicaciones sobre qué hacer exactamente durante el desarrollo de software. Se trata más bien de una forma de pensar en la colaboración y los flujos de trabajo, y define un conjunto de valores que guían nuestras decisiones con respecto a lo que hacemos y a la manera en que lo hacemos.

En concreto, las metodologías ágiles de desarrollo de software buscan proporcionar en poco tiempo piezas pequeñas de sistemas de software en funcionamiento para mejorar la satisfacción del cliente. Estas metodologías utilizan enfoques flexibles y el trabajo en equipo para ofrecer mejoras constantes. Por lo general, el desarrollo ágil de software implica que pequeños equipos autoorganizados de desarrolladores de software y representantes empresariales se reúnan regularmente en persona durante el ciclo de vida del desarrollo de software. La metodología ágil favorece un enfoque sencillo de la documentación de software, y acepta los cambios que puedan surgir en las diferentes etapas del ciclo de vida, en lugar de resistirse a ellos.

Los valores de la metodología ágil

La metodología ágil como la conocemos en la actualidad nació en el año 2001. En respuesta a los enfoques en cascada de la gestión de proyectos, en que estos se organizan como series de secuencias lineales, un grupo de desarrolladores de software redactó el Manifiesto para el Desarrollo Ágil de Software. En este documento, los programadores propusieron un nuevo enfoque de desarrollo de software y describieron cuatro características fundamentales que se deberían priorizar por encima de otras cuestiones. De acuerdo con lo que establecieron, los equipos de desarrollo ágil de software deberían valorar:

Las personas y las interacciones antes que los procesos y las herramientas

El software en funcionamiento antes que la documentación exhaustiva

La colaboración con el cliente antes que la negociación contractual

La respuesta ante el cambio antes que el apego a un plan

Los autores aclaran que todos los puntos de la lista anterior tienen cierto valor inherente. Sin embargo, proponen que valorar los puntos de la izquierda (en negrita) antes que los de la derecha puede dar lugar a mejores resultados en el desarrollo del producto. El manifiesto no busca imponer un conjunto de prácticas, sino ser una guía que permita pensar en el desarrollo de software de otra manera.

Gracias a este manifiesto, se han obtenido varios resultados prácticos. Por ejemplo, en lugar de desarrollar sistemas de software en una secuencia que va de una fase a la siguiente (que es como el método cascada garantiza la calidad de un producto), el método ágil promueve que los procesos de desarrollo y prueba sean simultáneos y constantes. Dicho de otra forma, en el desarrollo en cascada, una fase debe finalizarse por completo antes de poder pasar a la siguiente; el desarrollo ágil, por otro lado, permite que varias secuencias sucedan al mismo tiempo.

¿Dónde se originó el enfoque ágil?

Los enfoques ágiles de trabajo se crearon para abordar las limitaciones del método en cascada, que se derivaba del sistema de cadena de montaje de 1913 que utilizó Henry Ford como método de fabricación, y que luego se aplicó al desarrollo de software. Desde su origen en 2001, el desarrollo ágil pisa fuerte en el sector de los sistemas de software y la gestión de proyectos, a pesar de sus múltiples variantes.

El enfoque ágil surgió cuando muchos desarrolladores de software notaron que los ciclos de producción y los métodos de colaboración del modelo en cascada no daban los resultados esperados. Para comienzos de la década de los 90, este problema se había generalizado, ya que era común que transcurrieran varios años entre la aparición de una necesidad empresarial justificada y la distribución de una aplicación en funcionamiento. Eran tantos los cambios que podían sufrir las demandas empresariales y los mercados durante esos años, que posiblemente se cancelarían partes importantes de los proyectos de software antes de poder distribuirse. El desperdicio de tiempo y recursos llevó a que varios desarrolladores de software buscaran una alternativa.

Frente a la amenaza de interrupciones, las empresas adoptan cada vez con mayor frecuencia estrategias de transformación digital que permitan seguir sus ritmos acelerados. Sin embargo, cuando esto ocurre, el desarrollo ágil de software suele adquirir un papel protagónico.

El desarrollo ágil constituye las bases de muchos de los flujos de trabajo actuales. El cloud computing, con su infraestructura de TI flexible y escalable, ha crecido en paralelo a las demandas de desarrollo ágil de software. El desarrollo nativo de la nube adopta una noción del software similar a la del enfoque ágil, es decir, funciona como una serie de servicios interconectados que se adaptan para satisfacer las necesidades empresariales.

El concepto de DevOps derriba la antigua barrera que existía entre el desarrollo de software y las operaciones. La SRE es una implementación de DevOps que utiliza el software como una herramienta para gestionar los sistemas y automatizar las tareas operativas.Los métodos de integración y distribución continuas (CI/CD) reconocen que los sistemas de software cambian permanentemente, y proporcionan a los desarrolladores herramientas para acelerar la implementación de un código nuevo.

Posiblemente haya notado que el concepto de "metodología ágil" es una idea ágil en sí misma, porque responde a las necesidades de sus clientes (es decir, los desarrolladores de software) durante los tiempos de cambio. Es importante que tenga esto en cuenta mientras damos un vistazo rápido a las opciones de marcos ágiles, que se conocen con diferentes nombres y que, generalmente, varían de una implementación a otra.

Marcos ágiles

Los marcos ágiles para el desarrollo de software (como Scrum, kanban o programación extrema [XP]) son la base de procesos conocidos de desarrollo de software, como DevOps y la integración continua/implementación continua (CI/CD).

Scrum es probablemente el marco ágil que más se utiliza en la actualidad. Sin embargo, no es la única alternativa dentro del mundo ágil y, para ser sinceros, no todos sus aspectos pueden caracterizarse como ágiles. Este marco de gestión de trabajos se diseñó para equipos pequeños e interdisciplinarios de entre 5 y 9 personas, los cuales dividen su trabajo en acciones que se puedan completar en un período de tiempo uniforme denominado "sprint". Los equipos de Scrum están formados por los miembros, un facilitador y el dueño de un producto. Por lo general, este marco de trabajo se implementa cuando un proyecto grande se puede dividir en sprints de dos a cuatro semanas. Además, se centra en ciclos de retroalimentación mediante reuniones donde se realiza una "retrospectiva" del sprint. Su lema no oficial bien podría ser "analice todo y adáptese".

Hay otros marcos ágiles, como kanban, que son anteriores al manifiesto. Sin embargo, se consideran ágiles porque promueven los valores que se detallan en él. Son muchos los marcos y los enfoques ágiles que permiten adaptar este tipo de metodología, y sería difícil enumerarlos a todos.

# data[].attributes.attachment_link.description
El enfoque ágil para el desarrollo de software busca distribuir de forma permanente sistemas de software en funcionamiento diseñados con iteraciones rápidas. Sin embargo, la frase "metodología ágil" es engañosa porque implica que el enfoque ágil es la única forma de abordar el desarrollo de software.

# data[].attributes.body
Waterfall, también conocida como modelo en cascada, es una metodología que propone ordenar de manera secuencial y lineal la gestión de un proyecto. Se aplica, fundamentalmente, en el ámbito de la ingeniería de software.

¿En qué consiste la metodología Waterfall en gestión de proyectos? (wearedrew.co)

# data[].attributes.attachment_link.readable_text
Waterfall, también conocida como modelo en cascada, es una metodología que propone ordenar de manera secuencial y lineal la gestión de un proyecto. Se aplica, fundamentalmente, en el ámbito de la ingeniería de software.

El concepto de cascada hace referencia a que, una vez cumplida una fase del proyecto, se inicia la otra. Al inicio del proyecto, se recopila la información y los requisitos necesarios, acordados entre desarrolladores y clientes, es decir, de antemano se acuerda el trabajo a realizar.

Al trabajar con Waterfall, el éxito del proyecto se centra en llegar a tiempo a las fechas estimadas y con el presupuesto fijado al inicio.

Historia de Waterfall

El modelo de cascada o Waterfall de gestión de proyectos fue creado por Winston Royce en 1970, postulado en su paper Managing the Development of Large Software Systems. En esas páginas, se proponía un enfoque secuencial para el desarrollo de software, donde las diferentes etapas eran seguidas en serie, una detrás de otra, Estas etapas eran: requerimientos, análisis, diseño, codificación, testing y operación.

En 1985, el modelo Waterfall se establece como estándar para el desarrollo de software en Estados Unidos, y a partir de allí surge su consolidación.

Hoy en día, es utilizado fundamentalmente en sectores IT (desarrollo de tecnologías de la información). Su aplicación consiste en una serie de pasos:

Análisis: planificación, análisis y especificación de los requisitos.

Diseño: diseño y especificación del sistema.

Implementación: programación y pruebas unitarias.

Verificación: integración de sistemas, pruebas de sistema y de integración.

Mantenimiento: entrega, mantenimiento y mejora.

A continuación se desarrollarán cada una de ellas:

Análisis

En esta primera etapa, se evalúa la viabilidad del proyecto, que incluye costos, rentabilidad y qué tan factible de ser realizado es. Además, se definen los requisitos. La viabilidad define como resultado una serie de condiciones, un plan y una estimación financiera. Asimismo, puede incluir una propuesta para el cliente.

Diseño

La etapa de diseño de Waterfall involucra una solución en base a las estrategias y tareas provenientes de la fase de análisis. Se ejecuta el diseño (por ejemplo, de software) con su arquitectura correspondiente.

Implementación

En esta etapa, se incluye fundamentalmente la puesta en práctica, tal como la programación del software, la búsqueda de errores y pruebas que sean necesarias. Las pruebas son unitarias, puesto que se hacen por separado de los distintos componentes pra luego hacer una prueba general del producto final.

Verificación

En esta instancia, se incluye la integración de software en donde debe ir. Se analiza que cumple con las exigencias que se han definido en los pasos anteriores. Si las pruebas funcionan correctamente, ya está listo para su lanzamiento oficial.

Mantenimiento

Incluye la entrega, el mantenimiento y la mejora del software en cuestión. Se vela por su correcta aplicación y su uso eficaz.

Ventajas de Waterfall

Trabajar con esta metodología es útil en tanto es la más apta para entornos industriales, donde el trabajo conlleva un ritmo estable, los requisitos son claros desde el inicio y no están previstos cambios que desarticulen el desarrollo.

Waterfall permite una estructura sencilla debido a las fases claramente definidas del proyecto, como así también una documentación a través de la demarcación de hitos destacados.

Al comienzo del proyecto, se estima la carga y los costos que el mismo demandará, por lo que se cuenta con esta información desde el principio. Asimismo, en Waterfall no es necesario que los clientes o partes interesadas participen de reuniones o revisiones, por lo que no hace falta que se involucren después de la fase de requisitos.

Otra ventaja se refiere a la sencillez para planificar y ejecutar las pruebas, ya que se pueden hacer al final de la fase de desarrollo.

Waterfall es ideal para aplicar en proyectos con alcance, tiempo y presupuestos fijos, como así también en proyectos definidos y simples. Asimismo, sirve para trabajar de forma conjunta con otras organizaciones.

El objetivo de esta metodología es hacer una ejecución rápida y rentable de los proyectos a través de una cuidadosa planificación.

Desventajas de Waterfall

Sin embargo, aplicar este enfoque metodológico tiene sus contras, en tanto es poco probable realizar ajustes a lo largo del proyecto, por lo que admite poca flexibilidad a la hora de querer modificar algo sobre la marcha. Una vez que se ha completado una fase, no se admiten cambios.

En Waterfall, para que el éxito sea garantizado, es necesario reunir todos los requisitos iniciales. Además, es difícil responder a algunas soluciones de problemas que puedan surgir debido a la rigidez del modelo.

Pese a todo, las desventajas son relativas, ya que dependen del proyecto en cuestión y sus necesidades.

Diferencias con otras metodologías

Waterfall, como se expresó anteriormente, se caracteriza por una rigidez frente a otras metodologías admiten mayor colaboración y permiten más cambios, como las metodologías ágiles. En Waterfall, es fundamental cumplir una fase para dar paso a otra, mientras en otras metodologías hay un feedback con el cliente y no necesariamente hay pasos tan estructurados.

Asimismo, en Waterfall las pruebas se hacen al finalizar el proyecto, en la fase anterior al lanzamiento, mientras que en las metodologías ágiles pueden realizarse en la ejecución misma del proyecto. Sin embargo, c on Waterfall es más fácil establecer los costos de un proyecto y los roles están definidos.

Al trabajar con Waterfall se dirigen los esfuerzos a hacer una entrega exitosa de un proyecto, sin embargo, no tiene como premisa fundamental la satisfacción del cliente (como sí ocurre con las metodologías ágiles).

# data[].attributes.attachment_link.title
¿En qué consiste la metodología Waterfall en gestión de proyectos?

# data[].attributes.attachment_link.description
La metodología Waterfall en gestión de proyectos consta de pasos secuenciados, donde una fase da paso a otra.

# data[].attributes.body
En Ingeniería del software, una métrica del software es cualquier medida o conjunto utilizado para conocer o estimar el tamaño de un software o sistema de información. Entre los usos más frecuentes de las métricas del software están el realizar comparaciones costo beneficio y estimaciones de costos en proyectos de software.
http://www.pmoinformatica.com/2018/04/metricas-del-software-ventajas.html?m=1#:~:text=En%20Ingenier%C3%ADa%20del%20software%2C%20una,software%20o%20sistema%20de%20informaci%C3%B3n.

# data[].attributes.attachment_link.readable_text
¿Te gustaría certificarte como experto en medición y estimación de software? Demostrando a tus clientes la elaboración de estimados que puedan cumplirse y logruen las espectativas. Inscribete en el curso de preparación para la certificación en el método COSMIC.

En Ingeniería del software, una métrica del software es cualquier medida o conjunto utilizado para conocer o estimar el tamaño de un software o sistema de información. Entre los usos más frecuentes de las métricas del software están el realizar comparaciones costo beneficio y estimaciones de costos en proyectos de software.

Un ejemplo de métrica del software es el punto de función, su uso permite mayor precisión en las estimaciones de costo, posibilidad de comparar funcionalidades del software a desarrollar y tomar decisiones en base al costo beneficio, más información para priorizar trabajo, posibilidad de hacer avaluos de activos de software, entre otros beneficios.

A continuación te contamos cual es el uso que se le da a las métricas de software y cuáles son las ventajas de implementarlas en la organización.

¿Para qué se utilizan las métricas del software?

De la misma forma que en ingeniería de construcción necesitaríamos definir la altura y ancho de una estructura y sus componentes expresados en metros o centímetros, en desarrollo de software podemos valernos de una unidad de medida que nos permitiera conocer el tamaño del reto al que como desarrolladores de software nos enfrentamos.

Una vez conocido el tamaño en unidad de medida, podríamos utilizarla para determinar con precisión cuál es la estimación de tiempo y presupuesto de un proyecto de software, si nuestras especificaciones derequerimientos son ambiguas o falta información, impacto de un cambio de alcance propuesto, medir unidades planificadas vs. Producidas, graficar la cantidad de unidades de medica producidas en el tiempo (para medir la productividad), entre otros usos.

¿Cuáles son los métodos más utilizados para determinar métricas del software?

Existen diversastécnicas de estimación de esfuerzo y costo en proyectos de softeware. Un ejemplo ampliamente usado para realizar mediciones del tamaño de un software es la métrica del punto de función.

Desarrollada originalmente en los años 70, la técnica del análisis de puntos de función permite asignar un tamaño a los requerimientos de software (sus funcionalidades) expresadas en una métrica que se conoce como el punto de función.

Para medir el software utilizando los puntos de función, primero se toman los requerimientos del software (que pueden estar documentados en la especificación de requerimientos o historias de usuario) y se realiza una descomposición funcional en sus componentes.

Realizada la descomposición funcional, se le asigna a cada componente una cantidad de puntos de función que vienen dados por su complejidad, si son movimientos de entrada o salida, solo consulta o transferencia de datos.

El método de más tiempo de uso es el del International Function Points User Group (IFPUG). En la siguiente serie de artículos, te presentamos un ejemplo de cómo medir software utilizando el método IFPUG.

> Estimación de proyectos de software por puntos de función: Introducción
> Estimación de proyectos de software con puntos de función: Determinar tipo de conteo y componentes funcionales

> Estimación de proyectos de software: Cálculo de los puntos de función no ajustados

El IFPUG ofrece un esquema de certificación, que le brinda la oportunidad a profesionales de demostrar sus conocimientos en el método y certificarse para presentarlo ante posibles empleadores y prospectos de cliente.

Desde su introducción inicial, se han desarrollado otros métodos de análisis de puntos de función, como por ejemplo NESMA, MkII, COSMIC y FiSMA.

Por ejemplo, el método COSMIC fue desarrolado para modernizar la técnica de puntos de función y alinearse con el proceso de ingeniería del software. A diferencia del método IFPUG en el cual se asignan los puntos de función según la clasificación y complejidad de las funcionalidades, bajo COSMIC el número de función se asigna en función del número de entradas y salidas que tengan los componentes del software.

Para ver un ejemplo de COSMIC, te recomendamos el siguiente artículo:

> Ejemplos de estimación de costos de un proyecto de software

Formación en medición de software

¿Te gustaría certificarte como experto en medición de software con el método COSMIC?

Curso online de preparación para la certificación COSMIC, medición de software en base a su tamaño funcional, aplicable a todos los tipos de software y metodologías de desarrollo de software empleada.

¿Cuáles son las ventajas de implementar métricas del software en la organización?

1.- Mayor facilidad de entendimiento común del alcance de la aplicación

Utilizando métricas de software, puedes presentar al usuario cual es el alcance de la aplicación, ilustrando las funcionalidades a entregar por área funcional y comparar su tamaño utilizando métricas de software.

Con esto se facilita un entendimiento común de cuál es el esfuerzo a realizar, pudiendo comparar cuales funcionalidades son de mayor esfuerzo que otra para establecer el costo beneficio.

2.- Posibilidad de comparar con una métrica el tamaño funcional de un nuevo sistema con uno existente

Si el proyecto de software a desarrollar va a reemplazar un software ya existente en la organización, puedes determinar las métricas de software para el sistema existente y el nuevo sistema y compararlo.

De esta forma podrías determinar si el nuevo sistema incluye más funcionalidad que el actual o si por el contrario se brinda menor funcionalidad. Puedes asignar un valor numérico a esta comparación y tomar decisiones sobre esta información.

3.- Evaluar con precisión el costo del nuevo software y sus componentes

Multiplicando el tamaño funcional de un sistema medido en puntos de función, por el costo de producir cada punto de función, quienes toman las decisiones en la organización pueden realizar cálculos rápidos sobre cuál es el costo de reemplazar un sistema existente.

Inclusive, puedes realizar comparaciones del costo de desarrollar el sistema in-house (según sus puntos de función) con el costo de adquirir un sistema externo, el cual podrías obtener de proveedores que te presenten propuestas de venta de licencias y consultoría de implementación.

Sígue el siguiente enlace y te compartimos un ejemplo para elaborar el presupuesto de un software usando los puntos de función como métrica:

> Ejemplo de presupuesto de un proyecto de software

4.- Facilita las negociaciones de alcance entre desarrollador y cliente (área funcional)

En los proyectos de software, los costos reales suelen exceder los planificados, por lo que un curso de acción que la organización pudiera considerar, es negociar con el área funcional o cliente para limitar el alcance del lanzamiento inicial y así mantenerse en tiempo y presupuesto.

El contar con una descomposición funcional en la que cada componente está medido, por medio de métricas de software, presenta una base ideal para esta negociación, al tener visibilidad de los ahorros que se pueden lograr al desincorporar funcionalidad.

5.- Mejor información para mantener el alcance bajo control

Las métricas de software le proporcionan a la gerencia de proyectos los medios para hacer seguimiento al tamaño del proyecto y tomar decisiones al respecto.

En la medida que transcurre el tiempo y se agregan más funcionalidades al proyecto, se pueden usar los puntos de función para graficar si el tamaño está aumentando o disminuyendo. Al superar un umbral definido, se pueden tomar decisiones para controlar el alcance y evitar la extensión indefinida del tiempo y costos del proyecto.

6.- Más información para priorizar solicitudes de cambio o retrabajo

El Gerente de proyectos que usa métricas de software, puede contar con información precisa y cuantificable del impacto de lassolicitudes de cambio de alcance. De esta forma puede tomar decisiones sobre si ejecutarlas o no, así como priorizarlas.

7.- Planificación y presupuesto del soporte técnico de aplicaciones

El personal que se necesita para implantar una infraestructura de un software está íntimamente relacionada con el tamaño de este.

Con las métricas de software y el análisis de puntos de función permite a la gerencia estimar el presupuesto para el soporte técnico.

Por ejemplo, si conocemos el tamaño actual del software y establecemos una métrica de software para un nuevo módulo podríamos anticipar cuanto personal adicional de soporte técnico tendríamos que incorporar.

8.- Benchmarking

Las métricas de software y en particular los puntos de función se pueden utilizar como una medida de la productividad de una organización, determinando cual es el costo, tiempo o cantidad de personal necesaria para producir cierta cantidad de puntos de función.

Conociendo una medida de productividad, se pueden establecer comparaciones con otros equipos de desarrollo de software, unidades funcionales de la organización e inclusive comparar con indicadores de otras empresas y de la industria por medio del Benchmarking.

9.- Posibilidad de hacer avalúos de activos de software

¿Te has preguntado cuánto vale un software desarrollado por tu organización? ¿Cómo asignarías un valor a un activo intangible como el software.

El contar con métricas de software y análisis del tamaño funcional del software por medio de puntos de función podría ser un punto de partida.

Un método que se usa cada vez más para hacer avalúos de software, es estimar el costo que tomaría reemplazarlo en el entorno técnico actual, más que el costo original de su desarrollo.

Dado que el análisis de puntos de función establece la posibilidad de medir el software con precisión, se pueden establecer provisiones y presupuestos, basados en el tamaño funcional del software y la productividad (tasa de puntos de función por costo) que tenga la organización.

10.- Mayor transparencia al establecer contratos de Outsourcing

Conociendo el tamaño funcional del software, se pueden establecer un presupuesto más realista paracontratar servicios de gestión de ciclo de vida de aplicaciones (ALM), así como establecer cláusulas contractuales más precisas, mayor transparencia entre las partes y menos espacio para interpretaciones divergentes.

Asimismo, cuando un tercero está involucrado en la producción de nuevo software y modificaciones a los existentes, se pueden usar las métricas de software para establecer acuerdos de nivel de servicio basados en metas de productividad.

¿Problemas para determinar las jornadas / horas para desarrollar requerimientos de software ?

Técnicas para medir y estimar el tamaño del software a partir de la complejidad de sus funcionalidades.

¿Y qué opinas tú?

¿Qué opinas de las métricas del software? ¿Has implementando métodos de medición y estimación de software en tu organización? ¿Cuál ha sido tu experiencia? Déjanos tus comentarios al final del artículo.

¿Buscas más información de gerencia informática?

¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de gerencia informática?, entonces presiona "suscríbete" a continuación.

También puedes seguirnos vía Twitter, Facebook o Linkedin:

Referencia

Totalmetrics. Uses and Benefits of Function Points

Artículos relacionados

# data[].attributes.attachment_link.description
Un ejemplo de métrica del software ampliamente es el punto de función, el cual trae beneficios para la organización, como por ejemplo estimaciones de software más precisas, posibilidad de comparar funcionalidades del software a desarrollar y tomar decisiones en base al costo beneficio, más información para priorizar trabajo, posibilidad de hacer avaluos de activos de software, entre otros aspectos.

# data[].attributes.body
Kanban es un método Lean, muy popular, de gestión del flujo de trabajo para definir, gestionar y mejorar los servicios que proporciona el trabajo de conocimiento. Te ayuda a visualizar el trabajo, maximizar la eficiencia y mejorar continuamente. El trabajo se representa en tableros Kanban, lo que te permite optimizar la entrega de trabajo a través de múltiples equipos y manejar, incluso los proyectos más complejos en un solo entorno.
¿Qué es Kanban? Principales características y funciones (kanbanize.com)

# data[].attributes.attachment_link.provider_name
Kanban Software for Agile Project Management

# data[].attributes.attachment_link.readable_text
Kanban es un método Lean, muy popular, de gestión del flujo de trabajo para definir, gestionar y mejorar los servicios que proporciona el trabajo de conocimiento. Te ayuda a visualizar el trabajo, maximizar la eficiencia y mejorar continuamente. El trabajo se representa en tableros Kanban, lo que te permite optimizar la entrega de trabajo a través de múltiples equipos y manejar, incluso los proyectos más complejos en un solo entorno.
Ejemplo de elementos básicos del tablero Kanban
Originario de la industria de fabricación, más tarde se convirtió en un método ágil utilizado por los equipos de desarrollo de software. Recientemente, está siendo reconocido por unidades de negocio en varios sectores.

A medida que más y más se oye hablar de Kanban, surgen múltiples preguntas:

¿Qué es exactamente Kanban?

¿Cuáles son los principios y las prácticas de Kanban?

¿Cuáles son las ventajas de adoptar Kanban?

Aquí exponemos lo más importante que debes saber sobre el método y su aplicación práctica.

Definición de Kanban y breve introducción

Definición de Kanban

La palabra japonesa "kanban", que significa "tablero visual" o "señal", se utiliza en el entorno de definición y mejora de procesos desde la década de 1950.

Fue desarrollado y aplicado por primera vez por Toyota como sistema de programación para la fabricación JIT ("Just In Time": "justo a tiempo").

Por otro lado, el término "Kanban" con mayúsculas es conocido y se asocia a la aparición del "Método Kanban", que se definió por primera vez en 2007.

La génesis de Kanban

Inicialmente, surgió como un sistema de programación para la fabricación JIT, antes mencionada, originado por el Sistema de Producción Toyota (TPS). A finales de los 40, Toyota introdujo este sistema en su producción.

Este enfoque representa un Sistema con un comportamiento "pull"; Esto significa que la producción se basa en la demanda de los clientes, en lugar de la práctica habitual de, producir bienes y llevarlos al mercado.

Este sistema de producción único, sentó las bases de la fabricación " Lean " ("Lean Manufacturing"). Su objetivo principal es minimizar las actividades de desperdicio/despilfarro ("waste") sin sacrificar la productividad.
El sistema Kanban original, Fuente: TOYOTA Global Website
El objetivo principal es crear más valor para el cliente sin generar más costes.

El método Kanban

A principios del siglo XXI, los principales actores de la industria del software se dieron cuenta rápidamente de cómo Kanban podía cambiar positivamente la forma de suministrar productos y servicios.

Con una mayor atención a la eficiencia y, aprovechando los avances de la tecnología informática, Kanban salió del ámbito de la industria del automóvil y se aplicó con éxito a otros sectores comerciales complejos como la informática, el desarrollo de software, la I+D y otros.

De hecho, lo que ahora reconocemos como el Método Kanban surgió a principios de 2007, siendo el resultado de años de pruebas, experiencia y esfuerzos conjuntos de las principales figuras de la comunidad Lean y Agile, como David J. Anderson, Dan Vacanti, Darren Davis, Corey Ladas, Dominica DeGrandis, Rick Garber y otros.

Puedes empezar a construir un sistema Kanban configurando el tablero Kanban más sencillo con tres columnas básicas: "Solicitado", "En curso" y "Hecho". Cuando se construye, gestiona y funciona correctamente, sirve como depósito de información en tiempo real, destacando los cuellos de botella dentro del sistema y cualquier otra cosa que pueda interrumpir las prácticas de trabajo sin problemas.
Pero, ¿cómo funciona el método Kanban?

Principios de Kanban

Antes de explorar los valores de Kanban con más detalle, nos gustaría establecer que el método en la forma que adoptamos y utilizamos hoy en día surgió debido a los esfuerzos de colaboración de muchas personas. La comunidad Kanban en expansión debería reconocer estas ideas y contribuciones como tales.

David J. Anderson, pionero en el campo de Lean/Kanban para el trabajo de conocimiento, y uno de los padres fundadores del método, ha formulado el método Kanban como: "Un enfoque de cambio, incremental y evolutivo, de procesos y sistemas, para las organizaciones de trabajo de conocimiento".

Se centra en "hacer las cosas", y sus fundamentos pueden desglosarse en dos tipos de principios y seis prácticas.

Examinemos cuáles son los principios de Kanban.

Principios de la gestión del cambio Principios de prestación de servicios

Comienza con lo que haces ahora

Centrarte en las necesidades y expectativas del cliente

Aceptar el cambio incremental y evolutivo

Gestionar el trabajo, no los trabajadores

Fomentar los actos de liderazgo a todos los niveles

Revisar periódicamente la red de servicios

Principios de la gestión del cambio

Combinando con los procesos ya establecidos, de forma no disruptiva, persiguiendo cambios evolutivos y la mejora continua. Veamos con más detalle los principios de gestión del cambio de Kanban.

Principio 1: Empezar por lo que haces ahora

Kanban ofrece la flexibilidad de utilizar el método sobre los flujos de trabajo, los sistemas y los procesos existentes, sin alterar lo que ya está en marcha. El método reconoce que los procesos, las funciones, las responsabilidades y los roles existentes tienen valor y, por lo general, vale la pena conservarlos. Naturalmente, pondrá de relieve los problemas que deben abordarse y ayudará a evaluar y planificar los cambios para que su aplicación sea lo menos invasiva posible.

Principio 2: Acordar un cambio incremental y evolutivo

El método Kanban está diseñado para encontrar una resistencia mínima. Fomenta la introducción continua de pequeños cambios incrementales y evolutivos en el proceso actual, mediante la aplicación de formas de colaboración y retroalimentación. En general, se desaconsejan los cambios radicales porque suelen encontrar resistencia por miedo o incertidumbre.

Principio 3: Fomentar los actos de liderazgo a todos los niveles

El liderazgo a todos los niveles, se deriva de las observaciones cotidianas de las personas y actúa para mejorar su forma de trabajar. Por insignificante que parezca, cada observación compartida fomenta una mentalidad de mejora continua (Kaizen), para alcanzar un rendimiento óptimo a nivel de equipo/departamento/empresa. Esto no puede ser solo una actividad a nivel de dirección.

Principios de prestación de servicios

Kanban pretende desarrollar un enfoque orientado a los servicios. Requiere que entiendas profundamente las necesidades de tu cliente, que crees una red de servicios en la que las personas se autoorganicen en torno al trabajo y que te asegures de que tu sistema evoluciona continuamente. Veamos con más detalle los principios de prestación de servicios de Kanban.

Principio 1: Centrarse en las necesidades y expectativas del cliente

La entrega de valor al cliente debe ser el centro de toda organización. Comprender las necesidades y expectativas de sus clientes, hace que se preste atención a la calidad de los servicios prestados y al valor que se crea.

Principio 2: Gestionar el trabajo

La gestión del trabajo en tu red de servicios, te permite potenciar la capacidad de las personas para autoorganizarse en torno al trabajo. Esto te permite centrarte en los resultados deseados sin el "ruido" creado por la microgestión de las personas que prestan los servicios.

Principio 3: Revisar periódicamente la red de servicios

Una vez desarrollado, un enfoque orientado al servicio requiere una evaluación continua para fomentar una cultura de servicio al cliente. Mediante el uso de revisiones periódicas de la red de servicios y la evaluación de las políticas de trabajo aplicadas, Kanban fomenta la mejora de los resultados entregados.

Prácticas Kanban

Cuando se pretende implantar el método Kanban, toda la organización debe tener cuidado con los pasos a dar en la práctica del mismo.
Para que la implantación sea un éxito, deben estar presentes seis prácticas básicas. Aunque dominarlas es vital, se trata de un proceso en evolución: cerca del 40% de las organizaciones admiten que la forma en que utilizan las prácticas Kanban todavía está madurando.

Echemos un vistazo más de cerca y entendamos cuáles son las seis prácticas de Kanban.

Visualizar el flujo de trabajo

Limitar el trabajo en curso

Gestionar el flujo

Explicitar las políticas de procesos

Aplicar bucles de retroalimentación

Mejorar en colaboración

1. Visualizar el flujo de trabajo

Un simple tablero Kanban

Para visualizar tu proceso con un sistema Kanban, necesitarás un tablero con tarjetas y columnas. Cada columna del tablero representa un paso en el flujo de trabajo. Cada tarjeta Kanban representa un elemento de trabajo. El tablero Kanban en sí, representa el estado real del flujo de trabajo, con todos sus riesgos y especificaciones.

Lo primero y más importante, es comprender lo que se necesita para que un elemento pase de ser una solicitud, a un producto entregable. Reconocer cómo fluye el trabajo a través del Sistema, te pondrá en el camino de la mejora continua al realizar cambios bien observados y necesarios.
Tablero Kanban digital con límites de WIP
Cuando empiezas a trabajar en un elemento X, lo sacas de la columna "Por hacer" y, cuando lo terminas, lo pasas a "Hecho". De este modo, puedes seguir fácilmente el progreso y detectar los cuellos de botella. Naturalmente, tu tablero Kanban puede tener una perspectiva diferente, ya que depende de necesidades y procesos específicos.

2. Limitar el trabajo en curso (WIP)

Una de las principales funciones de Kanban, es garantizar un número manejable de elementos activos en progreso en cualquier momento. Si no hay límites de trabajo en curso, no estás haciendo Kanban.

Cambiar el enfoque de un equipo a mitad de camino, generalmente dañará el proceso, siendo la multitarea una ruta segura para generar desperdicio e ineficiencia.

Limitar el WIP significa implantar un sistema "pull" sobre las piezas o el flujo de trabajo completo. Establecer un número máximo de artículos por etapa garantiza que una tarjeta sólo se "extraiga" a la siguiente etapa cuando haya capacidad disponible.

Este tipo de restricciones pondrán de manifiesto rápidamente las áreas problemáticas del flujo para que puedas identificarlas y resolverlas.

3. Gestionar el flujo

La gestión del flujo consiste en gestionar el trabajo, y no a las personas. Por flujo, entendemos el movimiento de los elementos de trabajo a través del proceso de producción, a un ritmo, predecible y sostenible.

Uno de los principales objetivos al implantar un sistema Kanban, es crear un flujo fluido y saludable. En lugar de microgestionar a las personas y tratar de mantenerlas ocupadas todo el tiempo, debes centrarte en la gestión de los procesos de trabajo y en entender cómo hacer, que ese trabajo pase más rápido por el sistema. Esto significará que tu sistema Kanban está creando valor más rápidamente.

4. Hacer explícitas las políticas de los procesos

No se puede mejorar algo que no se entiende. Por eso tu proceso debe estar claramente definido, publicado y socializado. La gente no se asociaría ni participaría en algo que no cree que sea útil.

Cuando todo el mundo está familiarizado con el objetivo común, puedes trabajar y tomar decisiones con un impacto positivo. Suficientes, visibles, bien definidas y sujetas a cambios cuando sea necesario, las políticas de trabajo tienen, el poder de impulsar la autoorganización de las personas.

5. Bucles de retroalimentación ("feedback")
Reuniones a nivel de equipo Reuniones orientadas al servicio
Para los equipos y las empresas que quieren ser más ágiles, la implantación de bucles de retroalimentación es un paso obligatorio. Garantizan que las organizaciones respondan adecuadamente a los posibles cambios, y permiten la transferencia de conocimientos entre las partes interesadas.

Kanban sugiere el uso de reuniones (bucles de retroalimentación) a nivel de equipo, así como de reuniones orientadas al servicio.

Un ejemplo de reunión a nivel de equipo, es la Reunión Kanban diaria del equipo para el seguimiento del estado y el flujo de trabajo. Ayuda a identificar la capacidad disponible y el potencial para aumentar el ritmo de entrega. Tiene lugar frente al tablero Kanban, y cada miembro cuenta a los demás lo que hizo el día anterior y lo que hará hoy.

Las reuniones orientadas al servicio en Kanban, como las reuniones de operaciones, de prestación de servicios y de riesgos, tienen como objetivo, sincronizar y mejorar la prestación de servicios. El resultado de estas revisiones, como la comprensión de lo que está bloqueando la prestación efectiva del servicio, debe servir como una entrada para la toma de decisiones para la mejora continua de la red de servicios.

Aunque las reuniones centradas y regulares con menos asistentes han demostrado ser una buena práctica, la duración ideal de las reuniones específicas de Kanban depende de su contexto, del tamaño del equipo y de los temas a tratar.

6. Mejorar en colaboración (utilizando modelos y el método científico)

La forma de conseguir una mejora continua y un cambio sostenible dentro de una organización, es mediante la aplicación colaborativa de cambios basados en métodos, información y métricas científicamente probadas.

Cultivar una cultura organizativa, en la que cada hipótesis tenga resultados positivos o negativos, es crucial para desarrollar una mentalidad centrada en la mejora a través del cambio evolutivo.

Las 6 principales ventajas de Kanban

Según el primer informe sobre el estado de Kanban, las principales razones para adoptar el método Kanban son, la necesidad de mejorar la visibilidad del trabajo y la mejora continua. Vamos a revelar algunas otras ventajas de utilizar Kanban.

Crédito de la imagen: State of Kanban

Mayor visibilidad del flujo

Mejora de la velocidad de entrega

Alineación entre objetivos y ejecución

Mejora de la previsibilidad

Mejora de la gestión de las dependencias

Mayor satisfacción del cliente

Mayor visibilidad del flujo

La idea básica de Kanban es visualizar cada elemento de trabajo. De este modo, el tablero Kanban se convierte en un eje central de información, y todo el mundo está en la misma visualización. Todas las tareas son visibles y nunca se pierden, lo que aporta transparencia a todo el proceso de trabajo. Cada miembro del equipo puede tener una rápida actualización del estado de cada proyecto o tarea.

Mejora de la velocidad de entrega

Kanban ofrece múltiples formas para que los gestores de proyectos puedan supervisar de cerca y realizar análisis informados de la distribución del trabajo. Con una visión clara sobre los elementos de trabajo completados durante un determinado periodo de tiempo, las etapas en las que las tareas pasan más tiempo y los cuellos de botella, son fáciles de identificar. Los equipos están capacitados para hacer frente a estos desafíos, para mejorar su flujo de trabajo y, en última instancia, su tasa de entrega.

Alineación entre los objetivos empresariales y la ejecución

Promoviendo la transparencia, fomentando la retroalimentación y las reuniones periódicas de revisión, las prácticas de Kanban permiten alinear los objetivos estratégicos de la empresa con el trabajo diario de los equipos. Esta alineación entre la dirección del negocio y la ejecución mejora la agilidad de una organización.

Permite que los equipos se adapten a las prioridades cambiantes y a las reorganizaciones, debidas a los cambios en el mercado o en las exigencias de los clientes.

Mejora de la previsibilidad

Una vez que crees un tablero Kanban y empieces a acumular elementos de trabajo en él, podrás entender tu proceso en profundidad, con las métricas de flujo. Analizar el tiempo que las tareas pasan en su flujo de trabajo (tiempo de ciclo / "cycle time") te permitirá mejorar sus predicciones sobre la cantidad de trabajo que puede entregar en el futuro. Comprender la consistencia de su tasa de entrega (rendimiento / "throughput") hará que sus previsiones sean más precisas y que sus decisiones se basen en datos históricos.

Mejora de la capacidad de gestión de la escala y las dependencias

La práctica intrínseca de Kanban a la visualización, también se aplica cuando se trata de mapear y gestionar las dependencias. Empezar con lo que se hace ahora significa, visualizar las dependencias actuales y gestionar el flujo entre ellas. La gestión de las dependencias proporciona, tanto información sobre el estado actual de un flujo de trabajo, como ideas de mejora.

Por otro lado, también permite una total transparencia para la gestión estratégica sobre el flujo de trabajo y los vínculos existentes entre los equipos.

Mayor satisfacción del cliente

El origen del método Kanban (el sistema "pull" en el que se basa), implica que el trabajo se realiza cuando hay una demanda. En otras palabras, Kanban te permite reducir el desperdicio de tiempo, trabajando únicamente, en las tareas que se necesitan en ese momento. Además, aplicando técnicas de visualización e introduciendo en el proceso límites de trabajo en curso, te asegurarás de que el resultado final se ajuste a las expectativas de tu cliente.

Scrum vs. Kanban

La diferencia más importante entre Kanban y Scrum es que el primero es un método, mientras que el segundo, es un marco de trabajo ("framework").

Kanban construye un modelo de entrega continua, en el que los equipos liberan valor tan pronto como están listos, mientras que Scrum organiza el trabajo en "Sprints".

La aplicación de uno u otro depende de la naturaleza de su proceso, sin embargo, puede decirse que Kanban ofrece un enfoque más "a medida" mientras que Scrum se basa en reglas predeterminadas.

Otra característica clave que distingue a ambos es, la mentalidad y los sistemas de creencias fundamentales de Scrum y Kanban.

Naturaleza

Kanban es un método adaptativo

Scrum es un marco prescriptivo

Principios

1. Empieza con lo que haces ahora
2. Acepta perseguir un cambio evolutivo
3. Fomentar los actos de liderazgo a todos los niveles
4. Centrarse en las necesidades del cliente
5. Gestionar el trabajo
6. Revisar periódicamente la red de servicios

1. Empirismo
2. Transparencia
3. Inspección
4. Adaptación

Reuniones/eventos

- Reuniones a nivel de equipo
- Reuniones orientadas al servicio

- Sprint con una duración fija
- Planificación del sprint
- Scrum diario
- Revisión del Sprint
- Retrospectiva del Sprint

Roles

- Gestor de prestación de servicios*
- Gestor de Solicitudes de Servicio*.
(*no se requieren roles predefinidos)

- Propietario del producto ("Product Owner")
- Scrum Master
- Equipo de desarrollo

Métrica

- Tiempo de ciclo
- Rendimiento
- Trabajo en curso

- Velocidad
- Capacidad planificada

Esquema de Portafolio Kanban
Aplicación de Kanban en toda la organización para la agilidad de la empresa

Por naturaleza, Kanban es un método adaptable que se puede aplicar en todos los niveles de la organización.

Puede utilizar tableros Kanban conectados, para mapear la gestión de sus carteras ("Portafolio") de proyectos y conectar la estrategia con la ejecución. Con la ayuda del concepto de Kanban de Portafolio, las organizaciones pueden cosechar los beneficios de los principios y prácticas de Kanban a través de múltiples niveles de gestión.

El enfoque de Portafolio Kanban se puede utilizar en cuatro formas diferentes:

Kanban de Portafolio a nivel de equipo

Kanban de Portafolio a nivel de proyecto/producto

Kanban de Portafolio a nivel de programa

Kanban de Portafolio a nivel estratégico

¿Cuáles son los principales términos de Kanban que debes conocer?

En esencia, Kanban es un método de trabajo que te ayuda a optimizar el flujo de valor, a través de sus flujos de valor, desde la ideación hasta el cliente.

Aunque parece una forma fácil de mejorar tus procesos de trabajo, Kanban es más que visualizar tu trabajo. Debes prestar atención a los detalles y familiarizarte con los términos y artefactos básicos de Kanban si quieres beneficiarte de la aplicación del método.

He aquí un breve glosario de Kanban que te ayudará a empezar.

Tablero Kanban: Un tablero Kanban es uno de los componentes clave del método Kanban y es, donde se visualizan todos los elementos de trabajo. Debe estar dividido en un mínimo de 3 columnas -Solicitado, En curso y Realizado - que representan las diferentes etapas del proceso.

Tarjeta Kanban: Las tarjetas Kanban representan los diferentes elementos de trabajo que se mueven a través de un tablero Kanban. Contienen detalles importantes sobre las tareas, como la descripción, el plazo, el tamaño, los asignados, etc.

Columnas: Dividen el tablero Kanban verticalmente, y cada una de ellas representa una etapa diferente del flujo de trabajo. Cada tablero Kanban tiene 3 columnas por defecto: Solicitado, En proceso, Hecho. Dependiendo de la complejidad de un proceso de trabajo, estas tres etapas pueden dividirse en muchas subcolumnas más pequeñas.

Carriles (de natación): Carriles horizontales que dividen un tablero Kanban en secciones. Los equipos los utilizan para separar visualmente diferentes tipos de trabajo en el mismo tablero y organizar juntas las tareas homogéneas.

Duración del ciclo: La duración del ciclo comienza en el momento en que una nueva tarea entra en la fase "en curso" de su flujo de trabajo, y alguien está realmente trabajando en ella.

Tiempo de espera: El plazo de entrega comienza en el momento en que se solicita una nueva tarea (no importa si alguien está trabajando en ella) y termina con su salida final del sistema.

Rendimiento: El número de elementos de trabajo que pasan por (completan) un sistema o proceso durante un periodo determinado. El rendimiento es un indicador clave que muestra la productividad de su equipo a lo largo del tiempo.

Trabajo en curso (WIP): Es la cantidad de trabajo en la que estás trabajando actualmente y que aún no está terminada.

Límites del trabajo en curso: Limitar el trabajo en curso significa limitar el número de tareas en las que tu equipo puede trabajar simultáneamente para evitar la sobrecarga y el cambio de contexto.

Clases de servicio: Conjunto de políticas que ayudan a los equipos ágiles a priorizar los elementos de trabajo y los proyectos.

Reuniones Kanban: Reuniones cíclicas que impulsan el cambio evolutivo y la prestación de servicios "adecuados".

Software Kanban: Se refiere a un sistema digital que permite la aplicación práctica de las prácticas y principios de Kanban para ser utilizado por varios equipos y organizaciones de todos los tamaños.

Kanban en pocas palabras

Un sistema Kanban, es más que notas adhesivas en la pared. La forma más fácil de entender Kanban es adoptar su filosofía y aplicarla a su trabajo diario. Si lees, entiendes y te identificas con sus principios básicos, la transición práctica te parecerá lógica e incluso inevitable.

La visualización del flujo de trabajo, el establecimiento de límites de trabajo en curso, la gestión del flujo, la garantía de políticas explícitas y la mejora continua, llevarán tu proceso mucho más allá de lo que podría pensar. Recuerda organizar bucles de retroalimentación regulares, y todas estas piezas juntas revelarán el verdadero poder de Kanban.

Prueba Kanbanize Gratis

En resumen

Tratar de aprender qué es Kanban puede ser difícil al principio, pero ahora que sabes lo que es, puedes aprovechar al máximo los principales beneficios de Kanban:

Los tableros Kanban físicos y digitales te ayudan a visualizar el trabajo

Kanban es fácil de adoptar y - sólo hay que empezar con lo que se tiene

Los límites de WIP te permiten ser más eficiente

Los principios y prácticas de Kanban ofrecen un camino evolutivo hacia la agilidad sin alterar los procesos actuales

# data[].attributes.attachment_link.title
¿Qué es Kanban? Principales características y funciones

# data[].attributes.attachment_link.description
Kanban es un método Lean, muy popular, de gestión del flujo de trabajo para definir, gestionar y mejorar los servicios que proporciona el trabajo de conocimiento. Te ayuda a visualizar el trabajo, maximizar la eficiencia y mejorar continuamente.

# data[].attributes.body
Los ingenieros de software debieran obligarse a hacer del análisis, especificación, diseño, desarrollo, pruebas y mantenimiento del software una profesión respetada y beneficiosa. En concordancia con la obligación con el bienestar, salud y seguridad de la sociedad
http://www.sc.ehu.es/jiwdocoj/elcodigo.htm

# data[].attributes.body
Scrum es un marco de gestión de proyectos de metodología ágil que ayuda a los equipos a estructurar y gestionar el trabajo mediante un conjunto de valores, principios y prácticas. Al igual que un equipo de rugby (de donde proviene su nombre) cuando entrena para un gran partido, scrum anima a los equipos a aprender a través de las experiencias, a autoorganizarse mientras aborda un problema y a reflexionar sobre sus victorias y derrotas para mejorar continuamente.
Scrum: qué es, cómo funciona y cómo empezar | Atlassian

# data[].attributes.attachment_link.title
Scrum: qué es, cómo funciona y por qué es excelente

# data[].attributes.attachment_link.description
Scrum constituye un marco de trabajo estructurado para el desarrollo de proyectos. Lo utilizan con frecuencia los equipos de desarrollo de software que siguen una metodología ágil. Lee esta guía para principiantes de scrum.

# data[].attributes.headline
Ciclo de vida del desarrollo de software

# data[].attributes.subject
Ciclo de vida del desarrollo de software

# data[].attributes.body
El ciclo de vida del desarrollo de software (SDLC) es un proceso rentable y eficiente en términos de tiempo empleado por los equipos de desarrollo para diseñar y crear software de alta calidad. El objetivo del SDLC es minimizar los riesgos del proyecto por medio de una planificación anticipada que permita que el software cumpla las expectativas del cliente durante la fase de producción y posteriormente.
https://aws.amazon.com/es/what-is/sdlc/

# data[].attributes.body
La metodología Agile es un sistema de trabajo que está cambiando el desarrollo de proyectos de muchas empresas, entre ellas, Google, Amazon o Microsoft. Este nuevo concepto triunfa en todo el mundo y ha llegado para quedarse. ¿La clave de su éxito? Organizar y repartir el trabajo de una manera rápida y flexible entre diferentes equipos multidisciplinares.
¿Qué es la metodología Agile y por qué está de moda? | Progressa Lean

# data[].attributes.attachment_link.readable_text
Lo oímos a menudo, sabemos que mejora la productividad y que alivia los flujos de trabajo, pero no sabemos qué tenemos que hacer para aplicar la metodología Agile a nuestra empresa.

Agile tiene su origen en febrero de 2001 cuando 17 expertos en desarrollo de software elaboraron, durante un encuentro en Estados Unidos (Utah), un documento a favor de los nuevos métodos ágiles de actuación.

La metodología Agile es un sistema de trabajo que está cambiando el desarrollo de proyectos de muchas empresas, entre ellas, Google, Amazon o Microsoft. Este nuevo concepto triunfa en todo el mundo y ha llegado para quedarse. ¿La clave de su éxito? Organizar y repartir el trabajo de una manera rápida y flexible entre diferentes equipos multidisciplinares.

La metodología Agile mantiene la dirección sin caer en la rigidez de los conocidos métodos en cascada o waterfall. Estos planean el trabajo desde el principio, sin lugar a imprevistos. De forma que cuando aparecen, resulta imposible reaccionar a tiempo. El agilismo, sin embargo, mantiene la capacidad de tomar la mejor opción en cada momento sin comprometer el proyecto. Los métodos Agile más populares del momento son Scrum y Kanban.

Bodybuilding: training programs and schedules alpha pharma shop 110 workout sheets for maximum bodybuilding rapini self-published.

Desde sus inicios, la metodología Agile reivindica 4 valores:

Las interacciones de las personas sobre los procesos y las herramientas.

Un software en funcionamiento frente a documentación exhaustiva.

La participación activa del cliente durante todo el proceso de desarrollo.

La capacidad de respuesta ante los cambios e imprevistos.

¿Cuáles deben ser los primeros pasos para hacer de la metodología Agile una realidad?

Como los profesionales a nuestro cargo y nuestros propios responsables han aprendido de la vieja escuela, es importante que entiendan que no solo hay que cambiar los métodos, sino las herramientas de gestión. Para algunos trabajadores, cuestionar qué herramientas usan es cuestionar su experiencia, y no son particularmente propuestos a los cambios. Principalmente porque no entienden los motivos.

Come la motivazione può andare oltre l'allenamento della forza www.esserefelice.net programma di bodybuilding per principianti: guadagno di massa e allenamento della forza.

El diálogo antes, durante y después de implantar métodos Agile es clave. En primer lugar para dar a conocer sus beneficios, en segundo para saber qué dificultades encuentran los trabajadores en su uso y en tercero para ver cómo mejorar con el tiempo. Es importante que los trabajadores comprendan que su experiencia sigue siendo tan válida como lo era antes.

Los métodos ágiles pasan sí o sí por las reuniones

Merece la pena reservar 15 o 20 minutos de primera hora de la mañana para, estando todo el equipo junto, chequear el estado de las distintas tareas de los proyectos. Inclusive aunque lo único que se diga por parte de algún departamento o empleado sea "No hay novedad".

Este tipo de reuniones son muy productivas, ya que redirigen día a día la capacidad de trabajo a las tareas pendientes y evitan las pérdidas de tiempo. Si durante la reunión matinal el responsable observa que alguna tarea requiere de más personal, podrá asignarlo durante el día a esa tarea específica.

Esto fomenta la cohesión de equipo, la participación y la implicación de los proyectos, ya que el mismo proyecto acaba siendo tarea y logro de todos los implicados.

Los métodos agilistas parten de la base de que la empresa tendrá que responder de forma rápida a los cambios del entorno, cada vez más turbulentos. Para ello se dejan abiertas las tareas más alejadas de la línea temporal, aunque con una clara orientación a un objetivo definido.

Con la colaboración entre equipos se consigue velocidad, fluidez y dinamismo. Las aportaciones de unos y otros enriquecen el resultado final.

Requerimientos del Método Agile

Lo más importante para implementar una metodología Agile es el liderazgo y el cambio de cultura empresarial. Saber dialogar y motivar a los equipos para vencer sus reticencias, convencerlos de los beneficios e involucrarlos en el cambio. El compromiso con el modelo es fundamental para su éxito.
Aplicar Agile conlleva cumplir estos 12 principios:

1. La prioridad es que el cliente esté satisfecho y siempre informado del estado del proceso.

2. Los requisitos del proyecto pueden cambiar y no se verá como un problema, sino como una ventaja competitiva.

3. Las entregas se realizan periódicamente y en periodos cortos. La planificación se realizará desde las dos semanas, a los dos meses.

4. El equipo debe trabajar de forma conjunta y coordinada.

5. Es prioritario motivar al equipo, confiar en los miembros y proporcionarles los recursos o apoyos que necesiten.

6. Las reuniones Scrum son el método más efectivo para comunicarse.

7. El éxito depende de si el producto final funciona y es satisfactorio.

8. Los procesos deben ser sostenibles, tanto en recursos materiales, como en la gestión del tiempo y el ritmo de trabajo.

9. En todo proceso o etapa debe prevalecer la excelencia técnica.

10. Prevalece la ley de la simplicidad: menos es más.

11. La organización de los equipos es esencial para dar con un buen diseño.

12. Los tiempos para la reflexión y buscar mejoras es necesario e igual que importante que el resto de fases.

Scrum y Agile: similitudes y diferencias

A pesar de que Scrum es una manera de ser ágil, no son lo mismo.

Agile es mucho más que una metodología, es un conjunto de valores y de principios a seguir para evitar que surjan típicos problemas del desarrollo de software. Por lo que podemos decir, que Agile es algo así como un movimiento frente a las metodologías de desarrollo de software tradicionales, por lo que representa los principios como tal.

Scrum, a diferencia de Agile, no es una metodología. Scrum es un framework porque está formado por una serie de eventos, artefactos, roles, normas... para un determinado fin, por lo que si no se siguen paso a paso no se estará haciendo Scrum.

# data[].attributes.attachment_link.title
¿Qué es la metodología Agile y por qué está de moda? | Progressa Lean

# data[].attributes.attachment_link.description
Lo oímos a menudo, sabemos que mejora la productividad y que alivia los flujos de trabajo, pero no sabemos qué tenemos que hacer para aplicar la metodología Agile a nuestra empresa. Agile tiene su origen en febrero de 2001 cuando 17 expertos en desarrollo de software elaboraron, durante un encuentro en Estados Unidos (Utah), un documento a favor de los nuevos métodos ágiles de actuación.

# data[].attributes.body
es el grado en que un sistema, componente o proceso, cumple con los requisitos especificados y satisface las necesidades del usuario o cliente.
https://www.qalovers.com/2019/02/que-es-la-calidad-del-software.html?m=1