PDF de programación - El proceso para el desarrollo de Software

Weitzenfeld: Capítulo 3



1



3 El Proceso para el Desarrollo de Software
Un proceso está definido como una serie de acciones u operaciones que conducen a un fin. En general, una empresa
u organización requiere de uno o más procesos para lograr sus objetivos, los cuales por lo general involucran la
utilización de sistemas de software. En el caso de una empresa que se dedica al desarrollo de software, se requieren
procesos que abarquen desde la creación de un sistema de software hasta su mantenimiento. Todo esto es conocido
como el ciclo de vida del software. Como hemos visto en el Capítulo 1, el desarrollo de sistemas de software es algo
muy complejo. ¡De lo contrario todos haríamos siempre software perfecto! Un aspecto básico para manejar la
complejidad inherente en los sistemas de software es contar con un modelo de proceso a seguir, como se discutirá en
el resto del capítulo.

3.1 Modelo del Proceso
El modelo de proceso define un orden para llevar a cabo los distintos aspectos del proceso. El modelo se puede
definir como un grupo de estrategias, actividades, métodos y tareas, que se organizan para lograr un conjunto de
metas y objetivos. El modelo de proceso abarca aspectos como la planeación, autoridad, predicción, evaluación y
rastreabilidad (“traceability”).
?? La planeación involucra definir cómo se llevarán a cabo las diversas etapas del proceso sin limitarse a aspectos

de desarrollo si no también por ejemplo, los organizacionales.

?? La autoridad define cómo se puede influir para llegar a donde se quiere.
?? La predicción describe a donde se va a llegar.
?? La evaluación describe donde se encuentra el proceso actualmente.
?? La rastreabilidad describe cómo se logró un resultado particular.
En particular, el proceso de desarrollo es considerado como un conjunto de personas, estructuras organizacionales,
reglas, políticas, actividades, componentes de software, metodologías y herramientas usadas o creadas
específicamente para conceptualizar, desarrollar, ofrecer un servicio, innovar o extender un producto de software, es
decir la forma en que la organización realiza sus distintos proyectos de generación de software.
Los modelos de proceso varían mucho entre sí y dependen de las diversas opiniones o máximas generales en las
cuales se basan [Goldberg & Rubin 1995], donde obviamente cada persona puede tener una opinión distinta al
respecto. Por ejemplo algunas creencias en el desarrollo de software son:
?? Es mejor comprender el problema antes de desarrollar una solución.
?? El proceso para resolver un problema debe dar un resultado predecible, sin importar del individuo que hace el

trabajo.

?? Debe ser posible planear y calcular el proceso con gran precisión.
?? Evaluar y administrar el riesgo es importante para el éxito del proceso.
?? Etapas bien definidas con entregas intermedias aumentan la confianza que se tiene en el resultado final.
En general, todas las creencias luego actúan como base para definir las estrategias, actividades, métodos, y tareas
del modelo de proceso. Estos conceptos se describen a continuación.
?? Una estrategia es un plan para llevar a cabo un objetivo, en nuestro caso el desarrollo de software. Existen

diversas estrategias para lograr mejor calidad en el software final. Una estrategia básica se relaciona con el tipo
de arquitectura que se desea crear, por ejemplo, utilizando elementos sencillos como bloques y componentes o
como elementos prefabricados de más alto nivel. Esta arquitectura puede incluso integrar diversos niveles de
sofisticación en los elementos. Las estrategias básicas escogidas afectan directamente el tipo de programación y
los lenguajes que se utilizarán. En cierta manera, para este libro ya hemos definido nuestra estrategia básica de
desarrollo de software, la cual es el uso de tecnología orientada a objetos, en particular usando el lenguaje Java.
Sin embargo, aún dentro esta estrategia de orientación a objetos puede refinarse aún mas. (Obviamente, se
puede utilizar una estrategia distinta, incluso que no sea orientada a objetos.) La estrategia no sólo afecta la
arquitectura del sistema sino tambien cómo se llevarán a cabo las actividades del proceso. Mientras no se tengan
conflictos, es posible combinar múltiples estrategias, donde las distintas actividades del proceso de software
pueden hacerse bajo estrategias diferentes, definiendo implícitamente la estrategia global del modelo de
proceso. Dos estrategias importantes son el uso de prototipos y reutilización. Hablaremos de esto más adelante.
?? Una actividad es una unidad o paso organizacional para llevar a cabo cierto aspecto de un proceso. En nuestro

caso las actividades definen los distintos pasos necesarios para lograr las metas y objetivos definidos en el
modelo de proceso, o sea en el desarrollo de software. Las actividades dependen de la arquitectura de software y
deben ser simples de aprender y usar; deben simplificar la comprensión del sistema, deben ser suficientemente

Weitzenfeld: Capítulo 3



2



poderosas para expresar la información requerida para modelar el sistema, deben ser lo suficientemente
descriptivas para poder discutir el sistema sin ambigüedades y deben proveer un modelo evolucionable del
sistema. Las actividades básicas necesarias para el proceso de desarrollo de software son las siguientes: (i)
requisitos para capturar los aspectos funcionales correspondientes, cómo un usuario interactuaría con el sistema;
(ii) análisis para dar al sistema una estructura robusta y extensible bajo un ambiente de implementación ideal;
(iii) diseño para adoptar y refinar las estructuras al ambiente de implementación particular; (iv) implementación
para codificar el sistema; (v) pruebas para validar y verificar el sistema; (vi) integración para pegar
componentes del sistema; (vii) documentación para describir los distintos aspectos el sistema y (viii)
mantenimiento para extender la funcionalidad del sistema.

?? Un método es un procedimiento definiendo las tareas que deben llevarse a cabo para satisfacer la actividad.

Existen métodos, por ejemplo, para asegurar la calidad del software, seguir el progreso del proyecto y probar el
software. Durante el análisis, el método debe ayudar en la identificación de los objetos necesarios para la
arquitectura del sistema. Análisis estructurado y análisis orientado a objetos son ejemplos de diferentes métodos
para hacer análisis, cada uno con sus propias tareas. Una metodología se refiere al estudio de los métodos,
existiendo un gran número de metodologías para el desarrollo de software. En general, distintas metodologías
llevan a cabo las actividades del desarrollo de software de diferente manera. En este libro buscamos aplicar las
metodologías más evolucionadas utilizando tecnología orientada a objetos. En el apéndice del libro
contrastaremos algunas de estas metodologías.

?? Una tarea es un grupo relacionado de acciones contribuyendo a una acción mayor. Cada método define un

conjunto de tareas a llevarse a cabo para lograr los objetivos deseados. La tarea puede incluir condiciones de
entrada y de salida que serán satisfechas antes y después de su realización.

Existen procesos de acuerdo al tipo de proyecto como se verá en la Sección 3.1.1 y aunque no hay límite a los
diversos modelos de proceso que puedan existir, describiremos los más “clásicos”: el Modelo de Cascada en la
sección 3.1.2 y el Modelo de Espiral en la sección 3.1.3. Cada uno de estos modelos de proceso está definido con un
propósito particular y posee distintas estrategias para especificar las diferentes actividades, métodos y tareas. El
tema de la madurez del modelo será tratada en la sección 3.1.4.

3.1.1 Procesos Adaptados a Tipos de Proyectos
Una creencia común pero equivocada en la industria del software es que hay un sólo modelo de proceso que sirve
para todo tipo de proyecto basados en tecnología orientada a objetos. En general, el modelo de proceso depende del
tipo particular de proyecto que se esté llevando a cabo. Algunos de estos tipos de proyectos son:
?? Primer proyecto de su tipo, donde se va a crear la mayoría del software desde cero, aunque obviamente se
pueden aprovechar componentes genéricos para su desarrollo. Por ser la primera vez que se crea este tipo de
software, se requiere más tiempo para analizar el dominio del problema que para otros proyectos. Incluso
aunque el dominio del problema sea familiar pudiera ser ésta la primera versión de un sistema de software de
este tipo. En un primer proyecto en su tipo, la incertidumbre crea riesgos adicionales.

?? Segundo proyecto en su tipo, donde se busca agregar nueva funcionalidad a un proyecto conocido. El

desarrollador típicamente tiende a excederse agregando demasiada funcionalidad en comparación al proyecto
anterior (“featuritis”). El sistema se vuelve muchos más grande que el original significando retrasos en el
sistema, como ocurre con muchos de los paquetes comerciales de la actualidad.

?? Variación de un proyecto, donde se extiende un sistema ya existente. Esto puede involucrar introducir

componentes de software reutilizables como un marco (“framework”), crear nuevos componentes o
simplemente extender la aplicación existente mediante nueva funcionalidad. Dependiendo de la estrategia
particular, el modelo de proceso debe variar. Por lo general, el riesgo en este tipo de proyectos es mucho menor
que en los primeros proyectos de su tipo. Lo que se debe hacer ya está definido por la naturaleza del software
existente, sin embargo se debe comprender las nuevas extensiones en el software en especial si éstos involucran
componentes reutilizables.

?? Proyecto de reescritura de legado (“legacy”), donde se busca transformar o hacer una “reingeniería” de un

sistema ya existente desarrollado bajo tecnologías anteriores, a un sistema desarrollado bajo nuevas tecnologías,
tales como las orientadas a ob