Caso de estudio

DEVELOP SOFTWARE
Como ingeniero de software has iniciado labores profesionales en la empresa
DEVELOP SOFTWARE, la que tiene como giro principal la creacin de aplicaciones
hechas a medida para los clientes que solicitan sus servicios. La empresa est
compuesta por un gerente general, un jefe de departamento de desarrollo, tres
programadores, un diseador, un ingeniero de testing y dos analistas.
Adicionalmente laboran en la organizacin tres encargados de ventas una
recepcionista y un guardia de seguridad.
Como parte de tus obligaciones profesionales se te ha encomendado realizar la
propuesta de un plan SQA para asegurar la calidad de un proyecto que se iniciar.
El proyecto se trabajar con un modelo de desarrollo gil basado en la creacin de
prototipos, y se tiene un alto grado de acceso a los usuarios finales y a la gerencia
por lo que la interaccin con los clientes ser cercana y permanente

Instrucciones
1.- En base a la informacin proporcionada complementar el plan para el
aseguramiento de la calidad del software desarrollando el proyecto de
mantenimiento de software que contenga lo siguiente:
2.- Identificar el tipo de mantenimiento al que corresponda el caso. (Para cada
una de sus etapas)
3.- Identifica las fases de evolucin del mantenimiento por las cuales el sistema
pasar
4.- Realiza el estudio de viabilidad y costos con base en los requerimientos.
5.- Integra esta informacin con lo ya desarrollado en la unidad 1 y 2 y modifica
las conclusiones del documento para incluir tu opinin sobre la importancia del
informe de viabilidad y anlisis de riesgos de un proyecto de mantenimiento de
software.
Plan de aseguramiento de pruebas
El plan a desarrollar se enfoca en establecer las pautas y actividades a
implementarse para garantizar la calidad del proyecto a desarrollar, el plan brinda
elementos de apoyo a la gestin del proyecto con lo cual se pueden realizar
verificaciones sobre la adecuacin al proceso y, de esta manera, detectar desvos
y posibles errores que puedan resultar en acciones correctivas en las etapas
tempranas, el ciclo de vida relacionadas que se tendr en cuenta para el presente
plan es: elaboracin, construccin, evaluacin y transicin, siguiendo una lnea de
trabajo sobre los siguientes pasos: requerimientos, anlisis, diseo,
implementacin, verificacin y mantenimiento.
Objetivo de la calidad del programa
Desarrollar cada etapa del proyecto con la seguridad de que se est cumpliendo
con todos los requisitos y funcionalidades que se espera obtener, evitando costos
futuros en reparacin o mantenimiento prematuro del software, garantizando al
cliente un producto apto para su uso e implementacin con un grado de error
mnimo.
Actividades de revisin propuestas para el plan
Revisar cada producto
El alcance de esta actividad consiste en revisar los productos que se hallan
definido como principales para verificar en el plan de calidad empleado,
inspeccionando que no queden correcciones sin resolver identificadas en los
informes de revisin previos, en caso de que se encuentre alguna no
resuelta, esta deber ser incluida en la siguiente revisin. Tambin se deber
identificar, documentar y mantener en continua revisin las desviaciones
encontradas as como verificar que se hayan realizado las correcciones
necesarias, como resultado se obtiene el Informe de revisin de SQA, el cual
debe ser entregado a los responsables del producto, asegurndoles que son
conscientes de desviaciones o discrepancias encontradas. Los responsables
de ejecutar la actividad son: el jefe de departamento de desarrollo y el
ingeniero de testing.
Revisar el ajuste al proceso
Su alcance consiste en revisar los productos que se definieron como
principales para verificar el cumplimiento de las actividades definidas en el
proceso, para asegurar la calidad en el producto final del desarrollo, se
realizaran revisiones sobre los productos durante todo el ciclo de vida del
software y a su vez se recoger la informacin necesaria de cada producto,
buscando que cumplan con los requerimientos planteados inicialmente.
Hay que debe verificar en los informes de revisin previos que todas las
desviaciones fueron corregidas, de no ser este el caso, las faltantes se
incluyen para ser probadas en un futuro no lejano, con el fin de pasar a la
siguiente etapa de desarrollo, de esta actividad se puede obtener el Informe
de revisin de SQA correspondiente a la evaluacin de ajuste al proceso, el
cual deber ser entregado a los programadores y gerente general, con el fin
de corregir posibles errores encontrados y darle seguimiento al desarrollo del
proyecto. Los responsables de ejecutar esta actividad son: el ingeniero de
testing y los analistas.
Realizar Revisin Tcnica Formal
La actividad consiste en descubrir los errores que se generen en la funcin,
la lgica o la implementacin de cualquier producto del software, verificando
que satisface las especificaciones y que se ajusta a los estndares
establecidos, mostrando las posibles desviaciones detectadas en el
 producto, con esta actividad se espera detectar lo antes posible, los defectos
y/o desviaciones en los productos que se van generando en todo el
desarrollo, estas revisiones se hacen mediante reuniones donde se convoca
a todo el equipo de desarrollo, gerente general, jefe de departamento de
desarrollo, ingeniero de testing, programadores, analistas y el diseador, los
cuales pueden hacer preguntas sobre las dudas que les han surgido durante
las revisiones y pruebas del producto, estas reuniones sern de dos horas o
menos, ya que no se debe invertir mucho tiempo en ellas, como resultado se
obtiene el informe de la revisin tcnica formal.
Asegurar que las desviaciones son documentadas.
El fin de esta actividad es documentar cada una de las desviaciones que se
hayan detectado en el proyecto, manejndolas de acuerdo a un correcto
procedimiento, el cual ser implementado por el responsable del rea que lo
requiera. Los responsables de realizar esta actividad son los analistas, el
encargado de desarrollo y el gerente general, los cuales se encargaran de
checar continuamente a los encargados de cada rea, para que resuelvan
las desviaciones encontradas de una manera oportuna.
Gestin de la configuracin:
Especificacin de requerimientos del software
Los requerimientos en el desarrollo del producto software son de suma importancia
al momento de iniciar con el proyecto, ya que estos sirven de base para las
siguientes etapas, estos son:
Funcionalidad
adecuacin a las necesidades
precisin de los resultados
interoperabilidad
seguridad de los datos
Confiabilidad
madurez
tolerancia a faltas
Usabilidad
comprensible
aprendible
operable
atractivo
Eficiencia
utilizacin de recursos
Mantenibilidad
analizable
modificable
estable
verificable
Portabilidad
adaptable
instalable
co-existencia
En conjunto estos atributos debern cumplir con las normas y regulaciones
aplicables a cada uno.
Descripcin del diseo del software
Este documento es elaborado por los desarrolladores en conjunto con los clientes,
es aqu donde se describen los componentes y subcomponentes del diseo del
software, incluyendo interfaces internas, las cuales cubren los requerimientos
iniciales en funcin de la importancia que estos presenten y de sus conexiones
lgicas.

Verificacin y validacin
Se verifica que los requerimientos descritos en el documento de requerimientos han
sido aprobados por el encargado de desarrollo y el cliente, y se verifica que los
requerimientos planteados son implementados en el diseo plasmado en el
documento de diseo, el cual a su vez deber estar implementado en el cdigo,
validando este ltimo al ser ejecutado.
Documentacin de usuario
En este apartado se especifica y describen los datos y entradas de control
requeridos, as como la secuencia de entradas, opciones, limitaciones del proyecto
y los elementos necesarios para la ejecucin exitosa del software.
Mantenimiento del software
Para esta etapa se realizan revisiones paulatinas al software por parte del
encargado de desarrollo el cual considera que se debe dar mantenimiento o no al
software que se est desarrollando, tambin se realizan las revisiones por el cliente,
si este considera que hace falta mantenimiento, se lo har saber al encargado, quien
a su vez lo re direccionara con el tcnico principal.
Norma para evaluar el proyecto
La norma empleada para la evaluacin del proyecto es IEEE 730-2002, la cual
permite emplear un ciclo de vida apto para cada proyecto, dependiendo el software
que se desea desarrollar, la ventaja principal de este estndar es que describe los
procesos en un plan integral, el cual se ha definido con anterioridad, elaborndose
sistemticamente para su correcta ejecucin.
Plan de pruebas
Revisar cada producto
El elemento del desarrollo que se va a probar
Se probara el sistema completo
Tipo de prueba
La prueba a utilizar en esta actividad es la de Implantacin
Nivel de prueba
Tercer nivel
Justificacin de la utilizacin de la prueba
Se ha optado por la utilizacin de la prueba de implantacin debido a que
este tipo de prueba permite realizar una sobrecarga en la ejecucin del
sistema, lo cual permitir encontrar algn posible error en la ejecucin del
mismo.

Planificacin
En especfico se evaluara la reaccin del sistema ante una sobrecarga de
ejecucin, con lo cual se le pedir al programa que realice una misma accin
un mnimo de 5 veces, tomando en cuenta las ordenes que puede ejecutar
la aplicacin, o producto que se halla desarrollado, cabe mencionar que la
prueba a implementar es dinmica.
Procedimientos
La aplicacin se ejecutara las veces que se halla planeado, en este caso 5
veces una misma orden, con el fin de sobrecargar el sistema y que arroje
algn error, de ser as se documentaran y se proceder a su correccin o
modificacin, segn sea el caso.
Personal que ejecutar la actividad
El jefe de departamento de desarrollo y el ingeniero de testing.
Revisar el ajuste al proceso
El elemento del desarrollo que se va a probar
Se probara la aplicacin por mdulo de cdigo
Tipo de prueba
Prueba de integracin
Nivel de prueba
Segundo nivel
 Justificacin de la utilizacin de la prueba
La prueba de integracin es la adecuada para el ajuste al proceso, pues
permite checar la funcionalidad del cdigo que se est estructurando,
teniendo en cuenta que este integra la informacin que se est procesando
en la elaboracin y ejecucin de la aplicacin.
Planificacin
Se evala el desarrollo del sistema en su etapa media, en la cual ya se cuenta
con clases estructuradas que desempean cada una diferente funcin, la
prueba se aplicara un mnimo de 5 veces, los requerimientos que se hallan
definido para esta etapa son los que se tendrn en cuenta, esperando cumplir
con los mismo, este tipo de prueba es esttica, pues se realiza durante la
programacin del componente.
Procedimientos
El cdigo de la aplicacin se divide en mdulos, para poder realizar
modificaciones o mejoras a la misma en un futuro, por tal motivo se prueba
el modulo en el desarrollo medio de la misma, en donde se realizan
peticiones de integracin por parte del usuario a las clases existentes, las
cuales deben arrojar el resultado previsto, de igual forma se documenta cada
uno de los resultados que se obtengan en las ejecuciones, si el positivo se
procede a dar como aprobado este mdulo.

Personal que ejecutar la actividad

El ingeniero de testing y los analistas.
Realizar revisin tcnica formal
El elemento del desarrollo que se va a probar
El programa en su totalidad
Tipo de prueba
Prueba de aceptacin
Nivel de prueba
Cuarto nivel
Justificacin de la utilizacin de la prueba
La prueba de aceptacin permite al desarrollador determinar si el programa
cumple con los criterios necesarios para su implementacin, verificando si
satisface con las especificaciones y que se ajusta a los estndares
establecidos, por tal motivo se procede a realizar las interacciones
necesarias.
Planificacin
Se evaluara la capacidad que presenta el programa al momento de manipular
los datos y el resultado que arroje, la prueba se llevara a cabo un mnimo de
4 veces, buscando que los requerimientos descritos en el documento inicial
se cumplan en su totalidad, tales como funciones que deben presentar
 resultados al usuario, esta prueba es dinmica, ya que permite probar el
componente cuando est terminado.
Procedimientos
Se ejecutan una serie de ordenes en el sistema de software, introduciendo y
manipulando informacin para que el sistema lleve a cabo el proceso de la
misma, y nos arroje el resultado final, esto se debe realizar el nmero de
veces prevista, para asegurarnos que el programa cumple con los criterios
de aceptacin requeridos.
Personal que ejecutar la actividad
Gerente general, jefe de departamento de desarrollo, ingeniero de testing,
programadores, analistas y el diseador.
Asegurar que las desviaciones son documentadas
El elemento del desarrollo que se va a probar
Por mdulo, dependiendo de cada actividad realizada
Tipo de prueba
Pruebas de regresin
Nivel de prueba
Quinto nivel

Justificacin de la utilizacin de la prueba

En este tipo de prueba se espera que el modulo seleccionado entregue los
resultados finales al usuario, mediante la revisin de los datos
documentados, los cuales debern mostrar resultados finales aceptos para
entregar el producto software.
Planificacin
Se evaluara el cumplimiento de los puntos previstos en la documentacin
inicial, los cuales se van mencionando conforme se desarrolla la actividad,
se realizara la revisin como mnimo 3 veces, esperando que la configuracin
del hardware y software se registren correctamente, el tipo de prueba es
dinmica, pue se realiza al final del desarrollo.
Procedimientos
Se realiza una revisin exhaustiva al documento de la actividad y se anotan
las posibles incongruencias encontradas, esto se debe hacer un mnimo de
3 veces, para que al final se est totalmente seguro de haber atendido a los
avisos necesarios, entregando una actividad correctamente documentada.
Personal que ejecutar la actividad
Ingeniero de testing y analistas

Informe de viabilidad y anlisis de riesgo

Tipos de mantenimiento
Mantenimiento preventivo: Se realiza tan pronto se entregue el producto software,
en este caso se debe hacer una revisin minuciosa a los productos al momento de
ejecutarlos por primera vez en su entorno donde se implementara, de existir algn
error, hay que realizar los cambios necesarios a la brevedad posible, con el fin de
que el error no se convierta en efectivo y resulte ms complejo y costoso corregirlo,
los encargados de hacerlo sern los mismos desarrolladores y diseador.
Mantenimiento correctivo: Despus de entregar el producto de software que se
ha desarrollado, pueden surgir inconvenientes en su ejecucin, ya sea en el
procesamiento de datos o en los resultados que se obtienen al final, cabe mencionar
que estos errores se originan despus de que el sistema estuvo ejecutndose de
una manera correcta, ante este tipo de situaciones hay que implementar el
mantenimiento correctivo.
Mantenimiento adaptativo: El producto software se desarrolla en determinado
entorno operativo y para que funcione tomando en cuenta ciertas herramientas
administrativas, pero al paso del tiempo, tanto el entorno operativo como las
herramientas administrativas se actualizan, o bien el cliente desea cambiar ambas
cosas y desea adaptar el producto, en este caso es necesario realizar el
mantenimiento adaptativo, tomando en cuenta los nuevos requerimientos
mostrados por el cliente, este tipo de mantenimiento se centra en realizar
modificaciones de actualizacin para que el producto se implemente en cualquier
entorno.
Mantenimiento perfectivo: Despus de que el producto lleva un tiempo en el
mercado y ejecutndose tal y como el usuario lo esperaba, surgen cambios a
implementar por parte del usuario, quien requiere que el sistema realice nuevas
funcionalidades o bien que las funcionalidades actuales, sean mejoradas para que
el producto se mantenga con su rendimiento inicial.

Fases de evolucin
Versin alfa: Pertenece al desarrollo inicial, es aqu donde se definen con precisin
los requerimientos del sistema, una vez identificados estos, se procede a estructurar
la aplicacin, ya que se tiene la versin completa, se pueden realizar pruebas, tanto
por el usuario como por los desarrolladores, con el fin de saber si se realizaran ms
cambios y modificaciones en la estructura, por el momento solo se muestran
escenarios y casos de estudio, pero con los conocimientos adquiridos mediante las
pruebas realizadas, se puede emplear el dominio de la aplicacin, soluciones a los
problemas encontrados, nuevos requerimientos del usuario, entre otros.
Etapa de madurez: Se aplica al momento de que el cliente muestra como
necesarias nuevas implementaciones en el mismo, con el fin de adaptarlo a los
entornos actuales que se manejen en su rea de aplicacin, un ejemplo seria la
aplicacin que se desarrolla nicamente para uso de escritorio, pero, con el uso
continuo de otro tipos de dispositivos (tablets, smarthphone, IPad) de debe mejorar
la aplicacin a un diseo responsivo, el cual permitir que esta sea manejada desde
cualquier dispositivo, dndole mayor probabilidad de xito en el mercado a sus
clientes.
Etapa de salida: Despus de haber realizado diferentes tipos de mantenimiento a
las aplicaciones que se desarrollan en la empresa Develop Software, se llega al
punto donde el sistema ya no es adaptable, debido al alto costo que supone realizar
una siguiente modificacin, por tal motivo, es necesario aplicar la reingeniera de
sistemas, la cual nos ayuda a identificar el cdigo reutilizable para tomarlo de base
en un nuevo componente, modulo o sistema para iniciar un nuevo proyecto.
Estudio de viabilidad y costos (Registro de trabajadores)
1. Identificar los requerimientos
- El sistema debe asignar a cada trabajador un nmero de clave conforme
se registre al nuevo integrante de la empresa.
- El sistema debe permitir a los trabajadores registrar su hora de salida y
llegada, mediante la huella digital.

2. Identificar el tipo de mantenimiento

Para el ejemplo tomado sera un mantenimiento perfectivo, pues este tipo de
mantenimiento logra adaptar al sistema existente, nuevas funcionalidades,
que le permitirn a la aplicacin, permanecer ms tiempo en el mercado.
3. Identificar la solucin a tales requerimientos
Requerimientos
- El sistema debe asignar a cada trabajador un nmero de clave conforme
se registre al nuevo integrante de la empresa.
- El sistema debe permitir a los trabajadores registrar su hora de salida y
llegada, mediante la huella digital.
Restricciones al usuario
El sistema se debe centralizar y cifrar, para que el usuario solo acceda
a los datos a manera de lectura.
Se debe adaptar al sistema operativo Windows 10
Utilizar Phpmyadmin para la administracin de la base de datos, a la
cual solo podrn acceder los usuarios administrativos mediante
contrasea.
Requisitos del sistema
Mdulos del sistema
 Actualizacin de datos
Generacin de informes
Equipo de hardware
Nmero de procesador E3-1125C
Cantidad de ncleos 4
Cantidad de subprocesos 8
Velocidad del reloj 2 GHz
Memoria cach L 38 MB
Conjunto de instrucciones 64-bit
Extensiones de conjunto de instrucciones AVX, AES-NI
Disco duro de 1 TB
Un quemador para respaldar la informacin
Lector de huella digital
Software
Phpmyadmin 4.6.6
Windows 10

4. Identificacin de riesgos y medidas de prevencin

Tipo de riesgo Riesgo Medidas Medidas
preventivas correctivas
Del proyecto Siniestros Ninguna Restablecer la
funcionalidad de los
equipos daados a la
brevedad posible.
Nuevos Comunicarse Replantear el estudio
requerimientos continuamente de factibilidad y hacer
por parte del con el usuario saber al usuario las
usuario para que todos consecuencias que
los parmetros a esto supone.
tomar en cuenta,
sean definidos
antes de concluir
con el estudio de
factibilidad.
Tcnico Equipo daado Realizar Aplicar
durante elmantenimiento mantenimiento
desarrollo delpreventivo correctivo
proyecto
Prdida de datos Configurar el Ingresar nuevamente
sistema para que los datos al sistema.
realice una copia
de seguridad del
 mimo cada
determinado
tiempo.
Tecnolgico Necesidad de una Fijar permisos Crear una nueva
interfaz adicional para cada tipo de interfaz
para el usuario del
administrador del sistema.
sistema.
Asociado con el Prdida de algn Tener una lista de Contratar a un nuevo
tamao y miembro del
espera sobre personal y redistribuir
experiencia de la equipo deposibles las actividades.
plantilla del desarrollo. candidatos para
personal el puesto.
Experiencia Capacitar al Capacitar
insuficiente por personal antes de continuamente al
parte del equipo iniciar el proyecto. personal, para que se
en el uso del actualicen en
software informacin y
experiencia.

5. Estudio de factibilidad operativa

Se desarrollan los siguientes mdulos de acuerdo a los requerimientos que
se tienen, estos podrn ser utilizados asocindose a los mdulos que ya
existen y adaptndolos al proyecto, los nuevos mdulos son:
Actualizacin de datos
Generacin de informes
6. Estudio de factibilidad tcnica
Hardware
20 Computadoras personales marca LENOVO modelo AIO 300-22ACL con
las siguientes caractersticas:
Procesador: AMD A6-7310
Memoria Ram: 4G
Disco duro: 1 TB
Pantalla: 21.5 Pulgadas LED
Puertos USB: 2 USB 2.0 / 1 USB 3.0
Teclado: Standard PS2
Red: RJ-45
Sistema Operativo: Windows 10
Mouse: OMEGA PS2
DVD-RW: LG
Unidad de disco flexible 3
Estabilizador ProNet de1000 W
2 Impresoras: HP color LaserJet 8550-PS y Canon Bubblet -Jet S450
Matricial EPSON LQ 570-e
 Plataforma software actual
Windows 10, x86-64, NT 10.0, hbrido.
Programas instalados
Office 360
SQL Server EnterPrice Manager + Service Pack 4
Visual Basic 2015
WinZip 21
WinRar 5.40
Nitro Pro 9
Nero Burning ROM 2014
Servidor wampserver 64
Editor de texto
MySQL 5.6

Para cumplir con los requerimientos de Develop Software, es necesario hacer

las siguientes adquisiciones:
Phpmyadmin
Lector de huella digital
7. Estudio de factibilidad econmica
Alternativa 1.- Lector de huella digital con Phpmyadmin
Construccin
2 programadores 650 al mes
1 Ingeniero de testing 450 al mes
1 analista 400 al mes
Tiempo real: 226.52+4*283.15+353/6
Tiempo real: 285.35
Coste real: 3.2+4*3.5+3.7/6
Coste real: 3.48
Hardware y software
Lector de huella digital 570.00
Phpmyadmin 300.00
Insumos
3 paquetes de papel 15.00
1 caja de lpices 12.00
Llamadas telefnicas 30.00
Impresin 10.00
Costos variables
2 paquetes de papel 10.00
Cartucho de tinta negra 50.00
Cartucho de tinta a color 70.00
Alternativa 2.- Lector de huella digital con MySQL Worckbench 6.3 CE
 Construccin
2 programadores 700 al mes
1 Ingeniero de testing 480 al mes
1 analista 400 al mes
Tiempo real: 196.22+4*245.28+306.6/6
Tiempo real: 247.32
Coste real: 3.3+4*3.5+3.8/6
Coste real: 3.51
Hardware y software
Lector de huella digital 570.00
MySQL Worckbench 6.3 CE 450.00
Insumos
3 paquetes de papel 15.00
1 caja de lpices 12.00
Llamadas telefnicas 30.00
Impresin 10.00
Costos variables
2 paquetes de papel 10.00
Cartucho de tinta negra 50.00
Cartucho de tinta a color 70.00

8. Estudio de factibilidad de tiempo

Tarea Tiempo estimado Tiempo
disponible
Asignacin de 7 das 15 das
roles en el equipo
Creacin de los 4 semanas 5 semanas
nuevos mdulos
Adaptacin del 2 semanas 3 semanas
lector de huellas
dactilares
Pruebas de 2 semanas 3 semanas
sistema

9. Estudio de factibilidad de derechos de autor

Para cumplir con las normas necesarias en cuanto a derechos de autor, se
realiza la compra de las licencias de los softwares incluidos en el desarrollo
y los hardware se compraran en lugares donde hagan constar que la
adquisicin de los mismos es completamente legal.
10. Seleccin de alternativas
Alternativa Descripcin Costo de la
inversin
 Lector de huella Esta alternativa se enfoca en $3, 700.00
digital con utilizar el lector de huellas
Phpmyadmin digitales en conjunto con el
software phpmyadmin, lo que
permitir a los usuarios
detectar si estn en la base de
datos o no.
Lector de huella En esta alternativa se utiliza el $4, 300.00
digital con MySQL lector de huellas digitales en
Worckbench 6.3 conjunto con MySQL
CE Worckbench 6.3 CE, siendo
este ltimo quien permite
manejar los datos de los
trabjadores.

Alternativa Ventaja Desventaja

Lector de huella - Precio - Solo administra
digital con - Se pueden generar bases de datos en
Phpmyadmin las bases de datos y MySQL
su administracin - Su cdigo se basa
en lnea principalmente en
- Puede trabajar con PHP
un gran nmero de - La cantidad de
leguajes de bases de datos
programacin. administradas se
- En intuitivo ven muy limitadas.
Lector de huella - Mayor flexibilidad - La utilidades
digital con MySQL en el manejo de usadas no estn
Worckbench 6.3 CE datos documentadas
- Es ms segura - No es intuitivo
esta alternativa, ya
que los datos solo
se manejan d
manera local y no en
lnea

11. Conclusiones del estudio de viabilidad y anlisis de riesgos

Reporte
Se observa que la alternativa numero 1 es la que ms se ajusta al
presupuesto, tanto de tiempo, economa y ventajas de los equipos tcnicos
utilizados, por tal motivo se considera factible y viable implementar este tipo
de mantenimiento en el sistema, que como habamos dicho, es
mantenimiento perfectivo, ya que busca agregar funcionalidad al sistema
existente, cabe mencionar que los riesgos encontrados en el proyecto, se
pueden controlar con facilidad por los miembros del equipo de desarrollo.