Construcción

Sistemas de Información 2022

 Teoría

Construcción
de un Sistema
de información
 • El término “Construcción de
Software” se refiere a la creación
¿Qué es la de software productivo y
significativo a través de los
construcción procesos de codificación,
de software? verificación, pruebas unitarias,
pruebas de integración y
depuración de errores.
¿Qué es la construcción
de software?
• La construcción de software es el proceso en
el cual se genera un programa que pueda
ejecutarse. Esta construcción está altamente
ligada al diseño del sistema y a su vez estará
muy relacionado con las prueba que validen el
sistema.
¿Qué es la construcción
de software?

• Se refiere a la creación detallada de software

operativo mediante una combinación de:
• Codificación
• Verificación
• Pruebas Unitarias y de Integración
• Depuración
Construcción
• Los límites entre Construcción, Diseño y Pruebas
varían dependiendo del ciclo de vida que se usa en
cada proyecto
• Aunque bastante esfuerzo de diseño puede
realizarse antes de empezar las actividades de
construcción, otro debe de realizarse en paralelo.
Construcción

• Igualmente, algunos tipos de pruebas se

realizan durante la construcción, mientras
que otras se hacen después.
• Durante la construcción se generan las
cantidades más grandes de artefactos
software (ficheros de código, contenidos,
casos de prueba, etc.), esto origina
necesidades de gestión de configuración.
Construcción

• Los principios fundamentales de la construcción de

software son:
• Minimizar la Complejidad

• Anticipar los Cambios

• Pensar en la Verificación posterior

• Aplicar Estándares
 • Los principios fundamentales de la
construcción de software son:

• Minimizar la Complejidad :
• Escribiendo código sencillo y fácil
Construcción de leer
• Utilizando estándares
• Técnicas de codificación
• Técnicas de aseguramiento de
calidad
 • Los principios fundamentales de la
construcción de software son:

Construcción • Anticipar los cambios :

• El software se ve afectado por los
cambios en su entorno y está destinado
a cambiar a lo largo del tiempo
• Aplicación de técnicas específicas
 • Los principios fundamentales de la construcción de
software son:

• Pensar en la verificación posterior:

• Construir de forma que los fallos puedan ser
encontrados lo antes posible (al codificar,

Construcción
hacer pruebas u operar el sistema)

• Técnicas:
• Seguir estándares de codificación
• Hacer pruebas unitarias
• Organizar el código para soportar pruebas
automatizadas
• Restringir el uso de técnicas complejas
 • Los límites entre el diseño y la construcción
variaran dependiendo del proceso de ciclo de
vida del software utilizado en el proyecto.
Construcción Aunque ciertas tareas de diseño puedan ser
desarrolladas antes del proceso de construcción,
gran parte del trabajo de diseño es realizado en
si, durante el proceso de construcción.
 Construcció
Diseño Pruebas
n
 Planificación

Manejo de Excepciones

Codificación
Proceso de Pruebas
Construcción
Aseguramiento de la calidad

Reutilización

Integración
 Elegir el método de construcción
• Granularidad y alcance con el que se
realizan los requisitos
• Orden en el que se abordan
Planificación
Establecer el orden en el que los
componentes se crean e integran

Asignar tareas de construcción a

personas específicas
 Modificaciones

Manejo de Ajustes
Excepciones
Detalles a perfeccionar del diseño
 Aplicar técnicas para crear código fuente
comprensible

Manejar condiciones de error

Prevenir brechas de seguridad a nivel de código

Codificación
Uso eficiente de recursos escasos

Organizar el código fuente

Documentar el código
 Utilizadas por aquellos que escriben el
código

Pruebas El propósito de estas pruebas es reducir

el tiempo entre el momento en el que
los fallos se insertan en el código y el
momento en que son detectados.
• Pruebas Unitarias
• Pruebas de Integración
 Pruebas (Unitarias y de Integración)

Escribir las pruebas primero

Ejecución línea a línea

Aseguramiento Uso de aserciones
de la calidad
Depuración

Revisiones

Análisis estático
 • Pruebas (Unitarias y de Integración)
• Escribir las pruebas primero
• Ejecución línea a línea
• Uso de aserciones
• En programación, una aserción es un
Aseguramiento predicado o una sentencia verdadero-
falso, incluido en un programa como
de la calidad indicación de que el programador piensa
que dicho predicado siempre se cumple en
ese punto del flujo de programa.
• Depuración
• Revisiones
• Análisis estático
 Implica mas que reutilizar código.

Activos reutilizables:
• Planes de proyecto, Estimaciones de
Reutilización coste
• Especificaciones de requisitos,
Arquitecturas, Diseños, Interfaces…
• Código fuente (librerías, componentes,…)
• Documentación de usuario y técnica,
Casos de prueba, Datos,…
 De rutinas, clases, componentes y sub-
sistemas construidos de forma
separada, y con otro(s) sistema(s)
• Planificar la secuencia en que se integrarán los
componentes
• Crear “andamios” para soportar versiones
Integración provisionales
• Determinar el nivel de pruebas y aseguramiento
de calidad realizado sobre los componentes
antes de su integración.

Determinar si es posible una correcta

integración
Verificación y Validación
Construcción
 ¿Qué es la verificación y validación?

Verificar y validar es un conjunto

de procedimientos, actividades,
técnicas y herramientas que se
Las pruebas son una familia de
utilizan, paralelamente al
técnicas de verificación y
desarrollo construcción del
validación.
software, para asegurar que el
producto resuelve el problema
inicialmente planteado.
Objetivos de la verificación y la validación

Disminuir los riesgos, las

Detectar y corregir los defectos y desviaciones sobre los
desviaciones respecto al objetivo presupuestos y sobre el
fijado. calendario o programa de
tiempos del proyecto.

Mejorar la calidad y fiabilidad Valorar rápidamente los cambios

del software. propuestos y sus consecuencias.
 VERIFICACIÓN VALIDACIÓN

¿Estamos construyendo ¿Estamos construyendo el producto

correctamente el producto? correcto?

El software
debe Estar conforme a su Hacer lo que el usuario
especificación realmente quiere

Demostrar la consistencia,
Determinar la corrección del
compleción y corrección de los
Objetivo producto final respecto a las
artefactos de las distintas fases
necesidades del usuario
(productos intermedios)

Técnica más
Revisiones Pruebas
utilizada
 Técnicas estáticas y dinámicas

Estáticas Dinámicas
Revisiones Pruebas
Las revisiones de software pueden ser

Formales
Semi-
Informales (Inspecciones
formales
)
 Informales

• No hay procedimientos definidos, por

lo que la revisión se realiza de la forma
más flexible posible.
Las revisiones • Requiere de menos preparación y por
lo mismo, puede detectar menos
de software errores.
pueden ser
Semi-formales

Formales
 Informales

Las revisiones Semi-formales

de software • Hay procedimientos mínimos
pueden ser a seguir, como un tutorial.

Formales
 Informales

Semi-formales

Las revisiones Formales

de software • Revisión en detalle para verificar si el

producto se ajusta a sus especificaciones o
pueden ser atributos de calidad y a los estándares
utilizados en la organización.
• Si existen, señalan las desviaciones sobre los
estándares y las especificaciones.
• Recopilan datos que realimenten inspecciones
posteriores (defectos recogidos, esfuerzo
empleado, etc.)
 Codificación
¿Qué necesitamos para programar?
¿Qué necesitamos?
Tecnologías Back-end y front-end
• Lenguajes de programación
• Estructuras
• Bases de datos

Editores de texto

Servidores locales (para PHP)

PRUEBAS DEL SOFTWARE

Construcción
 PRUEBAS DE SOFTWARE

• Las pruebas de Software tienen 2 objetivos:

• Demostrar al desarrollador y al cliente que el software alcanza sus requisitos.

• Descubrir situaciones donde el comportamiento del software es incorrecto, indeseable o no esta

ajustado a las especificaciones.
PRUEBAS DE SOFTWARE

Objetivo Pruebas de
1 validación

Objetivo Pruebas de
2 defecto
Las pruebas no pueden demostrar que

un software esta libre de defectos o que

siempre se comportara según lo

especificado en cada circunstancia.

 ESTRATEGIA DE PRUEBA DE
SOFTWARE

Una estrategia de prueba de

Por tanto, cualquier estrategia de
software proporciona una guía
prueba debe incorporar la
que describe los pasos que deben
planificación de la prueba, el
realizarse como parte de la
diseño de casos de prueba, la
prueba, cuándo se planean y se
ejecución de la prueba y la
llevan a cabo dichos pasos, y
recolección y evaluación de los
cuánto esfuerzo, tiempo y
resultados.
recursos se requerirán.
ESTRATEGIA DE PRUEBA El gerente de proyecto, los ingenieros de
DE SOFTWARE
software y los especialistas en pruebas

¿Quién la realiza? desarrollan una estrategia para probar el

software.
 ESTRATEGIA DE PRUEBA DE
SOFTWARE

Componente

Componente La prueba comienza “por lo

Grupo de Componentes

pequeño” y avanza “hacia lo

grande”.
ESTRATEGIA DE PRUEBA DE
SOFTWARE

• En las primeras etapas de prueba se enfocan sobre

un solo componente o un pequeño grupo de
componentes relacionados y se aplican pruebas
para descubrir errores en los datos y en la lógica
de procesamiento que se encapsularon en los
componentes.
ESTRATEGIA DE PRUEBA DE
SOFTWARE

• Después de probar éstos, deben integrarse hasta

que se construya el sistema completo. En este
punto, se ejecuta una serie de pruebas de orden
superior para descubrir errores en la satisfacción de
los requerimientos del cliente.
• Conforme se descubren, los errores deben
diagnosticarse y corregirse usando un proceso que
se llama depuración.
 Para realizar una prueba efectiva, debe
realizar revisiones técnicas efectivas. Al
hacerlo, eliminará muchos errores antes de
comenzar la prueba.

E S TRATE G I A D E La prueba comienza en los componentes y

P RU EB A D E
SO FT WA RE : opera “hacia afuera”, hacia la integración de
PL A N TI L LA todo el sistema de cómputo.

Diferentes técnicas de prueba son adecuadas

para distintos enfoques de ingeniería de
software y en diferentes momentos en el
tiempo.
 Las pruebas las realiza el
desarrollador del software, y
para proyectos grandes, un
E S TRATE G I A D E grupo de prueba independiente.
P RU EB A D E
SO FT WA RE :
PL A N TI L LA
Prueba y depuración son
actividades diferentes, pero la
depuración debe incluirse en
cualquier estrategia de prueba.
ESTRATEGIA DE PRUEBA DE
SOFTWARE

Pruebas de Verificar un
pequeño segmento
bajo nivel de código fuente

Validar las
Pruebas de funciones del
sistema a partir de
alto nivel los requerimientos
del cliente
Pruebas de software
VERIFICACIÓN Y
VALIDACIÓN
VERIFICACIÓN Y VALIDACIÓN

Verificació
Validación
n
¿Construimos ¿Construimos
el producto el producto
correctamente? correcto?
 • La verificación y la validación incluyen un amplio
arreglo de actividades SQA:
1. Revisiones técnicas

VERIFICACIÓN Y 2. Auditorías de calidad y configuración

VALIDACIÓN 3. Monitoreo de rendimiento
4. Simulación
5. Estudio de factibilidad
6. Revisión de documentación
 7. Revisión de base de datos
8. Análisis de algoritmos
9. Pruebas de desarrollo
VERIFICACIÓN Y
10. Pruebas de usabilidad
VALIDACIÓN
11. Pruebas de calificación
12. Pruebas de aceptación
13. Pruebas de instalación
Las pruebas representan el último
bastión desde donde puede valorarse la
calidad y, de manera más pragmática,
descubrirse errores.
PA S O S D E L A
PRUEBA DE
S O F T WA R E
 PREGUNTAS EN EL PROCESO DE
PRUEBAS

¿Cuándo terminan las pruebas?

¿Cómo se sabe que se ha probado lo suficiente?

ESTRATEGIAS DE PRUEBA PARA SOFTWARE
CONVENCIONAL

Pruebas de software
 PRUEBA DE UNIDAD

• La prueba de unidad enfoca los esfuerzos de

verificación en la unidad más pequeña del
diseño de software: el componente o módulo
de software.
 PRUEBA DE UNIDAD

Las pruebas de unidad por lo general se consideran como adjuntas

al paso de codificación.

El diseño de las pruebas de unidad puede ocurrir antes de

comenzar la codificación o después de generar el código fuente.
 PRUEBAS DE Si todos los componentes funcionan individualmente,
INTEGRACIÓN
¿Por qué dudan que funcionarán cuando se junten todos?
 • Las pruebas de integración son una técnica
sistemática para construir la arquitectura del software
mientras se llevan a cabo pruebas para descubrir
PRUEBAS DE errores asociados con la interfaz.
INTEGRACIÓN
• El objetivo es tomar los componentes probados de
manera individual y construir una estructura de
programa que se haya dictado por diseño.
 Integración descendente

Integración ascendente

PRUEBAS DE
INTEGRACIÓN: Prueba de regresión
INTEGRACIÓN
I N C R E M E N TA L

Prueba de humo

Productos de trabajo de las

pruebas de integración.
• Los módulos se integran al
moverse hacia abajo a través de la
jerarquía de control, comenzando
con el módulo de control principal
(programa principal). INTEGRACIÓN
• Los módulos subordinados al DESCENDENTE
módulo de control principal se
incorporan en la estructura en una
forma de primero en profundidad o
primero en anchura.
• La prueba de integración
ascendente, como su nombre
implica, comienza la construcción
y la prueba con módulos atómicos
INTEGRACIÓN
(es decir, componentes en los ASCENDENTE
niveles inferiores dentro de la
estructura del programa).
• La prueba de humo es un enfoque
de prueba de integración que se usa
cuando se desarrolla software de
producto.

PRUEBA DE
• La prueba de humo puede
caracterizarse como una estrategia
HUMO
de integración constante. El
software se reconstruye (con el
agregado de nuevos componentes)
y se prueba cada día.
PRUEBAS DE VALIDACIÓN

Pruebas de software
• Las pruebas de validación
comienzan en la culminación de
las pruebas de integración,
cuando se ejercitaron
componentes individuales, el PRUEBAS DE VALIDACIÓN
software está completamente
ensamblado como un paquete y
los errores de interfaz se
descubrieron y corrigieron.
 ¿CUÁNDO ES EFECTIVA LA
VALIDACIÓN?

• La validación es exitosa cuando el software

funciona en una forma que cumpla con las
expectativas razonables del cliente.
 ¿CUÁNDO ES EFECTIVA LA
VALIDACIÓN?

• La validación es exitosa cuando el software

funciona en una forma que cumpla con las
expectativas razonables del cliente.

Especificación de requerimientos
de software
 CRITERIOS PARA LA VALIDACIÓN

Un plan de pruebas subraya

las clases de pruebas que se
La validación del software se
van a realizar y un
logra a través de una serie de
procedimiento de prueba
pruebas que demuestran
define casos de prueba
conformidad con los
específicos que se diseñan
requerimientos.
para garantizar diferentes
aspectos.
 CRITERIOS PARA LA VALIDACIÓN

Se satisfacen todos los Se logran todas las Todo el contenido es

requerimientos de características de preciso y se presenta
funcionamiento comportamiento de manera adecuada

La documentación es
Se logran todos los
correcta y se satisfacen
requerimientos de
la facilidad de uso y
rendimiento
otros requerimientos.
 La prueba alfa se lleva a cabo en el sitio
del desarrollador por un grupo
representativo de usuarios finales. El
software se usa en un escenario natural con
el desarrollador presente y los usuarios
registrando los errores y problemas de uso.
PRUEBAS ALFA
Y BETA

Las pruebas alfa se realizan en un

ambiente controlado.
 La prueba beta se realiza en uno o más
sitios del usuario final.

PRUEBAS ALFA
Y BETA
A diferencia de la prueba alfa, por lo
general el desarrollador no está presente.
Por tanto, la prueba beta es una aplicación
“en vivo” del software en un ambiente
que no puede controlar el desarrollador.
PRUEBAS DE SISTEMA

Pruebas de Software
 PRUEBA DE SISTEMA

Aunque cada prueba tenga un

La prueba del sistema es una
propósito diferente, todo él
serie de diferentes pruebas
funciona para verificar que los
cuyo propósito principal es
elementos del sistema se
ejercitar por completo el
hayan integrado de manera
sistema basado en
adecuada y que se realicen las
computadora.
funciones asignadas.
 PRUEBAS DE RECUPERACIÓN

La recuperación es una prueba del sistema que fuerza al

software a fallar en varias formas y que verifica que la
recuperación se realice de manera adecuada.
Si la recuperación es automática, se evalúa Si la recuperación requiere intervención
el reinicio, los mecanismos de puntos de humana, se evalúa el tiempo medio de
verificación, la recuperación de datos y la reparación (TMR) para determinar si está
reanudación para correcciones. dentro de límites aceptables.
 PRUEBAS DE SEGURIDAD

Con los suficientes tiempo y

La prueba de seguridad intenta
verificar que los mecanismos de
protección que se construyen en un
sistema en realidad lo protegerán de
cualquier penetración impropia.
recursos, las buenas pruebas de
seguridad a final de cuentas penetran
en el sistema. El papel del diseñador
de sistemas es hacer que el costo de
la penetración sea mayor que el valor
de la información que se obtendrá.
 La prueba de esfuerzo ejecuta un
sistema en forma que demanda
recursos en cantidad, frecuencia o
volumen anormales.
PRUEBAS DE
ESFUERZO
Una variación de la prueba de
esfuerzo es una técnica llamada
prueba de sensibilidad.
 PRUEBAS DE RENDIMIENTO

La prueba del rendimiento ocurre a lo largo de todos los pasos del

proceso de prueba. Incluso en el nivel de unidad, puede accederse al
rendimiento de un módulo individual conforme se realizan las
pruebas.
Sin embargo, no es sino hasta que todos los elementos del sistema
están plenamente integrados cuando puede determinarse el verdadero
rendimiento de un sistema.
 La prueba de despliegue, en
ocasiones llamada prueba de
configuración, ejercita el software en
cada entorno en el que debe operar.
PRUEBAS DE
DESPLIEGUE
Puesto que la seguridad es un tema
principal, un juego completo de
pruebas de seguridad se integraría
con la prueba de despliegue.
DEPURACIÓN

Pruebas de software
Prueba
Depuración
exitosa

PROCESO DE DEPURACIÓN
 PROCESO DE DEPURACIÓN

Durante la depuración,
Conforme aumentan las
encontrará errores que
consecuencias de un
varían desde los
error, también aumenta la
ligeramente
cantidad de presión por
desconcertantes hasta los
encontrar la causa.
catastróficos.
 ESTRATEGIAS DE DEPURACIÓN

Tácticas de depuración.

Depuración automatizada.

El factor humano.
 TÁCTICAS DE DEPURACIÓN

• La categoría fuerza bruta de la depuración probablemente es el método más común y

menos eficiente para aislar la causa de un error de software.
• Al usar una filosofía de “deje que la computadora encuentre el error”, se espera que en
alguna parte de toda la información que se produzca, se encontrará una pista que pueda
conducir a la causa de un error.
 TÁCTICAS DE DEPURACIÓN

• El seguimiento hacia atrás o vuelta atrás es un enfoque de depuración bastante común

que puede usarse exitosamente en programas pequeños. Al comenzar en el sitio donde se
descubrió un síntoma, el código fuente se rastrea hacia atrás (de manera manual) hasta
que se encuentra la causa.
 TÁCTICAS DE DEPURACIÓN

• La eliminación de la causa, se manifiesta mediante inducción o deducción, e introduce el

concepto de partición binaria. Los datos relacionados con la ocurrencia del error se
organizan para aislar las causas potenciales.
 DEPURACIÓN AUTOMATIZADA

• Cada uno de estos enfoques de

depuración puede complementarse
con herramientas de depuración
que puedan proporcionar apoyo
semiautomático conforme se
intenten estrategias de depuración.
 EL FACTOR HUMANO

• Una máxima final para la depuración puede ser:

“Cuando todo lo demás falle, ¡consiga
ayuda!”
 CORRECCIÓN DEL ERROR

1 2 3
¿La causa del error se ¿Qué “siguiente error” ¿Qué debió hacerse
reproduce en otra parte puede introducirse con para evitar este error
del programa? la corrección que está a desde el principio?
punto de realizar?
DESPLIE
GUE
Implementación de un software
¿QUÉ CONSIDERAR AL MOMENTO
DE IMPLEMENTAR UN SOFTWARE?
¿Cuáles son las necesidades?

¿Hacia dónde quieren llegar con el nuevo software?

Planificación consciente

Migración de datos

Responsables de supervisión y gestión de la implementación

Realizar las pruebas

 ¿QUÉ ES
EL  Son todas las actividades que hacen que un sistema de software esté
disponible para su uso.
DESPLIEG
UE DE UN
 Consiste en varias actividades interrelacionadas con posibles
transiciones entre ellas. Estas actividades pueden ocurrir en el lado
del desarrollador de software o en el lado del consumidor o en

SOFTWAR
ambos.

E?
LA IMPLEMENTACIÓN ES UN
PROCESO GENERAL QUE DEBE
PERSONALIZARSE BASADO EN LOS
REQUISITOS Y CARACTERÍSTICAS
ESPECÍFICAS DE LA ORGANIZACIÓN
A considerar SIEMPRE…
ACTIVIDADES DEL
DESPLIEGUE
Configuración del hardware

Instalación, actualización y migración de software

Configuración y personalización del sistema

Desarrollo e integración

Pruebas de prototipos y pilotos

Presentación de producción
ROLES PARA LA
IMPLEMENTACIÓN
En entornos de preproducción:

• Desarrolladores de aplicaciones
• Gerentes de lanzamiento
• Coordinadores de despliegue

En entornos de producción:

• Administrador de sistema
• Administrador de base de datos
• Coordinadores de liberación
• Directores de proyecto de las operaciones
MANTENIMIENT
O
MANTENIMIENTO DE UN
SOFTWARE
En ingeniería del software, el mantenimiento de software es la
modificación de un producto de software después de la entrega, para
corregir errores, mejorar el rendimiento, u otros atributos.

El mantenimiento de software es también una de las fases en el ciclo de

vida de desarrollo de sistemas, que se aplica al desarrollo de software. La
fase de mantenimiento es la fase que viene después del despliegue
(implementación) del software.
 La característica de mantenibilidad
representa la capacidad del producto
software para ser modificado efectiva
y eficientemente, debido a necesidades
evolutivas, correctivas o perfectivas.
MANTENIBIL
IDAD

La mantenibilidad está dividida en

características, que se detallan a
continuación.
  Modularidad.
 Capacidad de un sistema o programa de
ordenador (compuesto de componentes
discretos) que permite que un cambio en un
componente tenga un impacto mínimo en los
demás.
 Reusabilidad.
MANTENIBIL  Capacidad de un activo que permite que sea
IDAD utilizado en más de un sistema software o en la
construcción de otros activos.
 Capacidad de ser analizado.
 Facilidad con la que se puede evaluar el impacto
de un determinado cambio sobre el resto del
software, diagnosticar las deficiencias o causas
de fallos en el software, o identificar las partes a
modificar.
  Capacidad para ser modificado.
 Capacidad del producto que permite que sea
modificado de forma efectiva y eficiente sin
introducir defectos o degradar el desempeño.
MANTENIBIL  Capacidad para ser probado.
IDAD  Facilidad con la que se pueden establecer
criterios de prueba para un sistema o
componente y con la que se pueden llevar a cabo
las pruebas para determinar si se cumplen dichos
criterios.
  La mantenibilidad es considerada un atributo
de calidad por lo cual a su vez se distingue
MANTENIBIL como un requisito no funcional del sistema. Y
como tal, debe ser especificado al inicio de
IDAD cada proyecto de desarrollo de software,
cuando se define el alcance del producto a
desarrollar.
 Mantenimiento preventivo.

• Consiste en la revisión constante del software para

detectar posibles fuentes de problemas que puedan
surgir en el futuro.

Mantenimiento predictivo.
TIPOS DE • Evalúa el flujo de ejecución del programa para predecir

MANTENIMIEN con certeza cuándo ocurrirá la falla, y así determinar

cuándo es apropiado hacer los ajustes correspondientes.

TO DE Mantenimiento correctivo.
SOFTWARE • Corrige los defectos encontrados en el software, y que
originan un comportamiento diferente al deseado. Estas
fallas pueden ser de procesamiento, rendimiento (por
ejemplo, uso ineficiente de recursos de hardware),
programación (inconsistencias en la ejecución),
seguridad o estabilidad, entre otras.
 Mantenimiento adaptativo.

• Si es necesario cambiar el entorno en el que se utiliza

la aplicación, puede ser necesario modificarla para
mantener su plena funcionalidad en estas nuevas
condiciones.

TIPOS DE Mantenimiento evolutivo.

MANTENIMIE • Es un caso especial donde la adaptación es

prácticamente obligatoria, ya que de lo contrario el
NTO DE programa quedaría obsoleto con el paso del tiempo.

SOFTWARE Mantenimiento perfecto.

• Por diferentes razones, el usuario puede solicitar la

adición de nuevas funcionalidades o características no
consideradas en el momento de la implementación del
software. Un mantenimiento perfecto adapta la
aplicación a este requisito.