INGENIERÍA DE SOFTWARE

UNIDAD Nº I
Procesos de desarrollo del sofware bajo el enfoque clásico.

1
 SEMANA 1

Introducción

La asignatura pretende proveer una visión general de la ingeniería del software, poniendo
especial acento en las fases de especificación y de diseño. Se pretende que al terminar la
asignatura el alumno sea capaz de especificar un sistema sencillo mediante la notación
UML y de diseñarlo usando la misma notación y aplicando el patrón arquitectónico domain
model y alguno de los patrones de diseño más conocido.
En esta área, se adscriben diversas disciplinas técnicas y metodologías que dicen relación
con las actividades relaconadas con la fabricación de software y su gestión, presentadas
desde el punto de vista de la ingeniería.

La asignatura propiamente tal, es de introducción al tema y presenta las ideas relaconadas

con el producto de software en sí.

2
 Ideas Fuerza

• Entender el concepto de Ciclo de vida del desarrollo de un software

considerando los principales modelos de proceso o paradigmas de ciclo de vida
del software

• Entender el concepto de Ciclo de vida del desarrollo Clásico de un software

considerando todas sus fases

• Aplicar algún método para Calcular la complejidad de un software, conforme a

alguna métrica

3
 Desarrollo

1. Ingeniería de software

1.1. Introducción a la Ingeniería de software

Los cursos previos a esta asignatura te han formado para operativizar y programar
sistemas informáticos. Este curso de Ingeniería de Software busca a que
desarrolles las competencias para implementar dichas soluciones de software, a
través de la sistematización del proceso de desarrollo y mantenimiento.

Bien, iniciaremos el contenido dando el contexto a la Ingeniería de software para

que internalices la importancia de ella en tu formación profesional como Ingeniero
Informático.

1.2. Definiciones para Ingeniería de software

Con objeto de elaborar software listo para enfrentar los retos del siglo XXI, se hace
necesario aceptar algunas realidades sencillas [1]:

• El software se ha incrustado profundamente en casi todos los aspectos de

nuestras vidas y, como consecuencia, el número de personas que tienen
interés en las características y funciones que brinda una aplicación específica
ha crecido en forma notable. Cuando ha de construirse una aplicación nueva
o sistema incrustado, deben escucharse muchas opiniones. Y en ocasiones
parece que cada una de ellas tiene una idea un poco distinta de cuáles
características y funciones debiera tener el software. Se concluye que debe
hacerse un esfuerzo concertado para entender el problema antes de
desarrollar una aplicación de software.
• Los requerimientos de la tecnología de la información que demandan los
individuos, negocios y gobiernos se hacen más complejos con cada año que
pasa. En la actualidad, grandes equipos de personas crean programas de
cómputo que antes eran elaborados por un solo individuo. El software
sofisticado, que alguna vez se implementó en un ambiente de cómputo
predecible y autocontenido, hoy en día se halla incrustado en el interior de
todo, desde la electrónica de consumo hasta dispositivos médicos o sistemas
de armamento. La complejidad de estos nuevos sistemas y productos

4
 basados en computadora demanda atención cuidadosa a las interacciones
de todos los elementos del sistema. Se concluye que el diseño se ha vuelto
una actividad crucial.
• Los individuos, negocios y gobiernos dependen cada vez más del software
para tomar decisiones estratégicas y tácticas, así como para sus operaciones
y control cotidianos. Si el software falla, las personas y empresas grandes
pueden experimentar desde un inconveniente menor hasta fallas
catastróficas. Se concluye que el software debe tener alta calidad.
• A medida que aumenta el valor percibido de una aplicación específica se
incrementa la probabilidad de que su base de usuarios y longevidad también
crezcan. Conforme se extienda su base de usuarios y el tiempo de uso, las
demandas para adaptarla y mejorarla también crecerán. Se concluye que el
software debe tener facilidad para recibir mantenimiento.

Estas realidades simples llevan a una conclusión: debe hacerse ingeniería

con el software en todas sus formas y a través de todos sus dominios de
aplicación. Y esto conduce al tema de este curso: la ingeniería de software.

Es muy probable que ya sabes que existen muchas definiciones para

Ingeniería de software con diversos autores y que por cierto aún no se tiene
una definición única, sin embargo, acá van al menos cuatro de ellas.

1. Ingeniería de software es el estudio de los principios y metodologías para el

desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)

2. Ingeniería de software es la aplicación práctica del conocimiento científico al

diseño y construcción de programas de computadora y a la documentación
asociada requerida para desarrollar, operar y mantenerlos. Se conoce
también como desarrollo de software o producción de software (Bohem,
1976).

3. Ingeniería de software trata del establecimiento de los principios y métodos

de la ingeniería a fin de obtener software de modo rentable, que sea fiable y
trabaje en máquinas reales (Bauer, 1972).

4. Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al

desarrollo, operación y mantenimiento del software; es decir, la aplicación
de la ingeniería al software (IEEE, 1993).

5
La ingeniería de software es una tecnología con varias capas. Como se aprecia en
la figura 1, cualquier enfoque de ingeniería (incluso la de software) debe basarse
en un compromiso organizacional con la calidad.

Figura 1 – Capas de la Ingeniería de software Roger S. Pressman

6
Compromiso con La administración total de la calidad, Six Sigma y otras
la calidad: filosofías similares alimentan la cultura de mejora continua, y
es esta cultura la que lleva en última instancia al desarrollo de
enfoques cada vez más eficaces de la ingeniería de software.
El fundamento en el que se apoya la ingeniería de software
es el compromiso con la calidad.

Proceso: El fundamento para la ingeniería de software es la capa

proceso. El proceso de ingeniería de software es el
aglutinante que une las capas de la tecnología y permite el
desarrollo racional y oportuno del software de cómputo. El
proceso define una estructura que debe establecerse para la
obtención eficaz de tecnología de ingeniería de software. El
proceso de software forma la base para el control de la
administración de proyectos de software, y establece el
contexto en el que se aplican métodos técnicos, se generan
productos del trabajo (modelos, documentos, datos, reportes,
formatos, etc.), se establecen puntos de referencia, se
asegura la calidad y se administra el cambio de manera
apropiada.

Métodos: Los métodos de la ingeniería de software proporcionan la

experiencia técnica para elaborar software. Incluyen un
conjunto amplio de tareas, como comunicación, análisis de
los requerimientos, modelación del diseño, construcción del
programa, pruebas y apoyo. Los métodos de la ingeniería de
software se basan en un conjunto de principios
fundamentales que gobiernan cada área de la tecnología e
incluyen actividades de modelación y otras técnicas
descriptivas.

7
 Las herramientas de la ingeniería de software proporcionan
Herramientas: un apoyo automatizado o semiautomatizado para el proceso
y los métodos. Cuando se integran las herramientas de modo
que la información creada por una pueda ser utilizada por
otra, queda establecido un sistema

2. Ciclo de vida de un software

El desarrollo de programas corresponde a un proceso creativo, de igual modo el

“desarrollo de un software” es un proceso propiamente creativo y la “ingeniería del
software” busca sistematizar este proceso, con el objeto de disminuir el riesgo del
fracaso en la obtención del software, haciendo uso de diversas técnicas y
métodos.

Entonces digamos que la Ingeniería de software es como la ingeniería aplicada al

software, esto es, la aplicación de metodologías y modelos para llevar a cabo el
proceso de desarrollo de software, con el uso de herramientas preestablecidas,
con ello se busca la obtención de un software de calidad.

Cuando hablamos de calidad, podemos estar refiriéndonos a cuán mantenible es

el software, el costo, el tamaño, su estabilidad, comprobabilidad, velocidad,
usabilidad, legibilidad, seguridad y número de fallas, entre otros atributos, a
cualidades menos medibles como elegancia, precisión y satisfacción del
cliente. Para conseguir esto es que los Ingenieros de software busquen construir
software adoptando algún enfoque sistemático y organizado en su trabajo, ya que
es la forma más efectiva de conseguir software de calidad; de ahí la finalidad de
este curso en tu formación de Ingeniero Informático.

2.1. Fases del Ciclo de vida de un software

El Proceso de desarrollo de software es el conjunto estructurado de las

actividades requeridas para realizar un sistema de software. Estas actividades o
fases son:
• Análisis
• Diseño
• Programación (Codificación)
• Pruebas (Validación) y
• Mantenimiento.

8
 Al proceso de desarrollo de software también se le conoce como ciclo de vida del
software porque describe la vida de un producto de software; primero nace con la
especificación de los requerimientos, luego se lleva a cabo su implantación, que
consiste en su diseño, codificación y validación, posteriormente el producto se
entrega y sigue viviendo durante su utilización y mantenimiento. En este ciclo se
establece una comunicación interactiva entre cliente y desarrollador en la que el
primero solicita servicios y el segundo propone soluciones. El ciclo de vida del
sistema de software termina cuando éste se deja de utilizar.

Especificación de
Explotación y
Requerimientos__ ________________Implantación___________________
__Mantenimiento_
Análisis Diseño Programación Pruebas Manteni-
miento

Figura 2: Fases del Ciclo de vida del desarrollo de un software1

1
Fuente propia

9
Análisis: También llamada Especificación de requisitos. Se definen los
requisitos del software; debe quedar claro qué tiene que hacer el
software para satisfacer las necesidades del cliente ( o de
usuarios).
Diseño: Se define cómo da respuesta el software a lo que se tiene que
hacer, definido en la etapa anterior. El cómo depende en arte de
qué tecnología (lenguaje, plataforma…) se escoja para la
implementación posterior del sistema (por ejemplo el diseño varía
según si se opta por utilizar una base de datos relacional o un
sistema de ficheros para guardar los datos que el software tiene
que gestionar)..
Programación: O Codificación, se implementa el diseño previo
Pruebas: Se verifica el buen funcionamiento de cada componente del
software aisladamente (pruebas unitarias) y en interacción con el
resto de los componentes (pruebas de integración).
Mantenimiento: Se ocupa de los cambios en el software causados por errores,
peticiones de mejoras solicitadas por el cliente o simplemente por
variaciones en elementos externos (como cambios del sistema
operativo o del sistema gestos de la base de datos) que obliga a
hacer una adaptación del software desarrollado.

2.2. Modelos de Ciclo de vida de un software (proceso de desarrollo de

software)

El proceso para el desarrollo de software también denominado ciclo de vida del

desarrollo de software, se define como una estructura para las actividades,
acciones y tareas que se requieren a fin de construir software de alta calidad. Un
modelo de desarrollo de software determina el orden en el que se llevan a cabo
las actividades del proceso de desarrollo de software, es decir, es el procedimiento
que se sigue durante el proceso. Al modelo de desarrollo también se le llama
paradigma del proceso.

10
Lo que tienes que saber de los Modelos de desarrollo de software

• Son una representación abstracta del proceso de desarrollar software

• El modelo puede ser modificado y adaptado de acuerdo a las necesidades del
software en proceso de desarrollo
• Cada modelo cuenta con pros y contras
• Se selecciona aquel modelo más apropiado a las necesidades del proyecto a
desarrollar
• Pueden combinarse los modelos

11
2.2.1. Modelo de Ciclo de vida en cascada (lineal secuencial)

Análisis
Diseño
Codificación

Pruebas
Manteni-
miento

Ventajas Desventajas
• Introduce el concepto de • La mayoría de los ciclos propuestos
interactividad son inviables
• Introduce el concepto de iteración
Figura 3: Ciclo de vida en cascada

2.2.2. Modelo de Ciclo de vida Lineal Incremental

Explota-
Codifica- ción y
Análisis Diseño Pruebas
ción Manteni
-miento

Explota-
Codifica- ción y
Análisis Diseño Pruebas
ción Manteni
-miento

Explota-
Codifica- ción y
Análisis Diseño Pruebas
ción Manteni
-miento

Figura 4: Ciclo de vida Lineal incremental

Ventajas Desventajas
• Introduce el concepto de • Escasa capacidad para absorber el
incrementalidad concepto de prototipo
• Más flexible que el Lineal • Evidencia cierta ineficiencia en la
Secuencial utilización de los recursos

12
2.2.3. Modelo de Ciclo de vida de Desarrollo Rápido (RAD)
Modelado
Equipo del Negocio Modelado
Modelado de
de Datos Prototipo de
1 Aplicaciones
Aplicaciones Desarrollo de Implantación y
Aplicaciones Pruebas

Modelado
Equipo del Negocio Modelado
Modelado de
de Datos Prototipo de
2 Aplicaciones
Aplicaciones Desarrollo de Implantación y
Aplicaciones Pruebas

Modelado
Equipo del Negocio Modelado
Modelado de
de Datos Prototipo de
3 Aplicaciones
Aplicaciones Desarrollo de Implantación y
Aplicaciones Pruebas

Figura 5: Ciclo de vida de Desarrollo rápido

Ventajas Desventajas
• Incremento significativo de la • Tentación de no alcanzar
productividad niveles de robustez y
• Compatible con métodos más confiabilidad aceptable
sofisticados y potentes que los
métodos estructurados

2.2.4. Modelo de Ciclo de vida Espiral

Proyecto de desarrollo de
conceptos

Proyecto de desarrollo de
nuevos productos

Proyecto de mejora de
productos

Proyecto de mantenimiento
de productos
Figura 6: Ciclo de vida Espiral

13
Ventajas Desventajas
• Como el software evoluciona a • Resulta difícil convencer a
medida que progresa el proceso, el grandes clientes de que el
desarrollador y el cliente enfoque evolutivo es controlable.
comprenden y reaccionan mejor ante • Debido a su elevada complejidad
riesgos en cada nivel evolutivo no se aconseja utilizarlo en
• Demanda una consideración directa pequeños sistemas.
de los riesgos técnicos en las etapas • Requiere experiencia en la
del proyecto y si se aplica identificación de riesgos
adecuadamente reduce los riesgos
antes de convertirse en problemas.

14
2.2.5. Modelo de Ciclo de vida de Proceso Unificado (UP)

Inicio Elaboraci Construcción Transición

ón
Flujos principales de
trabajo
Modelamiento del
negocio
Requerimientos

Análisis y Diseño

Implementación
Pruebas
Despliegue

Flujos de apoyo al
trabajo
Configuración y cambios
Administración del
proyecto
Ambiente
Figura 7: Ciclo de Proceso unificado

Ventajas Desventajas
• Reducción de riesgos en el • Requiere una gran previsión sobre lo
proyecto que va a ocurrir (para poder
• La garantía de calidad, y controlarlo)
• La integración entre lo que es • Genera abundante trabajo adicional
propiamente desarrollo con de documentación y comunicación,
mantenimiento de software por tanto no es práctico para
proyectos pequeños

15
2.3. Metodología y modelos de proceso de desarrollo de software

Mucha es la confusión que podemos encontrar en diversos documentos que dan

cuenta de Metodologías y Modelos de Procesos de desarrollo del software, ello
debido a que son documentos tipo ensayo, opiniones en blog, trabajos de algunos
cursos y en ocasiones trabajos desarrollados en cursos de pregrados que no han
tenido la revisión experta antes de ser divulgados. Acá encontrarás una aclaración
de ellos, de manera que puedas distinguir la diferencia entre Metodología y
Modelo de Proceso, además conocerás los factores a considerar para decidir una
Metodología adecuada para llevar a cabo el proceso de desarrollo de un software.

Algunas definiciones para Metodología de desarrollo de software:

Gacitúa (2003): Plantea que una metodología impone un proceso de forma

disciplinada sobre el desarrollo de software con el objetivo de
hacerlo más predecible y eficiente. Una Metodología define una
representación que permite facilitar la manipulación de
modelos, y la comunicación e intercambio de información entre
todas las partes involucradas en la construcción de un sistema,
para que sea un proyecto exitoso.

Goncalves (2005) Plantea que la experiencia ha demostrado que los proyectos

exitosos son aquellos que son administrados siguiendo una
serie de procesos que permiten organizar y luego controlar el
proyecto, considerando válido destacar que aquellos procesos
que no sigan estos lineamientos corren un alto riesgo de
fracasar. Es necesario destacar la importancia de los métodos,
pero el éxito del proyecto depende más de la comunicación
efectiva con los interesados, el manejo de las expectativas y las
personas que participan en el proyecto.

Someerville (2005), Menciona que Metodología de desarrollo de software es un

enfoque estructurado para el desarrollo de software que incluye
modelos de sistemas, notaciones, reglas, sugerencias de
diseño y guías de procesos.

El diccionario RAE: Diccionario de la Real Academia Española define a la

Metodología como "la ciencia del método" y a método como el
"modo de decir o hacer con orden una cosa" y también como el
"modo de obrar o proceder".

16
La Metodología normalmente consistirá en un conjunto de fases, descompuestas
en sub-fases (en base a un modelo de desarrollo de software). Esta
descomposición guía a los desarrolladores en la elección de las técnicas que se
deben elegir para cada estado del proyecto.

Hoy en día frente a necesidades de adaptarse a una industria de software, donde

prevalece atender necesidades de rapidez de construcción del software y
dinamismo de las necesidades ha llevado a una gran categorización de las
metodologías de desarrollo de softwares, ellas son: Metodologías Pesada
(tradicionales o estructuradas) y las Metodologías Ágiles. Bajo dicha clasificación
nos introduciremos en su estudio, así podrás identificar cual se adapta de manera
más eficiente a un proyecto determinado.

Las Metodologías Tradicionales: Toman este nombre pues siguen un marco de

disciplina estricto y un proceso de aplicación riguroso.
Exige una fuerte cantidad de documentación del
desarrollo del software.

Las Metodologías Ágiles: Su nombre lo toma debido a que son usadas para
atender a problemas que requieren de una respuesta
ágil en un ambiente flexible y con cambios constantes,
y donde la documentación es la mínima indispensable.

Desarrollar un software involucra un proceso en donde se recopila información y

genera interacción entre usuarios, desarrolladores, herramientas cambiantes y en
evolución. Es un proceso que se repite generando un avance del software, dicho
avance sirve como medio para la comunicación: con cada nueva ronda del diálogo
se genera más conocimiento útil a partir de las personas involucradas, la que se
utiliza para una siguiente iteración.

Roger S. Pressman define al “proceso del software” como una estructura para las
actividades, acciones y tareas que se requieren a fin de construir software de alta
calidad.
En el contexto de la ingeniería de software, un proceso no es una prescripción
rígida de cómo elaborar software de cómputo. Por el contrario, es un enfoque
adaptable que permite que las personas que hacen el trabajo (el equipo de
software) busquen y elijan el conjunto apropiado de acciones y tareas para el
trabajo. Se busca siempre entregar el software en forma oportuna y con calidad
suficiente para satisfacer a quienes patrocinaron su creación y a aquellos que lo
usarán.

17
Revisión de modelos de desarrollo

A continuación (ver la figura 8) se presenta una clasificación de los modelos y

metodologías concretos más citados en la literatura en cuatro clases abstractas:
Cascada, Evolutivos, Híbridos y Ágiles. Se ha dividido en Modelos Tradicionales
(también llamados pesados), que son los que promueven la disciplina por medio
de la planificación y la comunicación escrita, y los Metodologías Ágiles, que dan
prioridad a la interacción entre los individuos y a la comunicación con el cliente.

18
TABLA COMPARATIVA ENTRE MODELOS DE PROCESOS PESADOS Y ÁGILES PARA DESARROLLAR SOFTWARE
Modelos abstractos Modelos concretos Modelo del Modelo cuándo Algunas
proceso usarlo Metodologías
asociadas al
Modelo
En cascada • Pura Proceso • Grandes • Clásica
Modelos • Con fases realizado en proyectos de • Estructurada
Tradicional solapadas fases software • Otras
es o • Con secuenciale • Requisitos
Pesados subproyectos s que se estables
Metodologías:
• Con reducción pueden • Hay experiencia
Estos • Clásica superponer
de riesgos en el modelo
• Estructurada
modelos • Hay experiencia
promueven • Otras
en la
la disciplina Metodología
por medio • Alto nivel
de la documentación
planificació
Evolutivos • Espiral Proceso • Grandes • Prototipo
n y la
• Entrega por desarrolla proyectos de • Espiral
comunicaci
etapas o un modelo software • Diseño rápido de
ón escrita
incremental (prototipo) • Requisitos poco aplicaciones
• Entrega evolutiva que permite claros al inicio • IWEB
o iterativo ver la • Incursiona en • OOHDM
• Cascada en V funcionalida nuevas • OMT, OMT++
• Componentes d básica de experiencias • Otras
Reutilizables la misma
Híbridos • Proceso Proceso que • Pequeños • RUP

19
 Unificado implica el equipos • UP
Racional desarrollo • Medianos y • Otras
• Otros iterativo y la pequeños
construcción proyectos
de • Requisitos que
prototipos pueden cambiar
Modelos Ágiles • Programación • Incursiona en • XP
Estos modelos dan prioridad a la interacción extrema nuevas • SCRUM
entre los individuos y a la comunicación con el • Desarrollo experiencias • CRYSTAL
cliente dirigido por • Otras
pruebas
• Desarrollo
dirigido por
Características
• Agile, Lean, …,
etc.
figura 8. Clasificación de los modelos y metodologías concretos más citados en la literatura2

2
Fuente propia

20
2.4. ¿Qué hay que saber para decidir una metodología de desarrollo de
software?

En el momento de adoptar un estándar o construir una metodología, se han de

considerar unos requisitos deseables, por lo que seguidamente se proponen una serie
de criterios de evaluación de dichos requisitos.
• La metodología debe ajustarse a los objetivos. Cada aproximación al
desarrollo de software está basada en unos objetivos. Por ello la metodología
que se elija debe recoger el aspecto filosófico de la aproximación deseada, es
decir que los objetivos generales del desarrollo deben estar implementados en la
metodología de desarrollo.
• La metodología debe integrar las distintas fases del ciclo de desarrollo
Trazabilidad. Es importante poder moverse no sólo hacia adelante en el ciclo de
vida, sino hacia atrás de forma que se pueda comprobar el trabajo realizado y se
puedan efectuar correcciones.
• La metodología debe incluir la realización de validaciones. La metodología
debe detectar y corregir los errores cuanto antes. Uno de los problemas más
frecuentes y costosos es el aplazamiento de la detección y corrección de
problemas en las etapas finales del proyecto. Cuanto más tarde sea detectado el
error más caro será corregirlo. Por lo tanto, cada fase del proceso de desarrollo
de software deberá incluir una actividad de validación explícita.
• La metodología debe soportar la determinación de la exactitud del sistema
a través del ciclo de desarrollo. La exactitud del sistema implica muchos
asuntos, incluyendo la correspondencia entre el sistema y sus especificaciones,
así como que el sistema cumple con las necesidades del usuario. Por ejemplo,
los métodos usados para análisis y especificación del sistema deberían
colaborar a terminar con el problema del entendimiento entre los informáticos,
los usuarios y otras partes implicadas. Esto implica una comunicación entre
usuario y técnico amigable y sencillo, exento de consideraciones técnicas.
• La metodología debe ser la base de una comunicación efectiva. Debe ser
posible gestionar a los informáticos, y éstos deben ser capaces de trabajar
conjuntamente. Ha de haber una comunicación efectiva entre analistas,
programadores, usuarios y gestores, con pasos bien definidos para realizar
progresos visibles durante la actividad del desarrollo.
• La metodología debe funcionar en un entorno dinámico orientado al
usuario. A lo largo de todo el ciclo de vida del desarrollo se debe producir una
transferencia de conocimientos hacia el usuario. La clave del éxito es que todas
las partes implicadas han de intercambiar información libremente. La
participación del usuario es de importancia vital debido a que sus necesidades
evolucionan constantemente. Por otra parte, la adquisición de conocimientos del

www.iplacex.cl
 usuario la permitirá la toma de decisiones correctas. Para involucrar al usuario
en el análisis, diseño y administración de datos, es aconsejable el empleo de
técnicas estructuradas lo más sencillas posible. Para esto, es esencial contar
una buena técnica de diagramación.
• La metodología debe especificar claramente los responsables de
resultados. Debe especificar claramente quienes son los participantes de cada
tarea a desarrollar, debe detallar de una manera clara los resultados de los que
serán responsables.
• La metodología debe servir para sistemas de distinta complejidad, es decir
puede abarcar un departamento, varios de departamentos o varias empresas.
Entorno. La metodología debe servir con independencia de la tecnología
disponible en la empresa.

3. Ciclo de vida del desarrollo Clásico

Hay veces en las que los requerimientos para cierto problema se comprenden bien:
cuando el trabajo desde la comunicación hasta el despliegue fluye en forma
razonablemente lineal. Esta situación se encuentra en ocasiones cuando deben
hacerse adaptaciones o mejoras bien definidas a un sistema ya existente (por ejemplo,
una adaptación para software de contabilidad que es obligatorio hacer debido a
cambios en las regulaciones gubernamentales). También ocurre en cierto número
limitado de nuevos esfuerzos de desarrollo, pero sólo cuando los requerimientos están
bien definidos y tienen una estabilidad razonable.

3.1. ¿Qué es el ciclo de vida de desarrollo clásico?

El ciclo de vida clásico, también llamado modelo de la cascada, sugiere un enfoque

sistemático y secuencial para el desarrollo del software, que comienza con la
especificación de los requerimientos por parte del cliente y avanza a través de
planeación, modelado, construcción y despliegue, para concluir con el apoyo del
software terminado (véase la figura 8).

Comunicaci
ón Planeación
Inicio del Estimación
proyecto recabar programación Modelado
los seguimiento Análisis Construcci
requerimientos diseño ón Despliegue
Código Entrega
pruebas Asistencia
retroalimentació
n

22 www.iplacex.cl
Figura 8. Ciclo de vida clásico

3.2. Fases del ciclo de vida clásico

La estructura del proceso establece el fundamento para el proceso completo de la

ingeniería de software por medio de la identificación de un número pequeño de
actividades estructurales que sean aplicables a todos los proyectos de software, sin
importar su tamaño o complejidad.

Una estructura de proceso general para la ingeniería de software consta de cinco

actividades o fases:

1. Fase Comunicación. Antes de que comience cualquier trabajo técnico, tiene

importancia crítica comunicarse y colaborar con el cliente (y con otros
participantes). Se busca entender los objetivos de los participantes respecto del
proyecto, y reunir los requerimientos que ayuden a definir las características y
funciones del software.
Es entender el problema. En ocasiones es difícil de admitir, pero la mayor parte
de nosotros adoptamos una actitud de orgullo desmedido cuando se nos
presenta un problema. Escuchamos por unos segundos y después pensamos:
Claro, sí, entiendo, resolvamos esto. Desafortunadamente, entender no siempre
es fácil. Es conveniente dedicar un poco de tiempo a responder algunas
preguntas sencillas:
• ¿Quiénes tienen que ver con la solución del problema? Es decir, ¿quiénes
son los participantes?
• ¿Cuáles son las incógnitas? ¿Cuáles datos, funciones y características se
requieren para resolver el problema en forma apropiada?
• ¿Puede fraccionarse el problema? ¿Es posible representarlo con problemas
más pequeños que sean más fáciles de entender?
• ¿Es posible representar gráficamente el problema? ¿Puede crearse un
modelo de análisis?

2. Fase Planeación. Cualquier viaje complicado se simplifica si existe un mapa.

Un proyecto de software es un viaje difícil, y la actividad de planeación crea un
“mapa” que guía al equipo mientras viaja. El mapa —llamado plan del proyecto
de software— define el trabajo de ingeniería de software al describir las tareas
técnicas por realizar, los riesgos probables, los recursos que se requieren, los
productos del trabajo que se obtendrán y una programación de las actividades.
23 www.iplacex.cl
 Planear la solución. Ahora entiende el problema (o es lo que piensa) y no puede
esperar para escribir el código. Antes de hacerlo, cálmese un poco y haga un
pequeño diseño:
• ¿Ha visto antes problemas similares? ¿Hay patrones reconocibles en una
solución potencial? ¿Hay algún software existente que implemente los datos,
funciones y características que se requieren?
• ¿Ha resuelto un problema similar? Si es así, ¿son reutilizables los elementos
de la solución?
• ¿Pueden definirse problemas más pequeños? Si así fuera, ¿hay soluciones
evidentes para estos?
• ¿Es capaz de representar una solución en una forma que lleve a su
implementación eficaz?
• ¿Es posible crear un modelo del diseño?

3. Fase Modelado. Ya sea usted diseñador de paisaje, constructor de puentes,

ingeniero aeronáutico, carpintero o arquitecto, a diario trabaja con modelos. Crea
un “bosquejo” del objeto por hacer a fin de entender el panorama general —
cómo se verá arquitectónicamente, cómo ajustan entre sí las partes
constituyentes y muchas características más—. Si se requiere, refina el
bosquejo con más y más detalles en un esfuerzo por comprender mejor el
problema y cómo resolverlo. Un ingeniero de software hace lo mismo al crear
modelos a fin de entender mejor los requerimientos del software y el diseño que
los satisfará.

4. Fase Construcción. Esta actividad combina la generación de código (ya

sea manual o automatizada) y las pruebas que se requieren para descubrir
errores en éste.
Ejecutar el plan. El diseño que creó sirve como un mapa de carreteras para el
sistema que quiere construir. Puede haber desviaciones inesperadas y es
posible que descubra un camino mejor a medida que avanza, pero el “plan” le
permitirá proceder sin que se pierda.
• ¿Se ajusta la solución al plan?
• ¿El código fuente puede apegarse al modelo del diseño?
• ¿Es probable que cada parte componente de la solución sea correcta?
• ¿El diseño y código se han revisado o, mejor aún, se han hecho pruebas
respecto de la corrección del algoritmo?

24 www.iplacex.cl
 5. Fase Despliegue. El software (como entidad completa o como un incremento
parcialmente terminado) se entrega al consumidor que lo evalúa y que le da
retroalimentación, misma que se basa en dicha evaluación.
Examinar el resultado. No se puede estar seguro de que la solución sea
perfecta, pero sí de que se ha diseñado un número suficiente de pruebas para
descubrir tantos errores como sea posible.
• ¿Puede probarse cada parte componente de la solución?
• ¿Se ha implementado una estrategia razonable para hacer pruebas?
• ¿La solución produce resultados que se apegan a los datos, funciones y
características que se requieren?
• ¿El software se ha validado contra todos los requerimientos de los
participantes?

Estas cinco actividades estructurales genéricas se usan durante el desarrollo de

programas pequeños y sencillos, en la creación de aplicaciones web grandes y en la
ingeniería de sistemas enormes y complejos basados en computadoras. Los detalles
del proceso de software serán distintos en cada caso, pero las actividades estructurales
son las mismas.

Una variante de la representación del modelo de la cascada se denomina modelo en V.

En la figura 9 se ilustra el modelo en V, donde se aprecia la relación entre las acciones
para el aseguramiento de la calidad y aquellas asociadas con la comunicación,
modelado y construcción temprana.

A medida que el equipo de software avanza hacia abajo desde el lado izquierdo de la
V, los requerimientos básicos del problema mejoran hacia representaciones técnicas
cada vez más detalladas del problema y de su solución. Una vez que se ha generado el
código, el equipo sube por el lado derecho de la V, y en esencia ejecuta una serie de
pruebas (acciones para asegurar la calidad) que validan cada uno de los modelos
creados cuando el equipo fue hacia abajo por el lado izquierdo. En realidad, no hay
diferencias fundamentales entre el ciclo de vida clásico y el modelo en V. Este último
proporciona una forma de visualizar el modo de aplicación de las acciones de
verificación y validación al trabajo de ingeniería inicial.

25 www.iplacex.cl
 Modelado de los Pruebas de
requerimientos aceptación

Diseño de la
Diseño de la arquitectura
arquitectura

Diseño de los Diseño de los

componentes componentes

Generación de Generación de
código código

Software
ejecutable

Figura 9. Ciclo de vida clásico

El modelo de la cascada es el paradigma más antiguo de la ingeniería de software. Sin

embargo, en las últimas tres décadas, las críticas hechas al modelo han ocasionado
que incluso sus defensores más obstinados cuestionen su eficacia [Han95]. Entre los
problemas que en ocasiones surgen al aplicar el modelo de la cascada se encuentran
los siguientes:

1. Es raro que los proyectos reales sigan el flujo secuencial propuesto por el
modelo. Aunque el modelo lineal acepta repeticiones, lo hace en forma indirecta.
Como resultado, los cambios generan confusión conforme el equipo del proyecto
avanza.
2. A menudo, es difícil para el cliente enunciar en forma explícita todos los
requerimientos. El modelo de la cascada necesita que se haga y tiene
dificultades para aceptar la incertidumbre natural que existe al principio de
muchos proyectos.
3. El cliente debe tener paciencia. No se dispondrá de una versión funcional del(de
los) programa(s) hasta que el proyecto esté muy avanzado. Un error grande
sería desastroso si se detectara hasta revisar el programa en funcionamiento.

26 www.iplacex.cl
En un análisis interesante de proyectos reales, Bradac [Bra94] encontró que la
naturaleza lineal del ciclo de vida clásico llega a “estados de bloqueo” en los que
ciertos miembros del equipo de proyecto deben esperar a otros a fin de terminar tareas
interdependientes. En realidad, ¡el tiempo de espera llega a superar al dedicado al
trabajo productivo! Los estados de bloqueo tienden a ocurrir más al principio y al final
de un proceso secuencial lineal. Hoy en día, el trabajo de software es acelerado y está
sujeto a una corriente sin fin de cambios (en las características, funciones y contenido
de información). El modelo de la cascada suele ser inapropiado para ese tipo de labor.
No obstante, sirve como un modelo de proceso útil en situaciones en las que los
requerimientos son fijos y el trabajo avanza en forma lineal hacia el final.

4. Cálculo de la complejidad del software

La complejidad del software podemos definirla a través de métricas, como volumen,

tamaño, anidaciones, costo (estimación), agregación, configuración, y flujo. Estos son
los puntos críticos de la concepción, viabilidad, análisis, y diseño de software.

Los 2 tipos de métrica principales3 para calcular la complejidad son:

• Complejidad ciclo matica de McCabe4
• Ciencia del Software de Halstead5

4.1. Complejidad ciclo matica de McCabe

La complejidad ciclo matica se basa en el recuento del número de caminos lógicos

individuales contenidos en un programa. Para calcular la complejidad del software,
Thomas McCabe [McCabe, 1976] utilizó la teoría y flujo de grafos. Para hallar la
complejidad ciclo matica, el programa se representa como un grafo, y cada instrucción
que contiene, un nodo del grafo. Las posibles vías de ejecución a partir de una
instrucción (nodo) se representan en el grafo como aristas.

Su éxito probablemente se deba, entre otras causas, a la gran facilidad con que se
calcula, a que su significado es intuitivamente sencillo de asimilar, y a que estudios

3 Fuente: https://www.quizover.com/course/section/ejemplo-de-calcular-la-complejidad-ciclomatica-by-openstax
4 Fuente: McCabe,T.J., y A.H. Watson, “Solftware Complexity”, Crosstalk.
5 Fuente: Halstead, M., “Elements of Software Science”, Holland.

27 www.iplacex.cl
sobre programas reales avalan su relación con el tiempo de desarrollo, la dificultad de
mantenimiento, etc.

Para calcularlo, supongamos que tenemos un grafo correspondiente al flujo de control

de un programa, con e arcos, n nodos.

El número ciclo matico puede entenderse como el número mínimo de caminos

necesario para, mediante combinaciones, construir cualquier otro camino presente en
el grafo. Utilizamos el término camino en el sentido usual, como una sucesión de nodos
que puede recorrerse siguiendo arcos presentes en el grafo. La complejidad ciclo
matica se puede calcular usando la fórmula:

v(G) = e - n + 2

Donde e representa el número de aristas y n el número de nodos.

La complejidad ciclo matica es una medición de software que proporciona una

evaluación cuantitativa de la complejidad lógica de un programa6.

6
Fuente: Ingeniería de software. Un enfoque práctico. Roger S. Pressman

28 www.iplacex.cl
A continuación,] se presenta un procedimiento que calcula el promedio de 100 o menos
números que se encuentran entre valores frontera; también calcula la suma y el
número total válido7.

1. i = 1; 1
2. total.input = total.valid = 0;
3. sum = 0;
2
4. DO WHILE value[i] <> –999 AND
total.input < 100
5. increment total.input by 1; 3
6. IF value[i] > = minimum AND value[i] < =
maximum 4
7. THEN increment total.valid by 1;
8. sum = s sum + value[i] 5
9. ELSE skip
ENDIF
6
10. increment i by 1;
ENDDO
11. IF total.valid > 0 7 9
12. THEN average = sum / total.valid
13. ELSE average = –999; 8
ENDIF
END average
Fin do
while

1
0

1
1

1 13
2

Fin

7
Fuente: Ingeniería de software. Un enfoque práctico. Roger S. Pressman

29 www.iplacex.cl
Si se realizase el grafo, se observaría que se encuentran 6 caminos posibles para
llegar de la sentencia 1 a la sentencia 13:

1. Camino 1: 1, 2, 3, 4, 10, 11, 12,fin

2. Camino 2: 1, 2, 3, 4, 10, 11, 13,fin
3. Camino 5: 1, 2, 3, 4, 5, 6, 9,10, 11, 12,fin
4. Camino 6: 1, 2, 3, 4, 5, 6, 9,10, 11, 13,fin
5. Camino 3: 1, 2, 3, 4, 5, 6, 7, 8,10, 11, 12,fin
6. Camino 4: 1, 2, 3, 4, 5, 6, 7, 8,10, 11, 13,fin

e = 17 aristas
n = 13 nodos (cantidad de instrucciones).
v(G)= 1

Reemplazando en v(G) = e - n + 2 tenemos:

v(G) = 17 - 13+ 2= 6 Este procedimiento tiene una complejidad ciclomática de
6.
Fuente: Fuente: Ingeniería de software. Un enfoque práctico. Roger S. Pressman

30 www.iplacex.cl
4.2. Ciencia del software de Halstead

Durante el final de los años 70 y principios de los 80, Maurice Halstead desarrolla un
conjunto de métricas llamadas Halstead Software Science, métricas basadas en el
cálculo de palabras clave (reservadas) y variables.
Su teoría está basada en una simple cuenta (muy fácil de automatizar) de operadores y
operandos en un programa:
• Los operadores son las palabras reservadas del lenguaje, tales como IF-THEN,
READ, FOR,...; los operadores aritméticos +, -, *,..... los de asignación y los
operadores lógicos AND, EQUAL TO,....
• Los operandos son las variables, literales y las constantes del programa.

Halstead distingue entre el número de operadores y operandos únicos y el número

total de operadores y operando. Por ejemplo, un programa puede tener un READ, siete
asignaciones y un WRITE; por lo tanto, tiene tres únicos operadores, pero nueve en
total operadores, y de manera idéntica se procede con los operandos. Se utiliza la
siguiente notación:
• n1 - número de operadores únicos que aparecen en un programa
• N1 - número total de ocurrencias de operadores
• n2 - número de operandos únicos que aparecen en un programa
• N2 - número total de ocurrencias de operandos

Las métricas de la Ciencia del Software para cualquier programa escrito en cualquier
lenguaje pueden ser derivadas de estas cuatro cuentas. A partir de ellas han sido
elaboradas diferentes medidas para diversas propiedades de los programas, tales
como longitud, volumen, etc...

Por ejemplo, consideremos el siguiente trozo de programa:

if (N<2){
A=B*N;
System.out.println("El resultado es : " + A);
}

A partir de aquí se deduce:

N2 = 6 (N, 2, A, B, N, A)
N1 = 6 (if, {}, system.out.println, =, *,<)
n2 = 4 (N, A, B, 2)
n1 = 6 (if, {}, system.out.println, =, *,<)

31 www.iplacex.cl
Medida de la longitud de un programa

Halstead permite obtener una medida de la longitud, N, de un programa, que es

calculada como:

N = N1 + N2

N es una simple medida del tamaño de un programa. Cuanto más grande sea el
tamaño de N, mayor será la dificultad para comprender el programa y mayor el
esfuerzo para mantenerlo. N es una medida alternativa al simple conteo de líneas de
código. Aunque es casi igual de fácil de calcular, N es más sensible a la complejidad
que el contar el número de líneas porque N no asume que todas las instrucciones son
igual de fácil o de difícil de entender.

Medida del volumen de un programa

La medida de longitud, N, es usada en otra estimación de tamaño de Halstead llamada

volumen. Mientras que la longitud es una simple cuenta (o estimación) del total de
operadores y operandos, el volumen da un peso extra al número de operadores y
operandos únicos. Por ejemplo, si dos programas tienen la misma longitud N pero uno
tiene mayor número de operadores y operandos únicos, que naturalmente lo hacen
más difícil de entender y mantener, este tendrá un mayor volumen. La fórmula es la
siguiente:

volumen V = N x log2(n)volumen V = N x log2(n)

donde n = n1 + n2n = n1 + n2

Medida del esfuerzo de un programa

El esfuerzo es otra medida estudiada por Halstead que ofrece una medida del trabajo
requerido para desarrollar un programa. Desde el punto de vista del mantenimiento, el
esfuerzo se puede interpretar como una medida del trabajo requerido para comprender
un software ya desarrollado.
La fórmula es la siguiente:

32 www.iplacex.cl
 E=VLE=VL

donde el volumen V es dividido por el nivel del

lenguaje L.

Éste indica si se está utilizando un lenguaje de alto o bajo nivel. Por ejemplo, una
simple llamada a un procedimiento podría tener un valor L de 1; el COBOL podría tener
0,1 y el ensamblador podría tener un L de 0,01. Así pues el esfuerzo aumenta
proporcionalmente con el volumen, pero decrece con la utilización de lenguajes de alto
nivel. Atendiendo a varios estudios empíricos, el esfuerzo, E, es incluso una medida
mejor de la entendibilidad (comprensión) que N.

Otras métricas de Halstead

1. Largo del Programa: N = N1 + N2

2. Tamaño del Vocabulario del programa: n = n1 + n2
3. Volumen del Programa: V = N * log2(n)
4. Nivel de Dificultad: D = (n1/2) * (N2/n2)
5. Nivel de Programa: L = 1/D
6. Esfuerzo de Implementación: E = V*D
7. Tiempo de Entendimiento: T = E/18 (18 es el número que Halstead encontró
experimentalmente para expresar esta magnitud en segundos)

33 www.iplacex.cl
Ejemplo para calcular las medidas de Halstead

Calcular las medidas de Halstead para el siguiente algoritmo:

if (N<2){
A=B*N;
System.out.println("El resultado es : " + A);
}

Operadores: Cantidad Operandos: Cantidad

1. If 1 1. N Cantidad
2. {} 1 2. A 2
3. system.out.print 1 3. B 2
ln 1 4. 2 1
4. = 1 1
5. * 1
6. <
Total N1 = Total n2 = 4 Total N2= 6
Total n1 = 6 6

La longitud es
N = N1 + N2 = 6 + 6 = 12

El Tamaño del Vocabulario del programa es

n = n1 + n2= 6 + 4 = 10

El volumen es
V = N x log2(n)= 12 x log2 (6+4)= 12 x 3,322= 39,864

El Nivel de Dificultad es
D = (n1/2) * (N2/n2)= (6/2) * (6/4)=3*1,5 = 4,5

El Nivel de Programa es
L = 1/D = 1/4,5 = 0,222

El Esfuerzo de Implementación es
E = V*D = 39,864* 4,5 = 179,388

El Tiempo de Entendimiento es
T = E/18 (18 es el número que Halstead encontró experimentalmente para

34 www.iplacex.cl
expresar esta magnitud en segundos) = 179,388/18 = 9,966

35 www.iplacex.cl
Bibliografía:
• [1] Ingeniería de software. Un enfoque práctico. Roger S. Pressman

36 www.iplacex.cl
 Conclusión

En el desarrollo de productos de software las etapas de análisis de requerimientos y

diseño toma gran parte del tiempo del proyecto. El modelo planteado en este proyecto
pretende establecer unos parámetros de diseño generales que permitan agilizar la
implementación de proyectos tipo sistemas de control por software, cuya base común
es el procesamiento de señales digitales en busca de comportamientos de interés
(caracterización de señales). La utilización de un ciclo de vida específico para el
desarrollo de software, 125 basado en las condiciones del tipo de problemas a tratar,
constituye uno de los alcances notables del modelo ofrecido. El ciclo de vida contempla
la noción de fases generales que constituyen un marco de situación, estableciendo
fases de solución para un subproblema concreto.

37 www.iplacex.cl
 Bibliografía
Modelo de madurez de ingeniería del software | Pino Correa, Francisco Javier |E-LIBRO

Ingeniería del software| Cabot Cabrera, Jordi|E-LIBRO

38 www.iplacex.cl
39 www.iplacex.cl