Lea esto Primero

SEMANA 2
Ingeniería de Software

Todos los derechos de autor son de la exclusiva propiedad de UNIACC o de los otorgantes de sus licencias. No está permitido
copiar, reproducir, reeditar, descargar, publicar, emitir, difundir, poner a disposición del público ni utilizar los contenidos
para fines comerciales de ninguna clase.
 Lea esto primero. UNIACC, semana 2

UNIVERSIDAD DE LAS COMUNICACIONES 1

 Lea esto primero. UNIACC, semana 2

CICLO CLÁSICO DEL DESARROLLO DE

SOFTWARE: CASCADA

Introducción

Todo modelo de desarrollo de software se divide en un conjunto de etapas

ordenadas bajo una secuencia lógica, la cual permite lograr objetivos parciales
que van agregando valor al gran objetivo final. Este proceso no tiene otro fin que el
de desarrollar un producto de software de alta calidad, es decir, con tendencia a
cero defectos y que satisfaga las necesidades del cliente. En general,
independientemente del tipo de modelo de desarrollo de software que se trate, las
etapas son: Especificación, Desarrollo, Validación y Evolución. Cada una de ellas
están ordenadas en diferentes secuencias, según el proceso de desarrollo que el
jefe de proyecto haya elegido para desarrollar el producto de software.

Así por ejemplo, en el modelo clásico de desarrollo en cascada, que es el modelo

en el que se profundizará en este documento, las etapas son ordenadas bajo una
lógica secuencial, mientras que en el modelo evolutivo están ordenadas en forma
intercalada (Pressman, 2003).

Para ordenar las etapas de un modelo de desarrollo en la aplicación específica de

un proceso de desarrollo, el jefe de proyecto debe considerar diversos criterios,
tales como: tipo de producto de software, la integración con otros productos de
software, el equipo de ingenieros de software que estarán a cargo del proyecto
(conocimiento y experiencia) y la estructura organizacional de la empresa. Por lo
tanto, es importante saber que los modelos de desarrollo de software no son ni
buenos ni malos, ni existe una configuración de etapas que sea correcta o
incorrecta; lo importante es que el jefe de proyecto, al iniciarlo, tenga la capacidad
de definir y ordenar el modelo de desarrollo en forma correcta para el proyecto

UNIVERSIDAD DE LAS COMUNICACIONES 2

 Lea esto primero. UNIACC, semana 2

específico que se debe obtener. El jefe de proyecto puede apoyarse en su equipo

de ingenieros para tomar las mejores decisiones.

A continuación, serán presentadas en detalle la etapas, en el orden en que se van

ejecutando, del modelo clásico de desarrollo: cascada, el cual considera como
etapas fundamentales: requerimientos, análisis y diseño, implementación,
verificación y validación y evolución. Estas etapas son ejecutadas en forma
secuencial e independiente, que poco a poco van agregando valor en la
construcción de un producto de software determinado.

I. Disciplinas del Desarrollo de

Software

a. Requerimientos

La ingeniería de requerimientos es la disciplina del proceso de desarrollo de

software que tiene por objetivo establecer y mantener acuerdos entre: el cliente, el
usuario final y el equipo de ingeniería a cargo del desarrollo. Lo que se busca es
llegar a acuerdos respecto de las solicitudes de cambio a partir de los
requerimientos que requiere el sistema. La etapa de requerimientos se encarga
de: elicitar, organizar, y documentar los requerimientos. También se debe
identificar las restricciones asociadas al producto de software y al proyecto en sí
mismo. Los requerimientos son considerados un factor de éxito en el proceso de
desarrollo del software, donde un buen conjunto de requerimientos son la base
para un buen desarrollo del producto de software. Los requerimientos permiten
validar en forma temprana si se está desarrollando el producto correcto, lo cual es
importante porque los errores que se generen en esta etapa del desarrollo, van a
generar defectos en sus etapas posteriores (Sommerville, 2002).

UNIVERSIDAD DE LAS COMUNICACIONES 3

 Lea esto primero. UNIACC, semana 2

La siguiente figura presenta el proceso que se debe desarrollar para lograr los
objetivos de la ingeniería de requerimientos. El producto de trabajo esperado, al
desarrollar las actividades asociadas a los requerimientos, es el documento de
Especificación de Requerimientos de Software, que se elabora en dos niveles de
abstracción: los requerimientos o características de sistema, que se enfocan en
las necesidades de los usuarios finales; y de los clientes, los cuales necesitan una
definición de requerimientos de alto nivel. Por otra parte, los requerimientos de
software (funcionales y no funcionales), que se enfocan en el equipo técnico del
proyecto, es decir, los desarrolladores del sistema, son los cuales necesitan una
especificación de más bajo nivel, es decir, con más nivel de detalle.

Fig. 1. Proceso de Ingeniería de Requerimientos.

Fuente: Sommerville (2002, p. 130).

Tal como se observa en la figura, la ingeniería de requerimientos considera cuatro

grandes actividades (Sommerville, 2002):

UNIVERSIDAD DE LAS COMUNICACIONES 4

 Lea esto primero. UNIACC, semana 2

En esta actividad, se evalúa si las necesidades expresadas por el usuario se

pueden satisfacer considerando diversos puntos de vista: técnico, tiempo,
costos, legales, ambientales, etc. El resultado deberá brindar información para
determinar si es factible dar continuidad al proyecto.

Estudio de viabilidad
1
Consiste en recopilar los requerimientos del sistema a través de la aplicación de
técnicas de recolección de información, tales como: entrevistas con los
involucrados (cliente-usuario), focus group, lluvia de ideas, encuestas, entre
otras. Estas, permitirán determinar: las necesidades que se deben satisfacer,
analizar los procesos de negocio del cliente, observar sistemas existentes, etc.
Todo lo anterior, implica documentar los requerimientos en un conjunto de
documentos, modelos y prototipos del sistema, con los cuales se busca ayudar a
comprender el sistema a desarrollar.

2
Obtención (elicitación) y análisis de requerimientos

Esta actividad consiste en detallar los requerimientos a partir de la información

obtenida y los modelos desarrollados durante la elicitación y análisis de los
requerimientos. El resultado será un documento que contiene la especificación de
los requerimientos con gran nivel de detalle, divididos en dos grandes tipos de
requerimientos: funcionales y no funcionales. En este documento, se incluyen
dos tipos de requerimientos: los requerimientos o características del sistema o
características, que definen los requerimientos del cliente y de los usuarios; y los
requerimientos del software, que son la descripción más detallada de la
funcionalidad y los atributos de calidad del sistema.

Especificación de requerimientos
3
UNIVERSIDAD DE LAS COMUNICACIONES 5
 Lea esto primero. UNIACC, semana 2

En esta actividad, determina la correctitud, coherencia, consistencia y completitud

de los requerimientos, a través de la aplicación de técnicas de revisión. El
objetivo fundamental es descubrir defectos en los requerimientos, con el fin de
corregirlos en forma temprana y así evitar la propagación de defectos en las
etapas posteriores del proceso de desarrollo.

4
Validación de requerimientos

Es importante destacar que las actividades asociadas a los requerimientos se

llevan a cabo a lo largo de todo el proceso de desarrollo, dado que lo normal es
que surjan nuevos requerimientos o se realicen peticiones de cambio en los
requerimientos iniciales.

b. Análisis y diseño

El proceso de análisis y diseño implica la transformación de la especificación de

requerimientos del sistema en un modelo de diseño, que incluye diferentes vistas
integradas en modelos de análisis y diseño, y que representan abstracciones de la
solución del sistema, incluyendo la arquitectura del mismo. El resultado final es el
documento denominado: especificación de la arquitectura de software.

El diseño de software es la descripción de la estructura del producto, la cual

considera elementos tales como capas, componentes e interfaces, y las relaciones
entre estos elementos. También se debe modelar los datos que se van a
manipular con el sistema, y en algunos casos de los procesos que se van a
ejecutar (Sommerville, 2002).

El análisis y diseño se desarrolla de manera iterativa e incremental, en dos

grandes etapas. La primera es el análisis y diseño de alto nivel y la segunda es el
análisis y diseño detallado. El proceso de diseño se documentará a través de la

UNIVERSIDAD DE LAS COMUNICACIONES 6

 Lea esto primero. UNIACC, semana 2

generación de un conjunto de modelos que representan la arquitectura de

software.

El conjunto de modelos, representan el sistema en diferentes vistas con niveles de

abstracción. Esta descomposición del sistema en varios modelos de análisis y
diseño, permite identificar defectos que quedaron de la etapa anterior, lo cual
permite a su vez mejorar la especificación de los requerimientos, así como
también los modelos de análisis y diseño. La siguiente figura representa dicho
proceso de análisis y diseño.

Fig. 2. Modelo general del proceso de análisis y diseño.

Fuente: Sommerville (2002, p.210).

Las actividades propias del proceso de análisis y diseño son:

 Arquitectura del sistema: aquí se identifican y documentan los

subsistemas y capas que estructuran el sistema, así como sus relaciones.

 Especificación abstracta: esta actividad consiste en especificar los

servicios y las restricciones de funcionamiento para cada subsistema y capa
que conformarán el producto de software.

UNIVERSIDAD DE LAS COMUNICACIONES 7

 Lea esto primero. UNIACC, semana 2

 Diseño de Interfaces: esta actividad radica en diseñar y documentar, para

cada subsistema, la interfaz de comunicación con los otros subsistemas. La
especificación de interfaces permite que el subsistema se diseñe sin
necesidad de conocer los detalles de su implementación interna.

 Diseño de Componentes: esta actividad permite determinar los servicios

que ofrecen los componentes (son los elementos básicos para la creación
de los subsistemas y capas). También se diseñan las interfaces a través de
las cuales prestan sus servicios.

 Diseño del Modelo de dato: esta actividad consiste en detallar y

especificar el modelo de datos que será utilizado en el sistema, para
gestionar los datos que se manipularán durante la operación del producto
de software.

 Diseño de los Algoritmos: a través de esta actividad se detallan y

especifican los procesos utilizados para proveer los servicios.

Las actividades descritas, son un modelo genérico del proceso de análisis y

diseño. En la realidad, cada empresa debe configurarlo de diversas maneras, de
acuerdo a sus propias necesidades.

c. Implementación

La implementación del producto de software es el proceso por el cual se

transforma la arquitectura del sistema en un código ejecutable. El desarrollo del
código ejecutable (programa) que implementa el sistema debe respetar y ceñirse
al diseño de la arquitectura.

Ahora bien, dependiendo del tipo de aplicación, es posible que sea necesario
tener el diseño detallado antes de iniciar la implementación. Sin embargo, es muy
frecuente que el diseño y la implementación se traten de actividades intercaladas.

UNIVERSIDAD DE LAS COMUNICACIONES 8

 Lea esto primero. UNIACC, semana 2

Una buena práctica para respetar el diseño, al pasar a la implementación, es

utilizar herramientas CASE que generen código automático a partir del diseño, y
que incluye código de definición de clases e interfaces, a partir de los cuales el
desarrollador implementa los detalles de funcionamiento (por ejemplo: Enterprise
Architect, StartUML, Poseidon, ArgoUML, BoUML, etc). Algunas herramientas de
última generación logran generar código con funcionalidades ya implementadas
(por ejemplo: Genexus) (Sommerville, 2002).

La estrategia de programación es una decisión del jefe de proyecto y su equipo de

ingenieros, donde no existe una regla general y única que deba aplicarse. Algunos
programadores prefieren desarrollar primero los componentes que les resultan
más fáciles, debido a que tienen mayor conocimiento y experiencia en ellos; para
luego desarrollar los componentes que les resultan más complejos. Otros, en
cambio, prefieren lo contrario, es decir, dejan los componentes más fáciles para
desarrollarlos al final, y así poder enfrentar en forma temprana los riesgos más
complejos del proyecto. Algunos programadores prefieren iniciar definiendo el
modelo de datos, otros prefieren dejar los datos en forma abstracta.

Después de haber terminado el proceso de implementación, los programadores

deben realizar algunas pruebas al código que desarrollaron (clásicamente son
conocidas como pruebas de caja blanca). Este proceso de prueba se denomina
depuración, cuyo objetivo es encontrar posibles defectos en el código y así
corregirlos antes de liberar los componentes de software. Es necesario aclarar que
las pruebas y la depuración son procesos con objetivos diferentes. Las pruebas se
realizan para encontrar defectos, mientras que la depuración se enfoca en
encontrar la causa del defecto para así poder corregirlo.

La siguiente figura presenta las actividades de la depuración. Primero se localizan

las causas de los defectos en el código, y luego se modifica el código para cumplir
con los requerimientos. Es importante anotar que después de todo el proceso de
depuración, es necesario repetir el ciclo de pruebas completo para asegurar que
los cambios son correctos y el sistema ha quedado completamente estable.

UNIVERSIDAD DE LAS COMUNICACIONES 9

 Lea esto primero. UNIACC, semana 2

Fig. 3. El proceso de depuración.

Fuente: Sommerville (2002, p.280).

d. Verificación y validación

La verificación y validación son procesos para determinar que el producto de

software cumple con la especificación de los requerimientos y que satisface las
necesidades del cliente - usuario. La verificación, considera procesos de
comprobación, que permiten determinar si se está desarrollando correctamente el
producto. Por, ejemplo: revisión informal, revisión semi-formal (walkthroughs),
revisión formal o inspección, pruebas de código, etc., los cuales son aplicados
durante las diferentes etapas del proceso de desarrollo. Por otra parte, la
validación implica la participación del cliente - usuario en un conjunto de pruebas
que le permiten comprobar que se está desarrollando el producto correcto, de tal
manera que le agregará valor al cliente en su contexto (Sommerville, 2002).

El producto de software no se prueba como un todo, excepto que sea muy simple
y pequeño. La siguiente figura presenta los detalles de la secuencia del proceso
de pruebas: pruebas unitarias, pruebas de integración, pruebas de sistema, y
pruebas de aceptación (estas últimas se realizan en el ambiente del cliente).

UNIVERSIDAD DE LAS COMUNICACIONES 10

 Lea esto primero. UNIACC, semana 2

Fig. 4. El proceso de pruebas.

Fuente: Sommerville (2002, p.291).

Las etapas del proceso de pruebas son las siguientes:

Pruebas unitarias.

Se prueban los componentes en forma individual para

determinar que funcionan correctamente. Los componentes
pueden ser: desde elementos simples, tales como funciones o
clases; o pueden ser elementos de mayor jerarquía,
compuestos por elementos simples.

Pruebas de integración.

Se prueban las interfaces de comunicación entre los

componentes individuales, para garantizar que la integración
entre ellos funciona correctamente.

Pruebas del sistema.

Se integran todos los componentes para conformar el

producto final. El objetivo de la prueba del sistema es el de
verificar que el sistema cumple con los requerimientos
funcionales y no funcionales, particularmente estos últimos,
dado que representan los atributos de calidad del sistema. Si
el sistema es muy grande o complejo, este proceso se
desarrolla en forma iterativa e incremental, es decir, se
integran los componentes para conformar subsistemas que
son probados en forma independiente antes de su integración
al producto final.

UNIVERSIDAD DE LAS COMUNICACIONES 11

 Lea esto primero. UNIACC, semana 2

Pruebas de aceptación.

Es la última etapa del proceso de pruebas, donde el cliente

valida y acepta que el sistema funciona correctamente y
satisface sus necesidades. Las pruebas se hacen en el
ambiente del cliente, con infraestructura y datos reales, es
decir, en condiciones idénticas al ambiente que se utilizará
cuando el sistema entre en producción.

Es importante considerar que cuando se ha desarrollado un sistema a pedido, se

realizan pruebas Alfa. Estas pruebas se realizan en el ambiente del cliente, con el
acompañamiento de la empresa de desarrollo; y terminan cuando el equipo de
desarrollo y el cliente están de acuerdo con que el sistema ha llegado a una
implementación aceptable y satisface las necesidades del cliente. Por otra parte,
cuando el sistema es un producto de software que se va a comercializar, se
realizan pruebas Beta. En este caso, se libera el producto y se entrega a un
número particular de clientes potenciales que quieran utilizarlo. La idea es que al
utilizarlo, los clientes informen de los problemas encontrados en el sistema. Esta
exposición del producto a usuarios reales, permite detectar los defectos no
identificados por los desarrolladores del sistema. Finalmente, con la
retroalimentación, el sistema se actualiza y se libera para más pruebas beta o para
comercializar la versión definitiva (típicamente conocida como versión estable).

El proceso de pruebas dependerá del modelo de desarrollo elegido. Por ejemplo,

si se utiliza un modelo en espiral o evolutivo, se deberá probar cada producto de
software entregable. Por otra parte, una buena práctica en ingeniería del software
es diseñar las pruebas junto con la especificación de requerimientos,
precisamente antes de iniciar el desarrollo. Esta práctica permitirá a los
programadores e ingenieros de prueba comprender los requerimientos y enfocar la
implementación considerando las pruebas.

UNIVERSIDAD DE LAS COMUNICACIONES 12

 Lea esto primero. UNIACC, semana 2

El proceso de prueba debe planificarse para que se desarrolle desde de la

especificación de requerimientos y el diseño del sistema. La siguiente figura
presenta la planificación de las pruebas como elemento vinculante entre las
actividades propias de las pruebas y del desarrollo.

Fig. 5. Las fases de prueba en el proceso de software.

Fuente: Sommerville, (2002, p. 307).

e. Evolución del software

Entre los atributos de calidad más importantes asociados a la evolución de los

sistemas software, se encuentran la flexibilidad y la mantenibilidad. Estos atributos
facilitan la adaptación fácil y rápida de los sistemas de software, permitiendo la
integración y evolución de sistemas grandes y complejos.

La figura siguiente presenta el proceso de adaptación de un sistema, reflejando su

evolución en el tiempo (Sommerville, 2002).

UNIVERSIDAD DE LAS COMUNICACIONES 13

 Lea esto primero. UNIACC, semana 2

Fig. 6. Evolución del sistema.

Fuente: Sommerville, (2002, p. 343).

En esencia, existe una separación de aspectos entre el proceso de creación

(desarrollo) y el proceso evolutivo del producto de software (mantenimiento). El
desarrollo de software es una actividad creativa que se inicia con el desarrollo
conceptual, a partir del cual se realizan una serie de transformaciones a modelos
hasta que se libera el producto de software para que entre en producción en el
ambiente del cliente. El mantenimiento del producto de software es el proceso de
modificar el producto de software debido a la: corrección de defectos, cambios a
petición del cliente, etc.

El éxito del proceso de mantenimiento dependerá del conjunto de buenas

prácticas aplicadas en el proceso de desarrollo, es decir, si el proceso de
desarrollo fue caótico e inmaduro, entonces el mantenimiento será muy
complicado, pero si el proceso de desarrollo fue ordenado y disciplinado, entonces
el mantenimiento será mucho más fácil.

La distinción entre desarrollo y mantenimiento es cada día más difusa. En la

actualidad, son muy pocos sistemas de software que se desarrollan
completamente desde cero, ya que la gran mayoría parte de la base de
componentes existentes que se integran, lo cual implica que el desarrollo y el

UNIVERSIDAD DE LAS COMUNICACIONES 14

 Lea esto primero. UNIACC, semana 2

mantenimiento sean vistos como actividades continuas, en constante evolución,

respondiendo adecuadamente a la dinámica de cambio de los requerimientos y
necesidades del usuario.

UNIVERSIDAD DE LAS COMUNICACIONES 15

 Lea esto primero. UNIACC, semana 2

Conclusión

El modelo clásico de desarrollo de software en cascada es un conjunto de etapas

organizadas lógicamente de manera secuencial e independiente, que tiene como
propósito obtener un producto de software. El ciclo de vida clásico considera las
etapas del proceso de desarrollo del producto de software.

Dicho modelo incluye etapas como son: requerimientos, análisis y diseño,

implementación, verificación y validación, y la evolución del producto de software.

Los requerimientos especifican el sistema, permiten comunicar las necesidades

del cliente al equipo de desarrollo y llegar a acuerdos con el cliente.

El análisis y diseño, en conjunto con la implementación, realizan la transformación

de los requerimientos (requerimientos de sistema y requerimientos de software) a
un producto de software de alta calidad, es decir, que sea con tendencia a cero
defectos.

La verificación y validación del sistema determinan que se cumpla con los

requerimientos (verificación) y que a su vez se satisfaga las necesidades de los
usuarios y agregue valor al contexto y procesos de negocio del cliente (validación).

Todo producto de software tiene un ciclo de vida que involucra mantenimiento,

dado por la evolución del producto de software.

El producto de software evoluciona, siendo necesario modificar, adaptar o

configurar sus componentes, para considerar cambios en los requerimientos o la
inclusión de unos nuevos.

UNIVERSIDAD DE LAS COMUNICACIONES 16

 Lea esto primero. UNIACC, semana 2

Referencias Bibliográficas

Pressman, R. (2003). Ingeniería del software: un enfoque práctico.. México:

McGraw-Hill.

Piattini, M. (2000). Análisis y diseño detallado de aplicaciones informáticas de

gestión. México: Alfaomega.

Sommerville, I. (2002). Ingeniería de Software.. México: Pearson. Addison Wesley.

Si usted desea referenciar este documento, considere:

UNIACC (2015). Ciclo de vida del desarrollo de Software: Cascada. Ingeniería de

Software. Lea esto primero (Semana 2).

UNIVERSIDAD DE LAS COMUNICACIONES 17

 Lea esto primero. UNIACC, semana 2

UNIVERSIDAD DE LAS COMUNICACIONES 18

 Lea esto primero. UNIACC, semana 2

Todos los derechos de autor son de la exclusiva propiedad de UNIACC o de los otorgantes de sus licencias. No está permitido
UNIVERSIDAD
copiar, reproducir, reeditar, descargar, publicar, DE LAS
emitir, COMUNICACIONES
difundir, poner a disposición del público ni utilizar los contenidos 19
para fines comerciales de ninguna clase.