Proceso para el desarrollo de software

El Proceso para el desarrollo de software, también denominado ciclo de vida del desarrollo de software, es una estructura aplicada al desarrollo de un producto de software. Hay varios modelos a seguir para el establecimiento de un proceso para el desarrollo de software, cada uno de los cuales describe un enfoque diferente para diferentes actividades que tienen lugar durante el proceso. Algunos autores consideran un modelo de ciclo de vida un término más general que un determinado proceso para el desarrollo de software. Por ejemplo, hay varios procesos de desarrollo de software específicos que se ajustan a un modelo de ciclo de vida de espiral.

Se ha sugerido que este artículo o sección sea fusionado con Proceso del desarrollo del software.

Generalidades

La gran cantidad de organizaciones de desarrollo de software implementan metodologías para el proceso de desarrollo. Muchas de estas organizaciones pertenecen a la industria armamentística, que en los Estados Unidos necesita un certificado basado en su modelo de procesos para poder obtener un contrato.

El estándar internacional que regula el método de selección, implementación y monitoreo del ciclo de vida del software es ISO 12207.

Durante décadas se ha perseguido la meta de encontrar procesos reproducibles y predecibles que mejoren la productividad y la calidad. Algunas de estas soluciones intentan sistematizar o formalizar la aparentemente desorganizada tarea de desarrollar software. Otros aplican técnicas de gestión de proyectos para la creación del software. Sin una gestión del proyecto, los proyectos de software corren el riesgo de demorarse o consumir un presupuesto mayor que el planeado. Dada la cantidad de proyectos de software que no cumplen sus metas en términos de funcionalidad, costes o tiempo de entrega, una gestión de proyectos efectiva es algo imprescindible.

Algunas organizaciones crean un grupo propio (Software Engineering Process Group, abreviado SEPG) encargado de mejorar los procesos para el desarrollo de software en la organización.

Actividades del desarrollo de software

Actividades del proceso de desarrollo de software representados en el desarrollo en cascada. Hay algunos modelos más para representar este proceso.

Planificación

La importante tarea a la hora de crear un producto de software es obtener los requisitos o el análisis de los requisitos. Los clientes suelen tener una idea más bien abstracta del resultado final, pero no sobre las funciones que debería cumplir el software.

Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un análisis del ámbito del desarrollo. Este documento se conoce como especificación funcional.

• Planificación: es el paso previo al inicio de cualquier proyecto de desarrollo y sin dudas el más importante. En este se definen los requerimientos y funcionalidades que debe tener el software, mediante el trabajo en conjunto entre los desarrolladores, el departamento de ventas, los estudios de mercado y, fundamentalmente, el contacto con el cliente. En este punto se realizan asimismo los análisis de riesgo para el emprendimiento y se fijan los requisitos de aseguramiento de la calidad.

Modelos de Desarrollo de Software

Los modelos de desarrollo de software son una representación abstracta de una manera en particular. Realmente no representa cómo se debe desarrollar el software, sino de un enfoque común. Puede ser modificado y adaptado de acuerdo a las necesidades del software en proceso de desarrollo. ^[1] Hay varios modelos para perfilar el proceso de desarrollo, cada uno de los cuales cuenta con pros y contras. El proyecto debería escoger el más apropiado para sus necesidades. En ocasiones puede que una combinación de varios modelos sea apropiado. Existen tres paradigmas de los modelos de desarrollo de software:

1. Paradigma Tradicional:

Es uno de los paradigmas más antiguo, se inventó durante la creación del método estructurado. Si se elige un proyecto, el método varia en etapas.^[2] Como todo modelo, existen sus pros y contras al usar este paradigma:

Si se aplica este paradigma, unos de los principales problemas , es que las etapas realizadas no son autónomas de las siguientes, creando una dependencia estructural y en el caso de un error atrasaría todo el proyecto. Se tiene que tener pautas bien definidas, y que no se incurra a modificación porque implicaría en que el software no cumpla con su ciclo de vida. Tener en cuenta que el cliente no se vea afectado por la impaciencia.^[3]

2. Paradigma Orientado a Objetos: Estos modelos se basan en la Programación orientada a objetos; por lo tanto, se refiere al concepto de clase, el análisis de requisitos y el diseño. El modelo o paradigma orientado a objetos posee dos características principales, las cuales son:

• Permite la reutilización de software.
• Facilita el desarrollo de herramientas informáticas de apoyo al desarrollo, el cual es simple al implementarla en una notación orientado a objetos llamado UML.^[4]

3. Paradigma de Desarrollo Ágil: Es un paradigma de las Metodologías De Desarrollo basado en procesos ágiles. Estos intentan evitar los tediosos caminos de las metodologías tradicionales enfocándose en las personas y los resultados. Usa un enfoque basado en el Valor para construir software, colaborando con el cliente e incorporando los cambios continuamente.^[4]

Modelo de cascada

Esta sección es un extracto de Desarrollo en cascada.[editar]

En Ingeniería de software el desarrollo en cascada, también llamado secuencial o ciclo de vida de un programa (denominado así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior.^[5] Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida.

La versión original fue propuesta por Winston W. Royce en 1970 y posteriormente revisada por Barry Boehm en 1980 e Ian Sommerville en 1985.^[6]

Un ejemplo de una metodología de desarrollo en cascada es:

1. Análisis de requisitos.
2. Diseño del sistema.
3. Diseño del programa.
4. Codificación.
5. Pruebas.
6. Despliegue del programa.
7. Mantenimiento.

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.

Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.^[7]

Modelo de espiral

Esta sección es un extracto de Desarrollo en espiral.[editar]

Este artículo o sección tiene referencias, pero necesita más para complementar su verificabilidad.

El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986,^[8] utilizado generalmente en la ingeniería de software.

Las actividades de este modelo consisten en la conformación de una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

Desarrollo iterativo e incremental

Esta sección es un extracto de Desarrollo iterativo y creciente.[editar]

Comparación entre desarrollo iterativo (izquierda) y desarrollo ágil (derecha).

El desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software creado en respuesta a las debilidades del modelo tradicional de cascada.

Básicamente este modelo de desarrollo, que no es más que un conjunto de tareas agrupadas en pequeñas etapas repetitivas (iteraciones),^[9] es uno de los más utilizados en los últimos tiempos ya que, como se relaciona con novedosas estrategias de desarrollo de software y una programación extrema, es empleado en metodologías diversas.

El modelo consta de diversas etapas de desarrollo en cada incremento, las cuales inician con el análisis y finalizan con la instauración y aprobación del sistema.^[10]

El desarrollo iterativo recomienda la construcción de secciones reducidas de software que irán ganando en tamaño para facilitar así la detección de problemas de importancia antes de que sea demasiado tarde. Los procesos iterativos pueden ayudar a desvelar metas del diseño en el caso de clientes que no saben cómo definir lo que quieren.^[11][12]

Desarrollo ágil

Esta sección es un extracto de Desarrollo ágil de software.[editar]

En el desarrollo de software, las prácticas ágiles (a veces denominadas "Agile")^[13] consisten en la mejora de requisitos, investigación y soluciones mediante el esfuerzo colaborativo de equipos autoorganizados y multifuncionales junto con sus clientes/usuarios finales.^[14] Popularizados en el Manifiesto por el Desarrollo Ágil de Software de 2001,^[15] estos valores y principios se derivaron de, y sustentan, una amplia gama de modelos de desarrollo de software, incluidos Scrum y Kanban.

Aunque hay muchas evidencias anecdóticas de que la adopción de prácticas y valores ágiles mejora la eficacia de los profesionales del software, así como de los equipos y las organizaciones, las pruebas empíricas son dispares y difíciles de encontrar.^[16][17][18]

Codificación y corrección

El desarrollo de codificación y corrección (en inglés "Code and fix") es, más que una estrategia predeterminada, el resultado de una falta de experiencia o presión que se ejerce sobre los desarrolladores para cumplir con una fecha de entrega.^[19] Sin dedicar tiempo de forma explícita para el diseño, los programadores comienzan de forma inmediata a producir código. Antes o después comienza la fase de pruebas de software (a menudo de forma tardía) y los inevitables errores que se encuentran han de eliminarse antes de poder entregar el software.

Orientado a la reutilización

La reutilización de software es un proceso donde se recurre al uso de activos de software en las especificaciones de análisis, diseños, implementación y pruebas de una aplicación o sistemas de software.^[20]

La reutilización se mide en términos del porcentaje de una aplicación que es susceptible de ser utilizada en otra. El rango general de uso recurrente está entre el 15% y 85%.^[21]

La reutilización tiene principios como la existencia de parecidos en distintos sistemas de un mismo dominio, donde el software puede representarse como una combinación de módulos y los sistemas nuevos se puede caracterizar por diferencias respecto a los antiguos sistemas.^[22]

Modelos de mejora de procesos

Capability Maturity Model Integration

El Capability Maturity Model Integration (CMMI), en español «Integración de Modelos de Madurez de Capacidades» es uno de los modelos líderes basados en mejores prácticas. Son evaluaciones independientes las que confirman el grado con el que una organización siguen sus propios procesos, que no evalúa la calidad de los procesos o del software que se produce. CMMI ha reemplazado a CMM y tiene un ámbito global, no sólo en procesos destinados al desarrollo del software.

ISO 9000

ISO 9000 describe estándares para un proceso organizado formalmente para resultar en un producto y los métodos de gestión y monitoreo del progreso. Aunque este estándar se creó inicialmente para el sector de producción, los estándares de ISO 9000 también se han aplicado al desarrollo del software. Al igual que CMMI, que una organización está certificada con el ISO 9000 no garantiza la calidad del resultado final, sólo confirma que se ha seguido los procesos establecidos.

ISO 15504

ISO 15504, también conocido como Software Process Improvement Capability Determination (SPICE), en español «Determinación de la Capacidad de Mejora del Proceso de Software» es un marco para la evaluación de procesos de software. Este estándar tiene como objetivo un modelo claro para poder comparar procesos. SPICE se utiliza como en el caso de CMMI. Modela procesos para gestionar, controlar, guiar y monitorear el desarrollo del software. Este modelo se utiliza entonces para medir lo que una organización o proyecto hace durante el desarrollo del software. Esta información se analiza para identificar puntos débiles y definir acciones para subsanarlos. También identifica puntos fuertes que pueden adoptarse en el resto de la organización.

Métodos formales

Los métodos formales son soluciones matemáticas para resolver problemas de software y hardware a nivel de requisitos, especificación y diseño. Ejemplos de métodos formales incluyen el Método B, la red de Petri, la demostración automática de teoremas, RAISE y el VDM. Hay varias notaciones de especificaciones formales, tales como el lenguaje Z. Más generalmente, se puede utilizar la teoría de autómatas para aumentar y validar el comportamiento de la aplicación diseñando un sistema de autómata finito.

Las metodologías basadas en los autómatas finitos permiten especificación de software ejecutable y evitar la creación convencional de código.

Los métodos formales se suelen aplicar en software de aviación, especialmente si es software de seguridad crítico. Los estándares de aseguramiento del software de seguridad, tales como DO178B demandan métodos formales en el nivel más alto de categorización (Nivel A).

La formalización del desarrollo de software está ganando en fuerza poco a poco, en otros ámbitos, con la aplicación del lenguaje de especificación OCL2.0 (y especializaciones tales como Java Modeling Language) y particularmente con Model-driven Architecture, que permite la ejecución de diseños, incluso especificaciones.

Otra tendencia que está surgiendo en el desarrollo de software es la redacción de especificaciones en algún tipo de lógica (normalmente una variación de FOL), para acto seguido ejecutar esa lógica como si se tratase de un programa. El lenguaje OWL, basado en lógica descriptiva, es un buen ejemplo. También se está trabajando en enlazar un idioma natural de forma automática con lógica, lógica que puede ejecutarse. Ejemplo en este campo es el Attempto Controlled English, una lógica de negocios de Internet, que no busca controlar el vocabulario o la sintaxis. Una características de los sistemas que apoyan el vínculo bidireccional inglés-lógica y ejecución directa de la lógica es que pueden explicar sus resultados en inglés en un nivel de negocios o científico.

Principales Roles en el proceso de Desarrollo de Software

Un Rol se define como una “Función que alguien o algo cumple” (Abstracta Academy, 2016).

Cada uno de los roles aportará al grupo parte del total necesario para tener éxito en el desarrollo. Los roles son necesarios para cubrir todas las especificaciones necesarias para cumplir un proceso ya que no todos tenemos las mismas cualidades y experiencias. Además al asignar roles, se definen objetivos y actividades para cada uno; lo anterior evitando que alguna actividad no sea asignada o que dos personas realicen el mismo trabajo.

Descripción de roles en el Proceso de Desarrollo de Software

El software se construye en equipo y hay muchas metodologías diferentes. Los roles se asignan de acuerdo a las capacidades de cada persona, así como también su especialización, experiencia e interés. Los roles más comunes son:

Gerente de proyecto

Tiene por función presentar informes sobre las litigaciones de riesgos, hacer cumplir los plazos y lleva el control de los costos. También organiza el equipo, realiza planificación y estima el tiempo de las actividades. En conclusión, resuelve problemas como el señor Lobo.

Analista de requerimientos

Se encarga del revelamiento de los requerimientos esenciales para el desarrollo del Software, la documentación de los requerimientos para así el resto del equipo lo pueda consultar en cualquier momento. Debe ser una persona con capacidad de abstracción y análisis.

Desarrollador de software o programador

Encargado de la concepción y el diseño, escribe el código, prueba lo que construye y se encarga de hacer el mantenimiento del código.

Testeador

Diseña y ejecuta las pruebas, para ello requiere conocer el producto a probar claro esta, estudiar funcionalidad del producto y desarrollar las pruebas que revelen incidentes críticos. Reporta los incidentes y provee información sobre la calidad del sistema.

Arquitecto de software

Determina las estructuras de la aplicación y las tecnologías con las que se construirá la aplicación. Está encargado del aseguramiento de la calidad, mejorar continuamente la arquitectura. Gestiona los requerimientos no funcionales, asume la dirección técnica para asegurar que todos los aspectos de la arquitectura se estén desarrollando de manera correcta.

Debe ser una persona con un innato sentido de liderazgo, dispuesto a formar a los integrantes del equipo, dispuesto a recibir y aplicar abiertamente recomendaciones de este.

Véase también

• Ingeniería de software
• Anexo:Filosofías del desarrollo de software
• Scrum
• Metodología de desarrollo de software
• Desarrollo ágil de software
• Programación extrema
• Prototipo
• Desarrollo de software
• Lenguaje unificado de modelado