Procesos de Software

Actualmente existe una gran diversidad de opciones relacionadas con procesos de desarrollo. Constantemente se escuchan diferentes acrónimos como CMM, CMMI, RUP, ISO, PSP, TSP, etc., que causan confusión, principalmente debido a la mala interpretación de los mismos.

Antes de definir lo que es un proceso de desarrollo de software, entendamos lo que es un proceso. Una definición sencilla de proceso es “serie de acciones que conducen a un final”. Esta definición parece coincidir con las ideas generales de la gente sobre procesos, pero deja muchas preguntas abiertas. ¿El proceso es la forma en que la organización opera —desde mercadotecnia hasta recursos humanos— o es la forma en que un desarrollador diseña, produce código, o prueba el software? ¿El proceso se refiere a administración, ingeniería, o ambas? ¿El proceso implica demasiada documentación y nos abstiene de desarrollar el producto objetivo?

La respuesta a éstas puede variar dependiendo de la perspectiva. Sin embargo, siempre que para alcanzar algún fin deseado necesitemos ejecutar una serie de acciones, y estas acciones tengan cierto orden, dependencias, roles responsables, resultados, tiempos de ejecución y herramientas de apoyo, estaremos hablando de procesos, que pueden ser predefinidos y personalizados.

Un proceso de desarrollo de software es un conjunto de personas, estructuras de organización, reglas, políticas, actividades y sus procedimientos, componentes de software, metodologías, y herramientas utilizadas o creadas específicamente para definir, desarrollar, ofrecer un servicio, innovar y extender un producto de software.

Un proceso de software efectivo habilita a la organización a incrementar su productividad al desarrollar software:

• Permite estandarizar esfuerzos, promover reuso, repetición y consistencia entre proyectos.

• Provee la oportunidad de introducir mejores prácticas de la industria.

• Permite entender que las herramientas deben ser utilizadas para soportar un proceso.

• Establece la base para una mayor consistencia y mejoras futuras. 

Un proceso de software mejora los esfuerzos de mantenimiento y soporte:

• Define cómo manejar los cambios y liberaciones a sistemas de software existentes.

• Define cómo lograr la transición del software a la operación, y cómo ejecutar los esfuerzos de operación y soporte.

Necesitamos un proceso de software cuya funcionalidad esté probada en la práctica, y personalizado para que cumpla con nuestras necesidades específicas.

Modelos de Proceso de Software

Modelo de cascada: 

El modelo de cascada muestra un proceso donde los desarrolladores han de seguir las siguientes fases de forma sucesiva:

1. Especificación de requisitos

2. Diseño del software

3. Construcción o Implementación del software

4. Integración

5. Pruebas (o validación)

6. Despliegue (o instalación)

7. Mantenimiento

Modelo de espiral:

Este modelo, también no secuencial, es algo más complejo que los anteriores, aunque incluye un elemento muy útil e importante en el desarrollo del software: análisis de riesgos. El modelo en espiral concreta cuatro fases:

- Planificación

- Análisis de Riesgos

- Ingeniería (Construcción del prototipo)

- Evaluación por el cliente

Si ésta última fase es afirmativa, el modelo continúa con la estructura del Ciclo de vida Clásico. Si el cliente no está satisfecho con el resultado, se cubre otra banda de la espiral y se vuelve a la primera fase (de planificación).

Desarrollo incremental:

El modelo incremental es una evolución del modelo de cascada; viene a suplir el problema de no poder retroceder en las fases de desarrollo del software. Es, por tanto, un modelo no secuencial.

El funcionamiento es sencillo. Comienza con el análisis de los requisitos, tras el cual se prepara un primer diseño. La novedad de este modelo respecto del anterior, es la introducción de iteraciones para “bifurcar” diseños. Es decir, este modelo ofrece la posibilidad de comenzar un diseño, arquitectura, estructura, etc del software, que de no convencer al cliente (o al propio programador) es rechazado y se comienza con una segunda iteración (o un segundo diseño), sin necesidad de realizar un nuevo análisis de requisitos. Pueden realizarse tantas iteraciones (también llamadas incrementos) como sean necesarias.

Desarrollo ágil:

El desarrollo ágil de software utiliza un desarrollo iterativo como base para abogar por un punto de vista más ligero y más centrado en las personas que en el caso de las soluciones tradicionales. Los procesos ágiles utilizan retroalimentación en lugar de planificación, como principal mecanismo de control. La retroalimentación se canaliza por medio de pruebas periódicas y frecuentes versiones del software.

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.2 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.

Fuente: http://sg.com.mx/content/view/23

http://html.rincondelvago.com/modelos-de-procesos-de-software.html

http://es.wikipedia.org/wiki/Proceso_para_el_desarrollo_de_software

MODELOS DEL PROCESO DE SOFTWARE

MODELOS DE PROCESOS EN CASCADA:

Este modelo fue diseñado por el señor Royce y básicamente lo que nos quiere dar a entender es que se debe completar un paso correctamente sin nada de errores para poder continuar con el siguiente paso.

CARACTERISTICAS: es una forma básica en el desarrollo de  software y se puede representar por pasos o procesos. De igual forma se debe verificar al finalizar el software de su correcto funcionamiento.

PASOS O FASES DE ESTE MODELO

• Ingeniería y análisis del sistema: Establece todos los requisitos de los elementos del sistema.
• Análisis de los requisitos del software: identifica las funciones del software, rendimiento, interfaces y toda su información.
• Diseño: se basa en una estructura de datos, arquitectura del software el detalle de los procedimientos y las caracterizaciones de la interfaz, de igual forma designa o escoje todas las herramientas para su codificación.
• Codificación (implementación): este diseño se convierte en un lenguaje para la maquina.
• Pruebas (verificación): en este paso se comprueba si existe algún tipo de error con el software o si este esta funcionando correctamente y se pueda entregar satisfactoriamente al usuario.
• Mantenimiento: este paso se ofrece con el fin de verificar si después de ser entregado el software puede presentar algunos errores o este no se adapte al entorno del cliente y no cumpla sus expectativas.

VENTAJA: este modelo se caracteriza por ser sencillo y de fácil uso y entendimiento para el cliente.

DESVENTAJA: el cliente debe ser paciente pues el software estará en su rendimiento total al final de las últimas etapas del proyecto.

MODELOS PROCESOS INCREMENTADOS:

El modelo incremental es una evolución del modelo de cascada; viene a suplir el problema de no poder retroceder en las fases de desarrollo del software. Es, por tanto, un modelo no secuencial.

El funcionamiento es sencillo. Comienza con el análisis de los requisitos, tras el cual se prepara un primer diseño. La novedad de este modelo respecto del anterior, es la introducción de iteraciones para “bifurcar” diseños. Es decir, este modelo ofrece la posibilidad de comenzar un diseño, arquitectura, estructura, etc del software, que de no convencer al cliente (o al propio programador) es rechazado y se comienza con una segunda iteración (o un segundo diseño), sin necesidad de realizar un nuevo análisis de requisitos. Pueden realizarse tantas iteraciones (también llamadas incrementos) como sean necesarias.

En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento.

Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo.

De esta forma el tiempo de entrega se reduce considerablemente.

Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional.

El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadir• personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.

El Modelo Incremental se puede ver aquí en forma gráfica:

• Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.
• El usuario se involucra más.
• Difícil de evaluar el coste total.
• Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.
• Requiere gestores experimentados.
• Los errores en los requisitos se detectan tarde.
• El resultado puede ser muy positivo.

Pipeline

La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior.

Esta arquitectura es muy común en el desarrollo de programas para el intérprete de comandos, ya que se pueden concatenar comandos fácilmente con tuberías (pipe).

También es una arquitectura muy natural en el paradigma de programación funcional, ya que equivale a la composición de funciones matemáticas.

Interprete de comandos

Parte fundamental de un sistema operativo que ordena la ejecución de mandatos obtenidos del usuario por medio de una interfaz alfanumérica.

Características

• Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia.
• El usuario se involucre más.
• Difícil de evaluar el costo total.
• Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.
• Requiere gestores experimentados.
• Los errores en los requisitos se detectan tarde.
• El resultado puede ser muy positivo.
• Iteración de Lineal Secuencial.
• Cada iteración devuelve un “Incremento” o versión operativa. (Ej. Editor de texto).
• Útil cuando no se está seguro de cumplir con plazos de tiempo o se tiene una fecha imposible de cambiar.

Ventajas:

• Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. 
• También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.
• El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
• Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.
• Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.
• Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.

Desventajas:

• El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.
• Requiere de mucha planeación, tanto administrativa como técnica.
• Requiere de metas claras para conocer el estado del proyecto.

MODELOS DE PROCESOS EVOLUTIVOS:

El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de separarse.

Existen dos tipos de desarrollo evolutivo:

1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.

2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.

Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas en comparación con un enfoque en cascada ya que el sistema se va ajustando a las necesidades del cliente, a la vez que él mismo entiende mejor sus propios requerimientos. Sin embargo el enfoque evolutivo desde una perspectiva de ingeniería y gestión suele tener dos grandes problemas:

1. El proceso no es visible. Los administradores tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema.

2. A menudo los sistemas tienen una estructura deficiente. Los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en una tarea difícil y costosa.

Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para sistemas pequeños y medianos. En los sistemas grandes, los constantes cambios en el desarrollo solo dificultan la estabilidad y la integración de los avances de los distintos grupos de trabajo que puedan existir. La mayoría de las empresas que desarrollan grandes sistemas usan un modelo mixto que usa las mayores fortalezas de los enfoques evolutivos y de cascada.

MODELOS ORIENTADOS A LA REUTILIZACIÓN:

¿Por qué la Reutilización de Software?

Mientras hoy, el software se hace cada vez más esencial en la vida cada día; los procesos de desarrollo de software actuales no apoyan este rápido crecimiento de las necesidades. Los procesos de desarrollo de software actuales principalmente se dirigen al desarrollo nuevo de software, y no hacen caso de todos los sistemas existentes, antes activos de desarrollo. Los productores de software necesitan satisfacer los requisitos crecientes del cliente rápidamente para nuevos productos y servicios. Este crecimiento rápido causa cada vez más nuevo software, que requiere cada vez más esfuerzos de desarrollo.

Mientras por una parte, las organizaciones tratan de controlar gastos crecientes de software; por otra parte, ellos deben responder rápidamente al cambio de necesidades comerciales y nuevas tecnologías y deben producir sistemas de software cada vez más complejos más rápidamente y más barato a fin de permanecer competitivos.

Es obvio que la reutilización de software sistemática puede reducir enormemente gastos de desarrollo en aplicación de software, acortar elementos de desarrollo, y reducir el riesgo de fracaso con la nueva tecnología, así como enormemente mejorar la calidad y la fiabilidad de productos de software.

Así en los gastos de desarrollo de software de hoy, la reutilización de software es un deber para cada productor de software, a fin de ser capaz de proporcionar mejores productos, más rápido y más barato que antes.

A continuación se describe el Proceso de Reutilización de Software empleada en la organización para los procesos de desarrollo de software

En este proceso se define los roles involucrados que participan en la identificación de la reutilización en cada uno de los elementos de software. Cada rol que participa dentro del proceso de reutilización debe participar en definir los elementos reutilizables en función a las actividades que realiza en el proceso de soluciones de software.

Análisis de escenarios para la reutilización

Existen al menos 4 escenarios en los que un proyecto de software requerirá elementos de reutilización.

• El proyecto es similar a un anterior (reutilización de un proyecto existente).
• Mismo proyecto con configuración diferente (reutilizan productos actuales)
• Características de uso basados en productos existentes
• Nueva Arquitectura con capacidades o elementos existentes.