¿No sabes por dónde empezar? Ayúdanos normalizando artículos.
¿Tienes experiencia? Crea alguno de estos artículos de actualidad.

Proceso de Desarrollo de Software

{Definición

nombre=Procesos de Desarrollo del Software

imagen=

tamaño=

concepto=un conjunto coherente de políticas, estructuras organizacionales, tecnologías, procedimientos y artefactos que son necesarios para concebir, desarrollar, instalar y mantener un producto software. }


Características de los Procesos Software

Un PS es "un conjunto coherente de políticas, estructuras organizacionales, tecnologías, procedimientos y artefactos que son necesarios para concebir, desarrollar, instalar y mantener un producto software".
La naturaleza especial de los PS está determinada por las siguientes características:
                                           

a) Son complejos. b) No son procesos de producción típicos, ya que están dirigidos por excepciones, ven muy determinados por circunstancias impredecibles y cada uno tiene peculiaridades que lo distinguen de los demás. c) Tampoco son procesos de ingeniería'pura', ya que se desconocen las abstracciones adecuadas (no existe una ciencia experimental en la que apoyarse), dependen demasiado de demasiada gente, el diseño y laproducción no están claramente diferenciados, y los presupuestos, calendarios y calidad no pueden ser planificados de forma suficientemente fiable.

d) No son (completamente) procesos creativos, ya que algunas partes pueden ser descritas en detalle y algunos procedimientos son impuestos previamente.
e) Están basados en descubrimientos que dependen de la comunicación, coordinación y cooperación dentro de marcos de trabajo predefinidos: los entregables generan nuevos requerimientos; los costes del cambio del software no suelen reconocerse; y el éxito depende de la implicación del usuario y de la coordinación de muchos roles (ventas, desarrollo técnico, cliente, etc.).
                                


Tipos de Procesos

En esta sección miramos a los dos tipos principales de procesos en uso por la ingenieria del software. Hay otros, pero son menos ampliamente usados. En años recientes ha habido tambien un movimiento para reducir el esfuerzo requerido en desarrollar software. Esto ha llevado al desarrollo de un numero de variantes ligeras de procesos (a menudo conocidas como computacion agil o programacion extrema) que son apropiadas para equipos muy pequeños de ingenieros.

El Proceso en Cascada

En este proceso, cada etapa del proceso-requerimientos, analisis y construccion (codigo y prueba) es completada antes que la siguiente comienze. Este es un proceso muy satisfactorio donde los requerimientos estan bien diseñados no se espera que cambien, por ejemplo automatizar un sistema manual bien probado. La debilidad de este enfoque se muestra problemas menos bien definidos. Invaliablemente algunas de las incertidumbres en los requerimientos no seran clarificados hasta bien entrado el analisis y el diseño, o incluso en fases de codificacion, requiriendo volver atras para rehacer trabajo. El peor aspecto de esto, es que no cuentas con codigo que funcione hasta cerca del final del proyecto, y muy a menudo es solo en esta etapa en la que los problemas con los requerimientos originales (por ejemplo con la interfaz de usuario) se hacen visibles. Esto esta exacerbado, por cada etapa sucesiva requiriendo mas esfuerzo que la anterior, asi que los costos del decubrimiento de un problema tardio son enormemente caros. El proceso en cascada es probablemente aún el proceso de diseño dominante. Sin embargo debido a sus limitaciones esta cada vez mas siendo sustituido por procesos iterativos, particularmente por proyectos donde los requerimientos nos están bien definidos.

Procesos de Desarrollo Iterativo

En años recientes un nuevo enfoque ha sido usado, el cual anima a conseguir al menos una parte del codigo funcionando tan pronto como sea posible, para conseguir descubrir problemas antes en el ciclo de desarrollo. Estos procesos usan unas series de "mini-cascadas", definiendo unos pocos requerimientos (los mas importantes) primero, llevandolos a traves del analisis, diseño y construcción para obtener una version temprana del producto, con funcionalidad limitada, relacionada con los requerimientos mas importantes. La retroalimentación de este código puede ser usada para refinar los requerimientos, apuntar problemas, etc antes de hacer mas trabajo. El proceso es entonces repetido para requerimientos adiciones para construir un producto con un paso mas en funcionalidad. Otra vez retroalimentación adicional puede ser aplicada a los requerimientos. El proceso es repetido, hasta que finalmente todos los requerimientos han sido implementados y el producto está completo. Es esta iteración lo que da a estos procesos su nombre. El crecimiento en popularidad de los procesos iterativos esta estrechamente unido a el crecimiento de OOA&D. Es el encapsulamiento limpio de objetos lo que permite a una parte del sistema ser contruida con trozos para el codigo restante claramente definidos.

El Proceso Racional Unificado

Quizas el Proceso Iterativo mejor conocido es el Proceso Racional Unificado (Rational Unified Process; RUP) de Rational Software Este proceso reconoce que nuestra vista piramidal de porciones iguales de la cascada no es realista. En la practica las iteraciones tempranas tienden a ser pesadas en los asuntos de requerimientos de cosas (necesitas definir una cantidad razonable incluso para comenzar), mientras las iteraciones posteriores tienen mas esfuerzo en las areas de diseño y construcción. RUP reconoce que las iteraciones pueden ser agrupadas en un numero de fases deacuerdo a su etapa en el proyecto global. Cada fase puede tener una o mas iteraciones. -En la fase del principio (inception phase) las iteraciones tienden a ser pesadas en asuntos de requerimientos/analisis, mientras que cualquier actividad de construcción debe estar limitada a la emulación del diseño dentro de una herramienta CASE. -En la fase de elaboración (elaboration phase) las iteraciones tienden a ser completar la especificación de los requerimientos, y comenzar a centrarse en el analisis y el diseño, y posiblemente la construcción del primer codigo real. -En la fase de construcción (construction phase) los requerimientos y analisis están mas o menos completos, y el esfuerzo de las iteraciones esta mayormente en diseño y construcción. -Finalmente, en la fase de desarrollo (deployment phase) las iteraciones están centradas sobre la actividad de la contrucción, y en particular la prueba del software.

fuentes