Metodología de desarrollo de software

De Wikipedia, la enciclopedia libre
Este artículo o sección necesita una revisión de ortografía y gramática.
Puedes colaborar editándolo. Cuando se haya corregido, puedes borrar este aviso. Si has iniciado sesión, puedes ayudarte del corrector ortográfico, activándolo en: Mis preferencias → Accesorios → Navegación → El corrector ortográfico resalta errores ortográficos con un fondo rojo. Este aviso fue puesto el 21 de septiembre de 2017.

La metodología de desarrollo de software en ingeniería de software es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de información. [1]​

Tres patrones básicos en las metodologías de desarrollo de software.

Introducción[editar]

Una metodología para el desarrollo de software se refiere a un framework (marco de trabajo) que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de información.

A lo largo del tiempo, se han desarrollado muchos métodos, cada uno con sus fortalezas y debilidades

Un framework para metodología de desarrollo de software consiste en:

  • Una filosofía de desarrollo de programas de computación con el enfoque del proceso de desarrollo de software
  • Herramientas, modelos y métodos para asistir al proceso de desarrollo de software

Estos frameworks se asocian habitualmente con organizaciones que desarrollan, apoyan el uso y promueven la metodología.



Scrum es un framework ágil utilizado para gestionar proyectos de software y otros proyectos complejos. Es un enfoque iterativo e incremental que se centra en la entrega continua de productos de alta calidad en un plazo establecido.

Partes importantes del Scrum son:

Product Backlog: es una lista de todas las funcionalidades o características que se deben desarrollar en un proyecto. El Product Owner es el responsable de mantener el Product Backlog actualizado y priorizar las tareas.

Daily Scrum: es una reunión diaria de 15 minutos en la que el equipo de Scrum se sincroniza y actualiza el estado del progreso. Cada miembro del equipo responde a tres preguntas: ¿Qué hizo ayer?, ¿Qué hará hoy? y ¿Hay algún impedimento?

Sprint: es un período de tiempo fijo, generalmente de 2 a 4 semanas, en el que se desarrolla un conjunto de funcionalidades específicas. Al final de cada Sprint, el equipo entrega un incremento de producto funcional.

Sprint Planning: es una reunión en la que el equipo de Scrum planifica el trabajo que se realizará durante el próximo Sprint. Se seleccionan elementos del Product Backlog para incluir en el Sprint Backlog y se definen las tareas necesarias para completarlos.

Sprint Review: es una reunión en la que el equipo de Scrum presenta el incremento de producto funcional que se ha desarrollado durante el Sprint. Los interesados, incluyendo al Product Owner y a los usuarios, dan retroalimentación y sugieren mejoras.

Sprint Retrospective: es una reunión en la que el equipo de Scrum reflexiona sobre el Sprint recién completado. Se discuten los procesos, las herramientas y las prácticas, y se identifican oportunidades de mejora.


Aquí hay un ejemplo de cómo se podría utilizar Scrum:

Imaginemos que una empresa está desarrollando una aplicación móvil para la gestión de proyectos. El equipo de Scrum estaría formado por el Product Owner, el Scrum Master y el equipo de desarrollo. El Product Owner mantendría el Product Backlog actualizado con las funcionalidades prioritarias, y el equipo de Scrum realizaría el desarrollo en Sprints de 2 semanas.

Durante el Sprint Planning, el equipo seleccionaría los elementos del Product Backlog para incluir en el Sprint Backlog y definiría las tareas necesarias para completarlos. Durante el Sprint, el equipo se reuniría diariamente en el Daily Scrum para sincronizar el progreso y discutir cualquier impedimento que surgiera.

Al final del Sprint, el equipo presentaría el incremento de producto funcional en la Sprint Review, y recibiría retroalimentación de los interesados. Luego, en la Sprint Retrospective, el equipo reflexionaría sobre el Sprint recién completado y discutiría oportunidades de mejora para el próximo Sprint.

En resumen, Scrum es un framework ágil. que ayuda a los equipos de desarrollo a trabajar de manera iterativa e incremental para entregar productos de alta calidad en plazos establecidos. Las partes importantes del Scrum son el Product Backlog, los Sprints, el Sprint Planning, el Daily Scrum, la Sprint Review y la Sprint Retrospective.

Historia[editar]

El desarrollo de los sistemas tradicionales de ciclo de vida se originó en la década de 1960 para desarrollar a gran escala funcional de sistemas de negocio en una época de grandes conglomerados empresariales. La idea principal era continuar el desarrollo de los sistemas de información de manera deliberada, estructurada y metódica, reiterando cada una de las etapas del ciclo de vida.

Las metodologías de desarrollo de software tienen como objetivo presentar un conjunto de técnicas tradicionales y modernas de modelado de sistemas que permitan desarrollar software de calidad, incluyendo heurísticas de construcción y criterios de comparación de modelos de sistemas.

Para tal fin se describen, fundamentalmente, herramientas de Análisis y Diseño Orientado a Objetos (UML), sus diagramas, especificación, y criterios de aplicación de las mismas. Como complemento se describirán las metodologías de desarrollo de software que utilizan dichas herramientas, ciclos de vida asociados y discusión sobre el proceso de desarrollo de software más adecuado para las diferentes aplicaciones ejemplos que se presentarán. Principalmente, se presentará el Proceso Unificado, el cual utiliza un ciclo de vida iterativo e incremental.


  • Kendall y Kendall


I. Identificación del problema, oportunidades y objetivos.

II. Determinación de los requerimientos de información.

III. Análisis de las necesidades del sistema.

IV. Diseño del sistema recomendado.

V. Desarrollo y documentación del software.

VI. Pruebas y mantenimiento del sistema.

VII. Implantación y evaluación del sistema.


  • James Senn


I. Ciclo de vida y desarrollo del sistema.

II. Desarrollo por análisis estructurado

III. Prototipo del sistema.


  • Llorens Fabregas

I. Requerimientos.

II. Análisis/Diseño.

III. Construcción.

IV. Pruebas.

V. Producción y mantenimiento.


  • Jonas Montilva


I. Definir el proyecto.

II. Análisis del contexto.

III. Definición de los requerimientos.

IV. Diseño preliminar.

V. Diseño detallado.


  • Roger Pressman


I. Análisis de los requerimientos del Software.

II. Diseño.

III. Generación de código.

IV. Pruebas.

V. Mantenimiento.

Metodologías de desarrollo de software[editar]

  1. Metodología ágil: Es una de varias metodologías de desarrollo de software basadas en el desarrollo iterativo e incremental, en contraposición a las metodologías tradicionales de desarrollo de software lineal o cascada.
  2. Metodologías tradicionales: Imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software más eficiente. Para ello, se hace énfasis en la planificación total de todo el trabajo a realizar y una vez que esta todo detallado, comienza el ciclo de desarrollo del producto software.
1970
1980
1990
Nuevo milenio

Enfoques de desarrollo de software[editar]

Cada metodología de desarrollo de software tiene más o menos su propio enfoque para el desarrollo de software. Estos son los enfoques más generales, que se desarrollan en varias metodologías específicas. Estos enfoques son los siguientes:[1]​

  • Modelo en cascada: Framework lineal.
  • Prototipado: Framework iterativo.
  • Incremental: Combinación de framework lineal e iterativo.
  • Espiral: Combinación de framework lineal e iterativo.
  • RAD: Rapid Application Development, framework iterativo.

Modelo en cascada[editar]

Es un proceso secuencial, fácil de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a través de las fases de análisis de las necesidades, el diseño, implantación, pruebas (validación), la integración, y mantenimiento. La primera descripción formal del modelo de cascada se cita a menudo a un artículo publicado por Winston Royce W.[2]​ en 1970, aunque Royce no utiliza el término "cascada" de este artículo.

Los principios básicos del modelo de cascada son los siguientes:[1]​

  • El proyecto está dividido en fases secuenciales, con cierta superposición y splashback aceptable entre fases.
  • Se hace hincapié en la planificación, los horarios, fechas, presupuestos y ejecución de todo un sistema de una sola vez.
  • Un estricto control se mantiene durante la vida del proyecto a través de la utilización de una amplia documentación escrita, así como a través de comentarios y aprobación / signoff hechas por el usuario y la gestión del área TI al final de la mayoría de las fases y antes de comenzar la próxima fase.

Prototipo[editar]

Permite desarrollar modelos de aplicaciones de software que permiten ver la funcionalidad básica de la misma, sin necesariamente incluir toda la lógica o características del modelo terminado. El prototipo permite al cliente evaluar en forma temprana el producto, e interactuar con los diseñadores y desarrolladores para saber si se está cumpliendo con las expectativas y las funcionalidades acordadas. Los Prototipos no poseen la funcionalidad total del sistema pero si condensa la idea principal del mismo, poco a poco crece su funcionalidad, y maneja un alto grado de participación del usuario.

Incremental[editar]

Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del producto software reservando el resto de aspectos para el futuro.

Espiral[editar]

Los principios básicos son:

  • La atención se centra en la evaluación y reducción del riesgo del proyecto dividiendo el proyecto en segmentos más pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo, así como ofrecer la oportunidad de evaluar los riesgos en fases tempranas del desarrollo.
  • Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes básicos:
  1. Determinar objetivos, alternativas, y desencadenantes de la iteración.
  2. Evaluar alternativas; Identificar y resolver los riesgos.
  3. Desarrollar y verificar los resultados de la iteración.
  4. Plan de la próxima iteración.
  • Cada ciclo comienza con la identificación de los interesados y sus condiciones de ganancia, y termina con la revisión y examinación.[3]​

Rapid Application Development (RAD)[editar]

El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de software, que implica el desarrollo iterativo y la construcción de prototipos. El desarrollo rápido de aplicaciones es un término originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991.

Principios básicos:

  • Objetivo clave es para un rápido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversión.
  • Intenta reducir los riesgos inherentes del proyecto partiéndolo en segmentos más pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo.
  • Orientación dedicada a producir sistemas de alta calidad con rapidez, principalmente mediante el uso de iteración por prototipos (en cualquier etapa de desarrollo), promueve la participación de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de Interfaz gráfica de usuario (GUI), las herramientas (CASE) Computer Aided Software Engineering, los sistemas de gestión de bases de datos (DBMS), lenguajes de programación de cuarta generación, generadores de código, y técnicas orientada a objetos.
  • Hace especial hincapié en el cumplimiento de la necesidad comercial, mientras que la ingeniería tecnológica o la excelencia es de menor importancia.
  • Control de proyecto implica el desarrollo de prioridades y la definición de los plazos de entrega. Si el proyecto empieza a aplazarse, se hace hincapié en la reducción de requisitos para el ajuste, no en el aumento de la fecha límite.
  • En general incluye Joint application development (JAD), donde los usuarios están intensamente participando en el diseño del sistema, ya sea a través de la creación de consenso estructurado en talleres, o por vía electrónica.
  • La participación activa de los usuarios es imprescindible.
  • Iterativamente realiza la producción de software, en lugar de enfocarse únicamente en un prototipo.
  • Produce la documentación necesaria para facilitar el futuro desarrollo y mantenimiento.

Otros enfoques de desarrollo de software[editar]

  1. De clase
  2. De objetos
  3. De estados de transición
  4. De interacción
  5. De módulo
  6. De proceso
  1. Creación
  2. Elaboración
  3. Construcción
  4. Directrices

Hay una serie de herramientas y productos diseñados para facilitar la aplicación. Una de las versiones más populares es la de Rational Unified Process.

Referencias[editar]

  1. ↑ a b c SELECTING A DEVELOPMENT APPROACH Archivado el 2 de enero de 2019 en Wayback Machine.. Revalidated: March 27, 2008. Consultado el 27 de octubre de 2008.
  2. ↑ Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Accessed on line November 28, 2007.
  3. ↑ Error en la cita: Etiqueta <ref> no válida; no se ha definido el contenido de las referencias llamadas ref_duplicada_1
Obtenido de «https://es.wikipedia.org/w/index.php?title=Metodología_de_desarrollo_de_software&oldid=153825577»