DISEÑO DE INGENIERÍA DE SOFTWARE

En las secciones anteriores, el diseño se presentó como un proceso sistemático e inteligente para
generar, evaluar y especificar diseños para dispositivos, sistemas o procesos. Para apoyar este proceso,
la habilidad de resolución de problemas se identificó como un ingrediente esencial para diseñar
productos complejos. Estas discusiones proporcionaron una perspectiva general sobre la importancia de
estos conceptos en la profesión de ingeniería. Al igual que en otras disciplinas de la ingeniería, el diseño
y la resolución de problemas son cruciales para el desarrollo de sistemas de software profesionales a
gran escala. Los sistemas de software son muy complejos, difíciles de crear, costosos de cambiar y,
según el producto de software, críticos para la seguridad humana. De manera similar a otras disciplinas
de ingeniería, los diseños en ingeniería de software se utilizan para identificar, evaluar y especificar las
características estructurales y de comportamiento de los sistemas de software que se adhieren a alguna
especificación. Los diseños de software proporcionan planos que capturan cómo los sistemas de
software cumplen con las funciones requeridas y cómo se configuran para cumplir con la calidad
prevista. Formalmente, el diseño de ingeniería de software se define como

(1) El proceso de identificar, evaluar, validar y especificar los modelos arquitectónicos, detallados y de
construcción necesarios para crear software que cumpla con los requisitos funcionales y no funcionales
previstos; y (2) el resultado de dicho proceso.

El término diseño de software se usa indistintamente en la práctica como un medio para describir tanto
el proceso como el producto del diseño de software. Desde una perspectiva de proceso, el diseño de
software se utiliza para identificar la fase, las actividades, las tareas y la interrelación entre ellas
necesarias para modelar la estructura y el comportamiento del software antes de que comience la
construcción. Desde una perspectiva de desarrollo de productos, el diseño de software se utiliza para
identificar los artefactos de diseño que resultan de la fase, las actividades y las tareas identificadas; por
lo tanto, estos productos por sí mismos, o en conjunto, se denominan diseño de software. Los productos
de diseño varían según varios factores, incluida la perspectiva del diseño, el lenguaje, el propósito y sus
capacidades de evaluación y análisis. Por ejemplo, los diseños pueden tener forma arquitectónica,
utilizando notaciones arquitectónicas dirigidas a partes interesadas específicas. Estos tipos de diseño se
pueden presentar mediante diagramas de bloques, diagramas de lenguaje de modelado unificado (UML)
u otra forma descriptiva de documentación de diseño de caja negra. En otros casos, el diseño puede ser
en forma detallada, donde se usa una representación más de caja blanca del sistema para modelar
aspectos estructurales y de comportamiento. Estos pueden incluir modelos de software que contienen
diagramas de clases, diagramas de objetos, diagramas de secuencia o diagramas de actividades. Otros
productos de diseño incluyen modelos que representan interfaces, datos o diseños de interfaz de
usuario. Debido a las muchas formas en que se usa el diseño de software en la práctica, un escollo
común en los proyectos de ingeniería de software es asociar el diseño con un tipo particular de artefacto
de diseño y, por lo tanto, descuidar otras formas de diseño o las actividades requeridas para crear
diseños de software completos y correctos. En conjunto, tanto el proceso como los productos, incluida
toda la variedad de productos de diseño, se consideran diseño de software y son esenciales en la
mayoría de los proyectos de software profesional.

¿POR QUÉ ESTUDIAR DISEÑO DE INGENIERÍA DE SOFTWARE?

El 25 de febrero de 1991, un error de software en el sistema de defensa antimisiles Patriot que operaba
durante la operación Tormenta del Desierto hizo que no pudiera rastrear e interceptar un Scud
entrante, lo que resultó en la muerte de 28 estadounidenses (GAO, 1992). En 1996, un error de software
hizo que el lanzamiento del satélite Ariane 501 fallara catastróficamente, lo que resultó en un costo
directo de aproximadamente $370 millones (Dowson 1997). El error de software que hizo que Ariane
501 fallara podría atribuirse a su diseño de software. De manera similar, la literatura está repleta de
muchos ejemplos de resultados desastrosos de productos basados en software. La razón de muchos de
estos desastres es que desarrollar software de alta calidad a tiempo y dentro del presupuesto es una
tarea abrumadora. Desde el principio, el panorama de los proyectos de desarrollo de software está
plagado de una variedad de desafíos que aumentan la complejidad de los proyectos de software. El
diseño de software juega un papel integral en la gestión de la complejidad y los desafíos que se
encuentran en cualquier esfuerzo de desarrollo de software.

Durante la fase de diseño del software, el sistema se descompone para permitir un desarrollo óptimo
del software; los requisitos se asignan a modelos conceptuales del software operativo; los roles se
asignan a equipos de software en el mismo sitio o en sitios remotos; se crean interfaces conocidas para
componentes de software; los atributos de calidad se abordan e incorporan en el diseño del sistema; se
crea la interfaz de usuario; se analiza la capacidad del software; se identifican los nombres de funciones
y variables; se establecen los objetivos de la documentación del diseño; y se establecen las bases para el
resto del ciclo de vida de la ingeniería de software. Dado su impacto en la creación y gestión de
productos de software, dominar el diseño de software se vuelve esencial para diseñar productos de
software con éxito. Las razones para estudiar el diseño de ingeniería de software se pueden describir
utilizando una perspectiva de desarrollo de productos y una perspectiva de gestión de proyectos.

Razones para estudiar diseño de software en el desarrollo de productos

Desde el punto de vista del desarrollo de productos, estudiar el diseño de software es importante
porque los diseños forman la base para todas las demás actividades de construcción de software. Los
diseños de software permiten a los ingenieros de software crear modelos que representan la estructura
y el comportamiento del sistema de software. A través de estos modelos se identifican los principales
componentes y su interconexión para la solución. Las características del código de calidad, como la
modularización, la cohesión y el acoplamiento, nacen en la fase de diseño. Para tareas complejas, las
abstracciones y la encapsulación se utilizan en el diseño de software como medios para proporcionar un
enfoque sistemático para la resolución de problemas. Además, los diseños de software son reutilizables;
por lo tanto, se pueden aplicar a diferentes proyectos para proporcionar soluciones listas para usar a
problemas comunes. El diseño de software también proporciona los medios para evaluar e incorporar
los atributos de calidad necesarios para los sistemas de software. Por lo tanto, los problemas como el
rendimiento, la facilidad de uso, la portabilidad y la seguridad pueden abordarse al principio del
proyecto de desarrollo. Estos beneficios se trasladan a todas las demás fases posteriores del ciclo de
vida del desarrollo de software y tienen un impacto directo en la fase de implementación, prueba y
mantenimiento.

Razones para estudiar Diseño de Software en Gestión de Proyectos

La gestión de proyectos de software caracterizados por requisitos cambiantes, cronogramas ajustados,
restricciones de costos y altas expectativas de calidad del software es difícil. Entre estos, los cambios en
los requisitos son impulsores comunes para todas las demás características del proyecto. Esto significa
que, a medida que cambian los requisitos, los proyectos deben esperar algún impacto en su costo,
cronograma y calidad. En algunos casos, los cambios en los requisitos pueden traducirse fácilmente en
cronogramas extendidos y mayores costos; en otros, donde los cronogramas no se extienden, los
cambios en los requisitos se traducen en una disminución de la calidad del software. Un buen diseño de
software puede minimizar (o contrarrestar) los efectos de la volatilidad de los requisitos en la gestión de
proyectos de software. Desde el punto de vista de la administración, el diseño del software es
importante porque ayuda a acomodar los cambios en los requisitos o las actualizaciones del sistema y,
por lo tanto, minimiza el impacto en el cronograma, el costo y la calidad. Además, un buen diseño de
software aumenta la eficiencia en las tareas de asignación de recursos humanos. Al descomponer el
software en unidades independientes, los recursos pueden asignarse a los componentes del software
para que puedan construirse en paralelo en el mismo sitio de construcción o en sitios diferentes, lo que
tiene un impacto significativo en los cronogramas y costos del software. Al compartimentar el diseño,
también se pueden minimizar los efectos de la deserción laboral no deseada (es decir, los empleados
que dejan la empresa), ya que los nuevos empleados solo necesitan asumir el componente de diseño
individual asignado a ese empleado. Los buenos diseños de software proporcionan un mapeo eficiente
de los requisitos del cliente a las soluciones de software, lo que facilita el seguimiento de los requisitos a
lo largo del diseño. Tener una sólida comprensión del diseño de software ayuda a la gerencia a abstraer
las tareas del proyecto y adquirir una mejor apreciación del trabajo a realizar. En general, tener una
sólida comprensión del diseño de software ayuda a la gerencia a mejorar la planificación, la
organización, la dotación de personal y el seguimiento del proyecto, y proporciona una guía general para
el proyecto.

DESAFÍOS DEL DISEÑO DE SOFTWARE

Hoy en día, la fase de diseño de software ha pasado de ser una fase ad hoc y, a veces, pasada por alto, a
una fase esencial del ciclo de vida del desarrollo. Además, la creciente complejidad de los sistemas
actuales ha creado una serie de desafíos particulares que dificultan que los ingenieros de software
satisfagan la continua demanda de los clientes de software de mayor calidad. Estos desafíos han llevado
a los ingenieros de software a prestar más atención al proceso de diseño para comprender, aplicar y
promulgar mejor los principios, procesos y prácticas profesionales de diseño bien conocidos para
superar estos desafíos. Algunos de los principales desafíos incluyen la volatilidad de los requisitos, el
proceso de diseño, los problemas de calidad (p. ej., rendimiento, usabilidad, seguridad), el desarrollo de
software distribuido, la asignación eficiente de recursos humanos a las tareas de desarrollo, los
presupuestos limitados, las expectativas y los cronogramas irrazonables, la velocidad -tecnología
cambiante y transformación precisa de un requisito de software a un producto de software. A
continuación se presenta una breve discusión de estos desafíos.

Desafío de diseño 1: Volatilidad de los requisitos

Una de las principales razones de la complejidad de los proyectos de software es el cambio constante de
requisitos. Cuando se diseña correctamente, el software se puede modificar o ampliar fácilmente; sin
embargo, cuando se diseña de manera deficiente, la modificación del software puede volverse
abrumadora y conducir a todo tipo de problemas complejos. A diferencia del desarrollo de hardware de
computadora, puentes, casas o partes mecánicas, la propia naturaleza del software se permite cambiar
para proporcionar una funcionalidad diferente o nueva a los sistemas. Este mismo rasgo que hace que el
software sea tan deseable es lo que lo hace también tan complejo. Aunque se pone mucho esfuerzo en
la fase de requisitos para asegurar que los requisitos sean completos y consistentes, ese rara vez es el
caso; dejando la fase de diseño de software como la más influyente a la hora de minimizar los efectos de
requisitos nuevos o cambiantes. La volatilidad de los requisitos es un desafío porque impactan los
esfuerzos de desarrollo futuros o actuales. Esto obliga a los diseñadores a crear diseños que brinden
soluciones a los problemas en un estado dado, al mismo tiempo que anticipan los cambios y los
acomodan con el mínimo esfuerzo. Esto requiere que los diseñadores tengan una sólida comprensión de
los principios del diseño de software y desarrollen habilidades para gestionar la complejidad y el cambio
en el desarrollo de software.

Desafío de diseño 2: proceso

La ingeniería de software es un campo orientado a procesos. Los procesos de software permiten a los
ingenieros organizar los pasos necesarios para desarrollar soluciones de software con limitaciones de
tiempo y costos. Por lo tanto, en el centro de toda empresa de desarrollo de software, debe haber un
proceso sólido, bien entendido y coherente para el desarrollo de software. Los procesos también se
pueden desarrollar y personalizar para fases particulares del ciclo de vida de la ingeniería de software.
En la fase de diseño, los procesos de software implican un amplio conjunto de actividades y tareas que
cierran la brecha entre los requisitos y la construcción mientras se adhieren a un conjunto de
restricciones específicas del proyecto (o de la empresa). Estas actividades incluyen las comunes, como el
diseño arquitectónico y detallado, así como otras actividades de apoyo. Estas actividades de apoyo
incluyen el establecimiento de un proceso de revisión del diseño, la definición de criterios de evaluación
de la calidad del diseño, la evaluación de la reutilización del diseño, el establecimiento de
procedimientos de gestión de cambios de diseño y control de versiones, la adopción de herramientas de
diseño y la asignación de recursos. En muchos casos, el proceso de diseño de una empresa no está bien
establecido, no se comprende bien o se aborda con expectativas minimalistas que ignoran aspectos que
son esenciales para ejecutar una fase de diseño exitosa. Centrar los esfuerzos de diseño en la creación
de productos de software independientes, como un diagrama de clase simple o una interfaz de usuario,
mientras se ignoran otras actividades de diseño puede crear complejidades más adelante durante la
prueba y el mantenimiento del sistema. El proceso de diseño es un desafío porque las actividades
esenciales del proceso de diseño a menudo se pasan por alto, se realizan de manera ad hoc o
simplemente no se realizan en absoluto. En muchos casos, un proceso de diseño bien establecido y bien
realizado sirve como indicador del éxito de un proyecto futuro.

Desafío de diseño 3: Tecnología

El software está destinado a estar en todas partes. Desde los sistemas de atención de la salud y la
educación hasta la defensa y los dispositivos ubicuos cotidianos, se requiere software para operar de
forma masiva y siempre.

panorama tecnológico en evolución. Además del entorno operativo, la tecnología para diseñar e
implementar los sistemas de software actuales continúa evolucionando para brindar capacidades
mejoradas. Ejemplos de estos incluyen lenguajes y herramientas de modelado, lenguajes de
programación, entornos de desarrollo, patrones de diseño y estrategias de diseño. A medida que surgen
nuevas tecnologías, los ingenieros de software deben asimilarlas y emplearlas todas al mismo tiempo.
En algunos casos, las tecnologías emergentes no reemplazan por completo a las antiguas. Se requiere
que algunos sistemas de software interoperen con sistemas heredados antiguos diseñados con
metodologías de diseño más antiguas. Esto da como resultado que los diseñadores de software empleen
diferentes metodologías y tecnologías de diseño, todas en el mismo sistema de software. En otros casos,
los modelos de diseño deben derivarse del código existente, modificarse y hacerse interoperables con
tecnologías más nuevas. Este aspecto de la fase de diseño impulsado por la tecnología crea una
demanda de diseñadores de software capaces que puedan asimilar la nueva tecnología de manera
rápida y efectiva para tener éxito en el diseño de software. El aspecto tecnológico del diseño de
software es desafiante porque es rápido y está en constante cambio; por lo tanto, los diseñadores
deben mantenerse al tanto de los últimos avances y dominar la aplicación de estos avances mientras se
mantienen arraigados en la tecnología heredada.

Desafío de Diseño 4: Prácticas Éticas y Profesionales

Los diseñadores crean planos que impulsan la construcción del software. Durante este proceso de
creación, los diseñadores deben determinar cómo las decisiones de diseño afectan el medio ambiente y
las personas que usan el software. En muchos casos, el proceso de desarrollo de software se lleva a cabo
tradicionalmente con limitaciones de tiempo muy estrictas. Inherentemente, todas las fases del ciclo de
vida del desarrollo sufren esto, incluida la fase de diseño. Esto crea presiones externas que pueden
llevar a los diseñadores a desviarse del enfoque de diseño normal para satisfacer estas demandas, lo
que puede tener consecuencias catastróficas. No importa cuán ajustados sean los plazos, cuánta
animosidad exista dentro del equipo de diseño o cuántos otros factores externos/personales se
incorporen a la fase de diseño, los diseñadores de software deben exhibir prácticas éticas y
profesionales sólidas para garantizar que los sistemas que construyen sean de la más alta calidad.
calidad y que todas las consideraciones de diseño se evalúen adecuadamente. En muchos casos, esto
requiere que los diseñadores ejerzan fuertes habilidades de liderazgo para influir y negociar con las
partes interesadas, motivar al equipo de diseño y liderar el proceso de diseño para lograr las metas del
proyecto. Los diseñadores también son responsables de hacer cumplir las pautas éticas durante el
proceso de diseño; evaluar los impactos sociales de sus diseños en el dominio público o en sistemas
críticos para la seguridad; y seguir las prácticas profesionales apropiadas para asegurar el éxito en el
sistema general. El aspecto de las prácticas éticas y profesionales del diseño de software es desafiante
porque los diseñadores se enfrentan constantemente a numerosas presiones de las partes interesadas
que influyen en las decisiones de los diseñadores, la mayoría de las cuales tienen consecuencias de
naturaleza social, ética o profesional.

Desafío de diseño 5: Gestión de las influencias del diseño

Los diseños están formados por muchas influencias diferentes de las partes interesadas, la organización
de desarrollo y otros factores. Estas influencias pueden tener efectos cíclicos entre el sistema

y sus influencias externas, de modo que los factores externos afectan el desarrollo del sistema y el
sistema afecta sus factores externos (Bass, Clements y Kazman 2003). La gestión de estas influencias es
esencial para maximizar la calidad de los sistemas y su influencia relacionada en futuras oportunidades
de negocio. De importancia específica son las influencias del diseño que provienen de las partes
interesadas del sistema y su organización en desarrollo.

Partes interesadas

El diseño de software es una actividad no determinista. Si se asigna la misma tarea a diferentes

diseñadores, se propondrán diferentes soluciones, siendo cada una de ellas perfectamente aceptable
(McConnell 2004). Ahora agregue a la mezcla la multitud de influencias que provienen de diferentes
partes interesadas, y puede obtener fácilmente una variedad de alternativas de diseño para satisfacer
una variedad de preocupaciones de las partes interesadas, todas en conflicto entre sí. Esto crea un
desafío cuando se intercambian alternativas de diseño que satisfacen las preocupaciones de todas las
partes interesadas. Hacer tales compensaciones de diseño es difícil, especialmente en los esfuerzos de
diseño a gran escala. Considere un proyecto con múltiples clientes, cada uno con objetivos en conflicto
que afectan las decisiones de diseño. En tales proyectos, la creación de un diseño que sacrifique parte
de la capacidad deseada por el cliente pero proporcione otras propiedades deseadas, como un tiempo
de comercialización rápido, confiabilidad o un costo más bajo, puede llevar al desarrollo de un sistema
de alta calidad que mantenga niveles aceptables de satisfacción entre los interesados. Este es un
ejemplo de cómo las partes interesadas afectan la decisión de diseño y el diseño, a su vez, influye en los
objetivos de las partes interesadas (Bass et al. 2003). Manejar las influencias de las partes interesadas es
un desafío porque requiere que los diseñadores ejerzan un alto nivel de comunicación, negociación y
habilidades técnicas para garantizar que las decisiones de diseño se tomen para acomodar todas las
inquietudes sin afectar negativamente el proyecto.

Estructura de la organización de desarrollo

La estructura de la organización de desarrollo influye en el desarrollo de productos de software, en

particular, el diseño de esos productos. Como ejemplo, considere el caso de la ingeniería de software
distribuida. En el mercado global actual, se están produciendo cada vez más casos de desarrollo de
software distribuido. Existe una amplia variedad de razones para desarrollar software en diferentes
sitios. Considere las empresas que tienen sitios en varios estados, donde se encuentran varios niveles de
experiencia en el dominio en diferentes sitios. O considere el caso de los ingenieros de software que
renuncian, creando una brecha en el equipo de desarrollo que es difícil de llenar con recursos locales.
Finalmente, considere empresas que simplemente quieren reducir costos contratando ingenieros de
software de diferentes países. Estas y muchas otras razones existen para tener desarrollo a través de los
límites del sitio. En cada uno de estos casos, la estructura de la organización del desarrollo hace que sea
complicado, por ejemplo, coordinar los esfuerzos de diseño, evaluar y discutir alternativas de diseño,
realizar revisiones por pares y administrar el control de versiones. En estos casos, los diseñadores deben
considerar no solo los aspectos técnicos del diseño, sino también la distribución de los empleados, las
metas de la organización, la disponibilidad de recursos, etc. Los diseños que admiten la integración de la
experiencia distribuida entre sitios pueden introducir capacidades para crear nuevos productos de
software que no podrían diseñarse de otra manera. Esto a su vez puede

Influir en la organización en desarrollo para que apunte a nuevas áreas de negocios, lo que permite que
el diseño del software influya en sus objetivos comerciales. Manejar las influencias de la organización de
desarrollo es un desafío porque requiere que los diseñadores se extiendan más allá del dominio técnico
para tener un gran interés en la organización como un todo.

CONTEXTO DEL DISEÑO DE SOFTWARE

En los sistemas de software modernos de hoy en día, el diseño de software juega un papel clave en el
desarrollo de

productos de software; sin embargo, es solo una fase de la vida completa de la ingeniería de software.

ciclo. Para entender cómo encaja el diseño dentro de todo el proceso de ingeniería de software, es

necesario proporcionar el contexto apropiado para que se puedan hacer distinciones claras entre

las diferentes fases del ciclo de vida y una apreciación de la importancia del diseño de software

Se pueden adquirir actividades y tareas. Por esta razón, una visión general de la ingeniería de software

y se requiere su ciclo de vida. La ingeniería de software es definida por el IEEE (1990, p. 67) como

(1) La aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y

mantenimiento de software; es decir, la aplicación de la ingeniería al software. (2) El estudio de
enfoques como en (1).

Las fases fundamentales del ciclo de vida de la ingeniería de software incluyen requisitos, diseño,
construcción, prueba y mantenimiento, como se presenta en la Tabla 1.5.

La fase de requisitos es donde se identifican las partes interesadas y se determinan las necesidades y
deseos del cliente y los requisitos no funcionales (a menudo pasados por alto) (Laplante 2009). Durante
esta fase, los requisitos se analizan en su forma original para abordar problemas tales como requisitos
que no tienen sentido, se contradicen entre sí o son incompletos, vagos o simplemente incorrectos
(Laplante 2009); los requisitos se clasifican y priorizan; y se revisa y valida la especificación del sistema
de software, que generalmente da como resultado la producción de un documento, o su equivalente
electrónico
2005). Una vez que se especifican los requisitos para el sistema, se lleva a cabo el diseño del sistema,
que es el tema principal de este libro.

La fase de construcción comienza una vez que se ha ejecutado la fase de diseño y todos los requisitos se
pueden rastrear a una sección de los modelos de diseño de software. La fase de construcción es donde
los diseños se implementan utilizando el lenguaje de programación elegido. En esta fase, el código se
genera de acuerdo con una guía de estilo. Además, el código se somete a pruebas unitarias, se depura y
se revisa por pares; los errores de programación se detectan, rastrean y resuelven; el código se gestiona
mediante el uso de software de gestión de cambios y control de versiones; y, por último, el código se
prepara para la entrega mediante un conjunto predefinido de convenciones para formatear. La fase de
construcción está estrechamente relacionada con la fase de diseño y, en algunos casos (normalmente en
proyectos más pequeños), la línea que divide ambas fases puede ser difícil de identificar. Hay varias
razones para esto, la principal es que los diseños detallados se pueden traducir directamente a código;
por lo tanto, los ingenieros de software tienden a diseñar y codificar al mismo tiempo. En otros casos,
donde el diseño y la construcción están claramente delineados por el proceso, es común que algunas
tareas de construcción, como la identificación de clases, funciones y nombres de variables apropiados,
se realicen durante el diseño detallado. Finalmente, debido a que muchos descubrimientos realizados
en la fase de construcción dan lugar a una funcionalidad que requiere trabajo de diseño, los ingenieros
deben alternar entre las actividades de construcción y diseño. Una vez que todos los artefactos de
diseño se implementan con la programación y todos los requisitos asignados se pueden validar
mediante la ejecución del código durante las pruebas unitarias, la fase de construcción está completa.

La fase de prueba suele ser el paso final antes de que el software salga por la puerta. El objetivo
principal de la fase de prueba es verificar y validar el software para garantizar que cumpla con las
funciones predefinidas y el nivel de calidad definido en la fase de requisitos del software. Formalmente,
el IEEE (1990, p. 76) define la prueba como

(1) El proceso de operar un sistema o componente bajo condiciones específicas, observando o

registrar los resultados y hacer una evaluación de algún aspecto del sistema o componente. (2) El
proceso de analizar un elemento de software para detectar las diferencias entre las condiciones
existentes y requeridas (es decir, errores) y evaluar las características del elemento de software.

La fase de prueba del software sirve como puerta de enlace entre el desarrollo y el lanzamiento del
producto. Por lo tanto, se deben realizar esfuerzos de verificación y validación para garantizar que el
software cumpla con las especificaciones y que se pueda garantizar la integridad del software en
condiciones normales y duras. Es importante tener en cuenta que no se puede verificar ningún atributo
de calidad deseado durante la prueba si no se ha diseñado primero en el producto. Por lo tanto, aunque
las pruebas generalmente se acreditan para garantizar la calidad del producto, el diseño es fundamental
para respaldar una fase de prueba exitosa. Una vez que se entrega el software, comienza la fase de
mantenimiento para implementar correcciones, adaptaciones o mejoras al software. Las correcciones
generalmente se realizan en una escala más pequeña para rectificar el comportamiento defectuoso o la
salida del software. Por lo general, no requieren trabajo de diseño. Sin embargo, para adaptaciones o
mejoras, es posible que se requiera trabajo de diseño para adaptarse a los cambios. Juntas, todas las
fases del ciclo de vida de la ingeniería de software trabajan juntas para definir las funciones que el
software debe proporcionar, para transformar estas funciones en soluciones técnicas, para implementar
esas soluciones y para validar su implementación y asegurar la calidad del sistema a lo largo de futuras
versiones. .