Wikibrief

Proceso de desarrollo de software

Editar artículo
Desarrollo de software
Actividades centrales Actividades principales
Paradigmas y modelos
Metodologías y marcos
Disciplinas de apoyo
Practicas
Instrumentos
Estándares y cuerpos de conocimiento
Glosarios
Contornos
  • v
  • t
  • mi

En ingeniería de software, un proceso de desarrollo de software es el proceso de dividir el trabajo de desarrollo de software en pasos o subprocesos más pequeños, paralelos o secuenciales para mejorar el diseño, la gestión de productos y la gestión de proyectos. También se conoce como ciclo de vida de desarrollo de software ( SDLC). La metodología puede incluir la pre-definición de entregables y artefactos específicos que son creados y completados por un equipo de proyecto para desarrollar o mantener una aplicación.

La mayoría de los procesos de desarrollo modernos se pueden describir vagamente como ágiles. Otras metodologías incluyen cascada, creación de prototipos, desarrollo iterativo e incremental, desarrollo en espiral, desarrollo rápido de aplicaciones y programación extrema.

Un "modelo" de ciclo de vida a veces se considera un término más general para una categoría de metodologías y un "proceso" de desarrollo de software es un término más específico para referirse a un proceso específico elegido por una organización específica. Por ejemplo, hay muchos procesos de desarrollo de software específicos que se ajustan al modelo de ciclo de vida en espiral. El campo a menudo se considera un subconjunto del ciclo de vida del desarrollo de sistemas.

Contenido
  • 1 Historia
  • 2 Prototipos
  • 3 Metodologías
    • 3.1 Desarrollo ágil
    • 3.2 Integración continua
    • 3.3 Desarrollo incremental
    • 3.4 Desarrollo rápido de aplicaciones
    • 3.5 Desarrollo de la cascada
    • 3.6 Desarrollo en espiral
    • 3.7 Metodologías avanzadas
  • 4 Metamodelos de proceso
  • 5 En la práctica
  • 6 Véase también
  • 7 referencias
  • 8 Enlaces externos

Historia

El marco de la metodología de desarrollo de software (también conocido como SDM) no surgió hasta la década de 1960. Según Elliott (2004), el ciclo de vida de desarrollo de sistemas (SDLC) puede considerarse el marco metodológico formalizado más antiguo para la construcción de sistemas de información. La idea principal del SDLC ha sido "perseguir el desarrollo de sistemas de información de una manera muy deliberada, estructurada y metódica, requiriendo cada etapa del ciclo de vida - desde el inicio de la idea hasta la entrega del sistema final - para llevarse a cabo de forma rígida y secuencial "dentro del contexto del marco que se está aplicando. El objetivo principal de este marco metodológico en la década de 1960 era "desarrollar sistemas comerciales funcionales a gran escala en una era de conglomerados comerciales a gran escala. Las actividades de los sistemas de información giraban en torno al procesamiento pesado de datos y las rutinas de procesamiento de números ".

Las metodologías, procesos y marcos varían desde pasos proscriptivos específicos que una organización puede usar directamente en el trabajo diario, hasta marcos flexibles que una organización usa para generar un conjunto personalizado de pasos a la medida de las necesidades de un proyecto específico o grupo. En algunos casos, una organización "patrocinadora" o de "mantenimiento" distribuye un conjunto oficial de documentos que describen el proceso. Los ejemplos específicos incluyen:

1970
Decenio de 1980
Decenio de 1990
2000

2010

Es notable que desde DSDM en 1994, todas las metodologías en la lista anterior, excepto RUP, han sido metodologías ágiles; sin embargo, muchas organizaciones, especialmente los gobiernos, todavía usan procesos pre-ágiles (a menudo en cascada o similares). El proceso del software y la calidad del software están estrechamente relacionados; En la práctica se han observado algunas facetas y efectos inesperados.

Entre estos, se ha establecido otro proceso de desarrollo de software en código abierto. La adopción de estas mejores prácticas procesos conocidos y establecidos dentro de los límites de una empresa se denomina fuente interna.

Creación de prototipos

La creación de prototipos de software consiste en crear prototipos, es decir, versiones incompletas del programa de software que se está desarrollando.

Los principios básicos son:

  • La creación de prototipos no es una metodología de desarrollo completa e independiente, 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, en espiral o rápido (RAD)).
  • Intenta reducir el riesgo inherente del proyecto dividiéndolo en segmentos más pequeños y proporcionando más facilidad de cambio durante el proceso de desarrollo.
  • El cliente participa durante todo el proceso de desarrollo, lo que aumenta la probabilidad de que el cliente acepte la implementación final.
  • Si bien algunos prototipos se desarrollan con la expectativa de que se descarten, en algunos casos es posible evolucionar de prototipos a sistemas operativos.

Es necesario tener una comprensión básica del problema empresarial fundamental para evitar resolver los problemas incorrectos, pero esto es cierto para todas las metodologías de software.

Metodologías

Desarrollo ágil

Artículo principal: Desarrollo de software ágil

El "desarrollo de software ágil" se refiere a un grupo de marcos de desarrollo de software basados ​​en el desarrollo iterativo, donde los requisitos y las soluciones evolucionan a través de la colaboración entre equipos multifuncionales autoorganizados. El término fue acuñado en el año 2001 cuando se formuló el Manifiesto Ágil.

El desarrollo de software ágil utiliza el desarrollo iterativo como base, pero aboga por un punto de vista más ligero y centrado en las personas que los enfoques tradicionales. Los procesos ágiles incorporan fundamentalmente la iteración y la retroalimentación continua que proporciona para refinar y entregar sucesivamente un sistema de software.

El modelo ágil también incluye los siguientes procesos de desarrollo de software:

Integración continua

Artículo principal: Integración continua

La integración continua es la práctica de fusionar todas las copias de trabajo del desarrollador en una línea principal compartida varias veces al día. Grady Booch nombró y propuso IC por primera vez en su método de 1991, aunque no abogó por la integración varias veces al día. La programación extrema (XP) adoptó el concepto de CI y defendió la integración más de una vez al día, quizás hasta decenas de veces al día.

Desarrollo incremental

Artículo principal: desarrollo iterativo e incremental

Se aceptan varios métodos para combinar metodologías de desarrollo de sistemas lineales e iterativos, siendo el objetivo principal de cada uno reducir el riesgo inherente del proyecto dividiendo un proyecto en segmentos más pequeños y proporcionando más facilidad de cambio durante el proceso de desarrollo.

Hay tres variantes principales de desarrollo incremental:

  1. Se realiza una serie de mini-cascadas, donde todas las fases de la cascada se completan para una pequeña parte de un sistema, antes de pasar al siguiente incremento, o
  2. Los requisitos generales se definen antes de proceder al desarrollo evolutivo en mini-cascada de incrementos individuales de un sistema, o
  3. El concepto inicial del software, el análisis de requisitos y el diseño de la arquitectura y el núcleo del sistema se definen a través de Waterfall, seguido de la implementación incremental, que culmina con la instalación de la versión final, un sistema en funcionamiento.

Desarrollo rápido de aplicaciones

Artículo principal: Desarrollo rápido de aplicaciones Modelo de desarrollo rápido de aplicaciones (RAD)

El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de software que favorece el desarrollo iterativo y la construcción rápida de prototipos en lugar de grandes cantidades de planificación inicial. La "planificación" del software desarrollado con RAD está intercalada con la escritura del propio software. La falta de una planificación previa exhaustiva generalmente permite que el software se escriba mucho más rápido y facilita el cambio de requisitos.

El proceso de desarrollo rápido comienza con el desarrollo de modelos de datos preliminares y modelos de procesos comerciales utilizando técnicas estructuradas. En la siguiente etapa, los requisitos se verifican mediante la creación de prototipos, eventualmente para refinar los modelos de datos y procesos. Estas etapas se repiten iterativamente; un mayor desarrollo da como resultado "una declaración combinada de requisitos comerciales y diseño técnico que se utilizará para construir nuevos sistemas".

El término se utilizó por primera vez para describir un proceso de desarrollo de software introducido por James Martin en 1991. Según Whitten (2003), es una fusión de varias técnicas estructuradas, especialmente ingeniería de tecnología de la información impulsada por datos, con técnicas de creación de prototipos para acelerar el desarrollo de sistemas de software..

Los principios básicos del desarrollo rápido de aplicaciones son:

  • El objetivo clave es el rápido desarrollo y la entrega de un sistema de alta calidad a un costo de inversión relativamente bajo.
  • Intenta reducir el riesgo inherente del proyecto dividiéndolo en segmentos más pequeños y proporcionando más facilidad de cambio durante el proceso de desarrollo.
  • Tiene como objetivo producir sistemas de alta calidad rápidamente, principalmente a través de prototipos iterativos (en cualquier etapa de desarrollo), participación activa del usuario y herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de interfaz gráfica de usuario (GUI), herramientas de ingeniería de software asistida por computadora (CASE), sistemas de administración de bases de datos (DBMS), lenguajes de programación de cuarta generación, generadores de código y técnicas orientadas a objetos.
  • El énfasis clave está en satisfacer las necesidades comerciales, mientras que la excelencia tecnológica o de ingeniería es de menor importancia.
  • El control del proyecto implica priorizar el desarrollo y definir plazos de entrega o “timeboxes”. Si el proyecto comienza a fallar, se hace hincapié en reducir los requisitos para ajustarse al calendario, no en aumentar el plazo.
  • Generalmente incluye el diseño de aplicaciones conjuntas (JAD), donde los usuarios están intensamente involucrados en el diseño del sistema, a través de la construcción de consenso en talleres estructurados o interacción facilitada electrónicamente.
  • La participación activa del usuario es imperativa.
  • Produce software de producción de forma iterativa, a diferencia de un prototipo desechable.
  • Produce la documentación necesaria para facilitar el desarrollo y el mantenimiento futuros.
  • Los métodos estándar de análisis y diseño de sistemas pueden adaptarse a este marco.

Desarrollo de cascada

Artículo principal: modelo de cascada Las actividades del proceso de desarrollo de software representadas en el modelo de cascada. Hay varios otros modelos para representar este proceso.

El modelo de cascada es un enfoque de desarrollo secuencial, en el que se considera que el desarrollo fluye de manera constante hacia abajo (como una cascada) a través de varias fases, por lo general:

La primera descripción formal del método se cita a menudo como un artículo publicado por Winston W. Royce en 1970, aunque Royce no utilizó el término "cascada" en este artículo. Royce presentó este modelo como un ejemplo de un modelo defectuoso que no funciona.

Los principios básicos son:

  • El proyecto se divide en fases secuenciales, con algunas superposiciones y salpicaduras aceptables entre las fases.
  • El énfasis está en la planificación, los cronogramas, las fechas objetivo, los presupuestos y la implementación de un sistema completo al mismo tiempo.
  • Se mantiene un control estricto durante la vida del proyecto a través de una extensa documentación escrita, revisiones formales y aprobación / aprobación por parte del usuario y la gestión de la tecnología de la información que se produce al final de la mayoría de las fases antes de comenzar la siguiente. La documentación escrita es un entregable explícito de cada fase.

El modelo en cascada es un enfoque de ingeniería tradicional aplicado a la ingeniería de software. Un enfoque de cascada estricto desalienta volver a visitar y revisar cualquier fase anterior una vez que esté completa. Esta "inflexibilidad" en un modelo de cascada pura ha sido fuente de críticas por parte de los partidarios de otros modelos más "flexibles". Se le ha culpado ampliamente de varios proyectos gubernamentales a gran escala que superan el presupuesto, a lo largo del tiempo y, a veces, no cumplen con los requisitos debido al enfoque de Big Design Up Front. Excepto cuando se requiere por contrato, el modelo en cascada ha sido reemplazado en gran medida por metodologías más flexibles y versátiles desarrolladas específicamente para el desarrollo de software. Ver Crítica del modelo Waterfall.

Desarrollo en espiral

Modelo en espiral (Boehm, 1988) Artículo principal: modelo en espiral

En 1988, Barry Boehm publicó un "modelo en espiral" de desarrollo de sistemas de software formal, que combina algunos aspectos clave del modelo en cascada y metodologías de creación rápida de prototipos, en un esfuerzo por combinar las ventajas de los conceptos de arriba hacia abajo y de abajo hacia arriba. Hizo hincapié en un área clave que muchos consideraron que otras metodologías habían descuidado: el análisis de riesgos iterativo deliberado, especialmente adecuado para sistemas complejos a gran escala.

Los principios básicos son:

  • El enfoque está en la evaluación de riesgos y en minimizar el riesgo del proyecto al dividir un proyecto en segmentos más pequeños y brindar más facilidad de cambio durante el proceso de desarrollo, así como brindar la oportunidad de evaluar los riesgos y sopesar la consideración de la continuación del proyecto a lo largo del ciclo de vida.
  • "Cada ciclo implica una progresión a través de la misma secuencia de pasos, para cada parte del producto y para cada uno de sus niveles de elaboración, desde un documento general de concepto de operación hasta la codificación de cada programa individual".
  • Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes básicos: (1) determinar los objetivos, las alternativas y las limitaciones de la iteración; (2) evaluar alternativas; Identificar y resolver riesgos; (3) desarrollar y verificar los entregables de la iteración; y (4) planifique la próxima iteración.
  • Comience cada ciclo con una identificación de las partes interesadas y sus "condiciones ganadoras", y finalice cada ciclo con una revisión y un compromiso.

Metodologías avanzadas

Otras metodologías de proyectos de software de alto nivel incluyen:

Procesar metamodelos

Algunos " modelos de proceso " son descripciones abstractas para evaluar, comparar y mejorar el proceso específico adoptado por una organización.

  • ISO / IEC 12207 es el estándar internacional que describe el método para seleccionar, implementar y monitorear el ciclo de vida del software.
  • La Integración del modelo de madurez de capacidad (CMMI) es uno de los modelos líderes y se basa en las mejores prácticas. Las evaluaciones independientes califican a las organizaciones en función de qué tan bien siguen sus procesos definidos, no según la calidad de esos procesos o el software producido. CMMI ha reemplazado a CMM.
  • ISO 9000 describe los estándares para un proceso organizado formalmente para fabricar un producto y los métodos de gestión y seguimiento del progreso. Aunque la norma se creó originalmente para el sector de fabricación, las normas ISO 9000 también se han aplicado al desarrollo de software. Al igual que CMMI, la certificación con ISO 9000 no garantiza la calidad del resultado final, solo que se han seguido procesos de negocio formalizados.
  • ISO / IEC 15504 Tecnología de la información: la evaluación de procesos, también conocida como determinación de la capacidad de mejora de procesos de software (SPICE), es un "marco para la evaluación de procesos de software". Esta norma tiene como objetivo establecer un modelo claro para la comparación de procesos. SPICE se usa de manera muy similar a CMMI. Modela procesos para administrar, controlar, guiar y monitorear el desarrollo de software. Este modelo se utiliza luego para medir lo que hace realmente una organización de desarrollo o un equipo de proyecto durante el desarrollo de software. Esta información se analiza para identificar debilidades e impulsar la mejora. También identifica las fortalezas que pueden continuar o integrarse en la práctica común para esa organización o equipo.
  • ISO / IEC 24744 Ingeniería de software — Metamodelo para metodologías de desarrollo, es un metamodelo basado en tipos de potencia para metodologías de desarrollo de software.
  • SPEM 2.0 por el Grupo de Gestión de Objetos
  • Metodología de sistemas blandos : un método general para mejorar los procesos de gestión
  • Ingeniería de métodos : un método general para mejorar los procesos del sistema de información.

En la práctica

Los tres enfoques básicos aplicados a los marcos metodológicos de desarrollo de software.

A lo largo de los años, han evolucionado varios de estos marcos, cada uno con sus propias fortalezas y debilidades reconocidas. Un marco de metodología de desarrollo de software no es necesariamente adecuado para todos los proyectos. Cada uno de los marcos metodológicos disponibles se adapta mejor a tipos específicos de proyectos, basándose en diversas consideraciones técnicas, organizativas, de proyecto y de equipo.

Las organizaciones de desarrollo de software implementan metodologías de proceso para facilitar el proceso de desarrollo. A veces, los contratistas pueden requerir metodologías empleadas, un ejemplo es la industria de defensa de EE. UU ., Que requiere una calificación basada en modelos de proceso para obtener contratos. El estándar internacional para describir el método de selección, implementación y monitoreo del ciclo de vida del software es ISO / IEC 12207.

Un objetivo de décadas ha sido encontrar procesos repetibles y predecibles que mejoren la productividad y la calidad. Algunos intentan sistematizar o formalizar la aparentemente rebelde tarea de diseñar software. Otros aplican técnicas de gestión de proyectos para diseñar software. Un gran número de proyectos de software no cumplen con sus expectativas en términos de funcionalidad, costo o cronograma de entrega; consulte la Lista de proyectos de software personalizados con errores y sobrepresupuesto para ver algunos ejemplos notables.

Las organizaciones pueden crear un Grupo de Procesos de Ingeniería de Software (SEPG), que es el punto focal para la mejora de procesos. Compuesto por profesionales de línea que tienen habilidades variadas, el grupo está en el centro del esfuerzo colaborativo de todos en la organización que están involucrados con la mejora de procesos de ingeniería de software.

Un equipo de desarrollo en particular también puede estar de acuerdo con los detalles del entorno de programación, como qué entorno de desarrollo integrado se utiliza y uno o más paradigmas de programación dominantes, reglas de estilo de programación o la elección de bibliotecas de software o marcos de software específicos. Estos detalles generalmente no están dictados por la elección del modelo o la metodología general.

Ciclo de vida de desarrollo de software (SDLC)

Ver también

Referencias

enlaces externos

Contactos: mail@wikibrief.org
El contenido está disponible bajo la licencia CC BY-SA 3.0 (a menos que se indique lo contrario).