¿Existe un libro completo, guía o documento del sitio web de las diferentes metodologías de desarrollo de software?

Metodologías de desarrollo de software: información detallada con datos sólidos

Cada negocio tiene diferentes requisitos de desarrollo de software. Sin embargo, numerosos Whitepaper e informes en Internet lo educan en el desarrollo de un excelente software para su negocio. Con lo que se debe y no se debe hacer, las mejores prácticas y las mejores prácticas de proceso, seguro que es una buena lectura. Pero todos no abordan que cada negocio y cada vertical son diferentes y las características respectivas hacen que el desarrollo del software sea completamente diferente.

Sumérjase en los conocimientos profundos presentados en el Informe de desarrollo de software de Damco, preparado después de años de amplia experiencia intercultural y multidimensional en ingeniería de productos y desarrollo de software.

Es posible que se encuentre en cualquier etapa de su desarrollo de software, las ideas nunca pueden pasarse por alto. Si está involucrado en el desarrollo de software, técnica o estratégicamente, es esencial una hoja de ruta con visión de futuro. Este informe de desarrollo de software ayuda a decidir sobre las consideraciones básicas de desarrollo de software que le permiten tomar decisiones informadas.

Descargue el Informe gratuito de desarrollo de software desde aquí: http://bit.ly/SoftwareDevelopeme…

“La tecnología es una combinación perfecta de innovación e ideación que conceptualiza para formar una plataforma, que es adecuada para operar diversos desarrollos de software que tienen lugar. De hecho, la metodología destinada al desarrollo de software se considera como una estructura utilizada para planificar y controlar el procedimiento de creación de un sistema de información especializado “.

Huff … WTF! Solo quería entender los conceptos básicos de lo que ellos llaman ‘Metodología de Desarrollo de Software’, y todo lo que obtengo son datos de datos y más datos en el concurrido espacio en línea, con ‘información’ inútil o nula. ¿siente lo mismo? ¡No hay problema! ¡Intentará ser claro y conciso al explicar este concepto tan importante, en términos simples!

‘Metodología’: significa lo mismo en ingeniería de software que en inglés, un procedimiento. ¡Sí! Quizás te estés preguntando, entonces, ¿por qué tanto alboroto? ¿Por qué tanta confusión? Yo también siento lo mismo. Es solo que han evolucionado demasiadas metodologías desde el inicio del desarrollo y las pruebas de software: diferentes procedimientos aplicados para estructurar, planificar y controlar el proceso (es decir, inicio, recopilación de requisitos, diseño, codificación, prueba y puesta en marcha).

Antes de saltar a diferentes metodologías, primero comprendamos un concepto subyacente llamado ‘creación de prototipos’.

Creación de prototipos (también conocido como modelado)

¿Qué sucede si, como Cliente, primero puede ver un software de muestra antes de decidirse por el producto final? ¿Guay, verdad? La creación de prototipos de software consiste en crear primero un modelo de software, es decir, versiones incompletas del programa de software que se está desarrollando.

  • La creación de prototipos no es una metodología independiente y completa, sino más bien un enfoque para probar características particulares en el contexto de una metodología completa (como el desarrollo de aplicaciones incrementales, espirales o rápidas).
  • Intenta reducir el riesgo inherente del proyecto dividiendo un proyecto en segmentos más pequeños y proporcionando una mayor facilidad de cambio durante el proceso de desarrollo.

Ahora que tiene una idea justa sobre la creación de prototipos, comprendamos los conceptos básicos de las diferentes metodologías de desarrollo.

Cascada (también conocida como tradicional)

Una de las metodologías clásicas más populares, junto con la nueva era Agile. Al igual que una cascada natural que fluye constantemente hacia abajo, el modelo de cascada es ‘en cascada’ y ‘secuencial’, rígido y lineal.

  • Enfoque fase por fase (secuencial) en el que la siguiente fase comienza solo cuando las actividades de la fase anterior se han completado. Para, por ejemplo, la codificación comienza solo después de que todos los requisitos son finales, la prueba comienza solo después de que se haya completado toda la codificación de todos los requisitos.
  • Un cronograma generalmente se establece con fechas límite para cada etapa
  • Se hace hincapié en la planificación, los horarios, las fechas objetivo, los presupuestos y la implementación de un sistema completo a la vez.
  • Como es un modelo lineal, permite la departamentalización y el control de gestión.
  • El control estricto se mantiene a través de una extensa documentación escrita, revisiones formales y aprobación / aprobación al final de la mayoría de las fases antes de comenzar la siguiente fase.
  • Preferible para un proyecto pequeño donde no hay requisitos inciertos.

El mayor inconveniente: ¿qué pasa si el requisito cambia en el medio? ¡Sí! No abarca los inevitables cambios y revisiones.

Dato curioso: a veces se enseña con el mnemotécnico “ A D ance I n T the D ark E very M onday”, que representa Análisis, Diseño, Implementación, Pruebas, Documentación y Ejecución, y Mantenimiento.

Entrega iterativa e incremental

‘Aumento repetido’, es decir, dividir el proyecto en iteraciones más pequeñas, acercándose al producto final con cada iteración.

  • Reduzca el riesgo inherente del proyecto (mitigando @ cada iteración) y proporcionando una mayor facilidad de cambio.
  • Descubra problemas importantes antes de que problemas o suposiciones defectuosas conduzcan al desastre.

Modelo V (también conocido como Verificación y Validación)

En primer lugar, ‘V’ aquí significa ‘Verificación’ y ‘Validación’. El ciclo de vida de desarrollo y prueba se mapean entre sí, es decir, las pruebas se realizan al lado del desarrollo.

  • Al igual que el modelo en cascada, el ciclo de vida en forma de V es una ruta secuencial de procesos. La prueba del producto se planifica en paralelo con una fase correspondiente de desarrollo.

Espiral (también conocido como basado en el riesgo)

Una fusión de cascada y creación de prototipos, al igual que la forma espiral: el producto de software final es el resultado de la ampliación del alcance y los prototipos posteriores. El beneficio: ¡la administración y el cliente pueden evaluar los riesgos * en la finalización de cada prototipo y, posteriormente, aumentar la escala (próxima iteración de la espiral) o reducir la escala!

  • Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes básicos: (1-Planificación) determinar objetivos, alternativas y limitaciones; (Análisis de 2 riesgos) evaluar alternativas; Identificar y resolver riesgos; (3-Ingeniería) desarrollar y verificar entregables; y (4-Evaluación) planificar la próxima iteración.
  • El rápido desarrollo se logra no acelerando sino manejando los riesgos
  • El sistema final se construye, basado en el prototipo refinado (última iteración de la espiral cuando el cliente está satisfecho con el prototipo).
  • Preferible para proyectos grandes, caros y complicados.
  • Todo el proyecto puede abortarse si el riesgo se considera demasiado grande.

* Los factores de riesgo pueden implicar sobrecostos en los costos de desarrollo, errores de cálculo en los costos operativos o cualquier otro factor que podría resultar en un producto final menos que satisfactorio.

Desarrollo rápido de aplicaciones (RAD, también conocido como Reutilización)

Como su nombre indica, es un procedimiento que favorece un desarrollo rápido en lugar de grandes cantidades de planificación inicial. ¿Y cómo logras la velocidad? ¡Plan en paralelo y reutilización! La falta de una planificación previa exhaustiva generalmente permite que el software se escriba mucho más rápido. Los lenguajes que soportan una implementación más rápida como C ++ o Java ofrecidos en paquetes de programación visual, grupos focales para req. análisis, reutilización de componentes de software, aplazamiento de mejoras de diseño a la próxima versión, revisiones informales y comunicación del equipo y uso de herramientas disponibles como groupware (por ejemplo, Slack), constructores de GUI, DBMS, generadores de código, etc.

  • Desarrolla el prototipo lo más rápido posible
  • Desarrolle iterativamente el software de producción, además del prototipo anterior.

Como habrás adivinado, ya que es rápido: esta metodología restringe la flexibilidad y se limita a tipos específicos de problemas como el software comercial interno o el software personalizado de distribución limitada.

Ágil (también conocido como Responsive)

Desarrollo y pruebas en sprints cortos (sí, es como galope), generalmente de una a cuatro semanas en las que cada sprint tiene como objetivo entregar un subconjunto de requisitos generales.

  • Cada sprint involucra todas las tareas: plan, análisis de requisitos, diseño, código, prueba y documento.
  • Como habrás adivinado, al final de cada sprint: comentarios de los clientes y planificación del próximo sprint.
  • Como es un sprint, las interacciones deben ser rápidas y claras con un tiempo de respuesta mínimo (preferiblemente F2F).
  • Dado que el cliente puede revisar el software real (después de cada sprint), existe una mínima necesidad de documentación.
  • La comunicación directa y la retroalimentación constante del representante del cliente no dejan espacio para conjeturas en el sistema.

Por ejemplo, Crystal Methods, Dynamic Systems Development Model (DSDM) y Scrum.

Dato curioso : el término fue acuñado en el año 2001 cuando se formuló el Manifiesto Ágil.

Notas clave

  • Predefinición de entregas y artefactos específicos que se crearán
  • Una variedad de tales marcos ha evolucionado a lo largo de los años, cada uno con sus propias fortalezas y debilidades reconocidas.
  • Una metodología en particular no es necesariamente adecuada para su uso en todos los proyectos: la más adecuada según diversas consideraciones técnicas, organizativas, de proyecto y de equipo.
  • La selección de una metodología particular tiene un impacto muy alto en las pruebas: define qué, dónde y cuándo de los esfuerzos de prueba planificados, influyen en las pruebas de regresión y determina en gran medida qué técnicas de prueba usar.
  • El objetivo final es entregar un producto de calidad bajo las limitaciones del proyecto.

Espero que este artículo sea útil para comprender los conceptos básicos de las metodologías de desarrollo. Me encantaría conocer tu opinión en la sección de comentarios a continuación.

Tal vez, y otras personas podrían brindar consejos. Lo que pasa con las metodologías es que en un proyecto en particular, puede profundizar con RUP o ITIL, o puede practicar desarrollo ágil o basado en pruebas; pero nunca necesitará todas las metodologías, por lo que una guía completa puede ser menos útil que una breve descripción general de un puñado, que puede obtener de Wikipedia. Además, algo que me pareció confuso al principio es que puede adoptar plantillas de documentos o prácticas de una metodología sin implementarlas completamente, y diferentes organizaciones pueden llamar a metodologías similares con diferentes nombres cuando las especializan. Entonces, por ejemplo, Oracle usa RUP, pero lo llaman OUM, y no es exactamente lo mismo.