INGENIERÍA DE SOFTWARE

SEMANA 7
Etapa V: implantación
y
mantenimiento

Todos los derechos de autor son de la exclusiva propiedad de IACC o de los otorgantes de sus licencias. No está
permitido copiar, reproducir, reeditar, descargar, publicar, emitir, difundir, poner a disposición del público ni 1
ESTE
utilizarDOCUMENTO
los contenidos paraCONTIENE LAdeSEMANA
fines comerciales 7
ninguna clase.
 2
ESTE DOCUMENTO CONTIENE LA SEMANA 7
ÍNDICE

ETAPA V: IMPLANTACIÓN Y MANTENIMIENTO .................................................................................. 4

OBJETIVOS ESPECÍFICOS ........................................................................................................................... 4
INTRODUCCIÓN ...................................................................................................................................... 4
1. IMPLANTACIÓN .............................................................................................................................. 5
1.1. PLANIFICACIÓN DE LA IMPLANTACIÓN ............................................................................... 5
1.2. DESARROLLO DE LA IMPLANTACIÓN................................................................................... 6
1.3. CAPACITACIÓN .................................................................................................................... 7
2. MANTENIMIENTO ........................................................................................................................... 8
2.1. DEFINICIÓN.......................................................................................................................... 8
2.2. TIPOS DE MANTENIMIENTO ................................................................................................ 8
2.3. TÉCNICAS DE MANTENIMIENTO ......................................................................................... 9
2.4. VIABILIDAD DEL MANTENIMIENTO ................................................................................... 10
2.5. ADMINISTRACIÓN DEL MANTENIMIENTO ........................................................................ 11
2.6. EVALUACIÓN DE RESULTADOS, CORRECCIONES, ESTABILIZACIÓN .................................. 12
2.7. CONTROL DE CAMBIOS ..................................................................................................... 13
COMENTARIO FINAL.......................................................................................................................... 16
REFERENCIAS........................................................................................................................................ 17

3
ESTE DOCUMENTO CONTIENE LA SEMANA 7
ETAPA V: IMPLANTACIÓN Y MANTENIMIENTO

OBJETIVOS ESPECÍFICOS
 Utilizar el proceso de implantación dentro del desarrollo de un software.

 Analizar los procesos involucrados en la etapa de mantenimiento de un software.

INTRODUCCIÓN
Bienvenidos a la Semana 7 del Curso de Ingeniería de Software, semana en la cual se estudiará la
etapa V: implantación y mantenimiento.

En esta semana se tratará todo lo referente al proceso de implantación de un software, señalando

actividades como planificación, desarrollo y capacitación en un proceso de implantación, de
manera de facilitar la comprensión del desarrollo de un software.

Presentaremos una visión general de las etapas de mantenimiento de un software, explicando

detalladamente tipos, técnicas, viabilidad, administración del mantenimiento, así como la
evaluación y control de cambios que se producen en un proyecto de software.

4
ESTE DOCUMENTO CONTIENE LA SEMANA 7
1. IMPLANTACIÓN
Durante este proceso se deben considerar las tareas a realizar en conjunto con los factores que
afectan la puesta en marcha del sistema, considerando (Whitten & Bentley, 2008):

 Planificación de la implantación
 Desarrollo de la implantación
 Capacitación

La implantación puede ser bastante más difícil que las otras etapas, considerando que el proceso
de implantación es la última etapa de la metodología de desarrollo. Tanto en los procesos de
desarrollo como en los de pruebas, la dificultad dependerá de las características de la tecnología.

En el caso que sea un producto estándar la implementación puede ser relativamente fácil.
Pero cuando se trata de nuevas tecnologías, que no se han aplicado con anterioridad o son
sustancialmente diferentes a las prácticas previas, la implantación debe eser manejada de forma
cuidadosa y siempre prestando atención a los detalles del proceso.

Dentro de la estrategia de implantación deben ser detalladas las etapas necesarias para probar la
nueva tecnología en el plan de administración del proyecto (Whitten & Bentley, 2008).

1.1. PLANIFICACIÓN DE LA IMPLANTACIÓN

El proceso de planificación de la implantación es la última etapa del desarrollo del sistema. Aquí
son instalados equipos o software nuevos.

Cuando es implantado un sistema de información, debemos asegurarnos de que el sistema sea

operacional o que por lo menos funcione de acuerdo a las necesidades del análisis, permitiendo
que los usuarios puedan utilizarlo.

Whitten & Bentley (2008) plantean que existe una variedad de enfoques de implementación como
lo son:

 Otorgale responsabilidades a los grupos.

 Utilizar diversas herramientas y estrategias para la capacitación de los usuarios.

 El analista de sistemas debe ponderar la situación y lograr elaborar un plan de conversión

óptimo para la organización.

5
ESTE DOCUMENTO CONTIENE LA SEMANA 7
  El analista debe crear medidas de desempeño, con las que se puedan evaluar a los
usuarios.

 Se debe realizar la conversión física del sistema de información antiguo al nuevo.

En la preparación de implantación se debe considerar que, a pesar de que el sistema esté

desarrollado y diseñado de manera óptima, el éxito de este dependerá directamente de la
implantación y ejecución. Por lo antes mencionado es que se debe capacitar al usuario sobre el
uso y mantenimiento del sistema.

1.2. DESARROLLO DE LA IMPLANTACIÓN

Existen distintos planteamientos sobre el modo de implantación del nuevo sistema, dependiendo
del tipo de organización, el estado previo de la información y el nivel de los usuarios afectados.

Ahora bien, cuando el sistema está informatizado desde antes, se deben definir distintos
programas de conversión o planificar la ejecución en el calendario.

Por lo general, de distienguen tres enfoques de implentación y estos son (Carbajo, s. f.):

 Implantación directa: se detiene el sistema anterior y se pasa al nuevo sistema en una

fecha establecida y sin procesos paralelos de contraste de resultados.

 Implantación en paralelo: se mantienen en funcionamiento paralelo dos sistemas (nuevo

y antiguo) durante un periodo determinado de tiempo. Son controlados los resultados de
ambos sitemas y se realizan ajustes al nuevo.

 Implantanción en centro piloto: se realiza una selección de uno o más centros de

experimentación del sistema, de forma tal que el funcionamiento de este en las unidades
otorgue la información necesaria sobre fallas o falencias del sistema. Esto posee el
beneficio de necesitar menos recursos y si el o los centros escogidos son representativos,
entonces se puede lograr afinar el sistema en un alto porcentaje.

Los recursos requeridos para implementar el sistema son destinados a hacer la transición del
sistema antiguo al nuevo lo más cómoda posible.

Se debe planificar de forma detallada el calendario de instalación de los medios implicados en el

arranque del sistema, como el hardware, la instalación, materiales, entre otros.

Se debe tener en cuenta que la implantación del sistema debe tener una planificación y
organización de recursos, considerando al software como un recurso más.

6
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 1.3. CAPACITACIÓN
La capacitación es el enseñar y otorgar herramientas a los usuarios que están relacionados u
operan en el proceso de implantación. El responsable de llevar a cabo estas capacitaciones es el
analista, quien debe enseñar a usuarios primarios y secundarios. No deben ser incorporadas
personas con distinto nivel de habilidad e intereses de trabajo en un mismo grupo. Con esto se
quiere decir que no se pueden incluir en una misma sección trabajadores expertos e inexpertos,
debido a que esto no sería productivo para el grupo (Pressman, 2005).

Considerando que las empresas podrían contratar servicios de instructores externos, se considera
que el analista es la persona más preparada para realizar la capacitación, debido a que conoce al
personal y el sistema mejor que cualquier otro. Pressman (2005) menciona que de no poder
realizar la capacitación el analista, se puede contratar otros servicios, tales como:

 Vendedores: estos proporcionan capacitaciones gratuitas fuera de la empresa y estas

pueden tener una duración de uno o dos días.

 Instructor pagado externamente: enseñan todo acerca de computadoras, pero para

algunos usuarios estas capacitaciones no son necesarias.

 Instructores en casa: se encuentran familiarizados con el personal y pueden ajustar el

material a las necesidades de estos, sin embargo requieren experiencia en sistemas de
información, lo cual es sumamente necesario para los usuarios.

La capacitación se enfoca en que los usuarios del sistema posean el dominio requerido básico de
las maquinarias y procesos que se aplican para su operación de manera óptima y segura.

Considerando que las empresas no funcionan solas, es decir, necesitan personal que las operen,
estas deben tener personal que utilice y cuide la tecnología que posee la empresa, razón por la
cual todo el personal debe realizar una capacitación de acuerdo con sus necesidades. Ahora, la
capacitación variará dependiendo de la dificultad de la tecnología que sea utilizada y el nivel de
interacción con esta.

Posterior a la capacitación el personal de igual forma requerirá apoyo continuo. Existiran varias
ocaciones en las cuales el usuario necesitará asistencia con algún problema cotidiano.

7
ESTE DOCUMENTO CONTIENE LA SEMANA 7
2. MANTENIMIENTO
El mantenimiento es un proceso bastante costoso, largo y por supuesto importante en la vida de
una aplicación informática. Su importancia radica en su extensa duración, la cual garantiza que la
aplicación funcione óptimamente (Sommerville, 2012).

2.1. DEFINICIÓN
Cuando se habla del proceso de mantenimiento del software, se hace referencia al cambio del
sistema posterior a su entrega.

El término aplica generalmente al software a medida, en el cual distintos grupos de desarrollo se

involucran antes y después de la entrega.

Los cambios que se llevan a cabo en el software; pueden ser sencillos como la corrección de fallas
de código, cambios más extensos de corregir como fallas en el diseño o bien pueden ser
modificaciones significativas como la corrección de una falla de especificación o el acomodar
nuevos requerimientos.

Un cambio es llevado a cabo mediante la modificación de componentes del sistema o bien

incorporando nuevos componentes donde se requiera.

2.2. TIPOS DE MANTENIMIENTO

Ian Sommerville (2012) plantea que los distintos tipos de mantenimiento del software son:

 Mantenimiento para reparar defectos del software: en general, la corrección de las fallas
de código no son costosas, en cambio las fallas de diseño suelen ser más caras. Esto se
debe a que se reescriben varios componentes de los programas. Ahora bien, las fallas de
requerimientos son bastante más costosas de reparar, ya que en algunos casos es
necesario un extenso rediseño de sistema.
 Mantenimiento para adaptar el software a diferentes entornos operativos: este
mantenimiento es utilizado cuando hay un cambio en el entorno del sistema, y se intenta
la adaptación del sistema a los cambios. Por ejemplo, el hardware, la plataforma del
sistema operativo o algún otro sistema de soporte.
 Mantenimiento para añadir o modificar las funcionalidades del sistema: este
mantenimiento es llevado a cabo cuando las necesidades del sistema sufren cambios,
debido a modificaciones organizacionales o del negocio.

Cuando esto es llevado a la práctica, no se logra visualizar de forma clara la distinción entre los
tipos de mantenimiento.

8
ESTE DOCUMENTO CONTIENE LA SEMANA 7
En la adaptación del sistema a un nuevo entorno, se le pueden incorporar funcionalidades con el
fin de sacar el mayor provecho a las nuevas características del entorno.

En gran parte de los casos las fallas del software son detectadas por el uso del sistema por parte
de los usuarios en formas no previstas. La manera óptima de reparación de fallas es la realización
de modificaciones en el sistema que se adapten a su manera de trabajo.

Los tipos de mantenimiento pueden ser reconocidos con distintos nombres, como por ejemplo el
mantenimiento correctivo, que se refiere a la reparación de defectos. En algunos casos el
mantenimiento adaptativo hace referencia a la adaptación a un nuevo entorno o a la adaptación
del software a nuevas necesidades. En el caso del mantenimiento perfectivo, puede significar la
perfección el software implementado nuevas necesidades, como también la mantención de la
funcionalidad del sistema, mediante la mejora de su estructura y rendimiento.

2.3. TÉCNICAS DE MANTENIMIENTO

Dentro de la ingeniería del software se generan soluciones técnicas que permiten abordar el
mantenimiento del sistema, de modo que el costo que este tenga dentro del ciclo de vida sea el
menor.

Tipos de soluciones técnicas (Sommerville, 2012):

 Ingeniería inversa: es el análisis del sistema, con el fin de identificar los componentes y
las relaciones entre ellos, para crear representaciones del sistema en un nivel de
abstracción más alto.

 Reingeniería: es la modificación del software o de algunos componentes, utilizando para

el análisis del sistema técnicas de ingeniería inversa y en la etapa de reconstrucción se
usan herramientas de ingeniería directa, de forma tal que el cambio tienda a facilitar el
mantenimiento, reutilización, comprensión o evolución.
 Reestructuración del software: es el cambio de representación del software, dentro del
mismo nivel de abstracción.

Estas técnicas están enfocadas en la entrega de métodos para la reconstrucción del software, ya
sea por medio de una reprogramación, redocumentación, rediseño o rehacer alguna(s)
característica(s) del software.

Lo que diferencia las soluciones antes dadas es cuál es el origen y cuál es el destino de las mismas
(producto inicial y/o producto final).

Ahora bien, gráficamente, las soluciones técnicas se enmarcan en el ciclo de vida de la siguiente
forma:

9
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 Relaciones entre los términos asociados con la reingeniería
(Fuente: http://goo.gl/3S7UqV)

Cuando se desarrolla el software de manera tradicional, se está hablando de ingeniería directa.

Cuando se habla del proceso de análisis del sistema con el fin de identificar sus interrelaciones y
componentes, creando representaciones del sistema en otras formas, estamos frente a la
ingeniería inversa. Y por último, la reingeniería es el examen y alteración del sistema con el fin de
reconstruirlo de una nueva forma.

La reestructuración es el cambio del software, atendiendo a facilitar su entendimiento y cambio.

Estas técnicas pueden ser utilizadas en cualquier fase del ciclo de vida.

2.4. VIABILIDAD DEL MANTENIMIENTO

El estudio que se realiza en la viabilidad del mantenimiento otorga diversas alternativas de
restauración, considerando los estudios de debilidades y fortalezas de las tecnologías. También
brinda criterios utilizados en la selección de una alternativa por encima de las otras.

Durante el proceso de investigación de restauración se desarrollan y analizan alternativas, como

también se establecen metas de restauración, las cuales se van afinando conforme la información
de este proceso está disponible.

En el estudio que realiza la viabilidad se establecen las factibilidades técnicas y de presupuesto

para alcanzar el objetivo de la restauración ambiental, es decir, quitar, reducir o controlar los
tóxicos en el sitio de estudio, con el fin de que no representen un riesgo mayor para la salud
pública que los socialmente aceptados.

10
ESTE DOCUMENTO CONTIENE LA SEMANA 7
El estudio de viabilidad se compone de las siguientes partes (Sommerville, 2012):

 Establecimiento de los objetivos de la restauración.

 Desarrollo de alternativas de restauración.
 Selección preliminar de las alternativas tecnológicas.

Por lo general, en los estudios de proyectos se encuentra la denominación “factibilidad técnica

económica”, como título de un informe final de evaluación de un proyecto de inversión.

En lo cotidiano son utilizados indistintamente los términos viabilidad y factibilidad; es necesario

establecer la diferencia entre estos, la factibilidad es una etapa del ciclo del proyecto que posee
repercusiones importantes en los procedimientos y alcances que determinan en el trabajo del
evaluador.

2.5. ADMINISTRACIÓN DEL MANTENIMIENTO

En el proceso de administración del mantenimiento se contempla la corrección de fallas no
detectadas en fases anteriores del ciclo de vida, la optimización de la implementación de las
unidades del sistema y alza de los servicios del sistema a medida que se descubren más
necesidades.

Las grandes fallas de mantenimiento suelen ser administrativas y técnicas. Ahora bien, los
problemas claves de la administración son (Sommerville, 2012):

 Alineación con las prioridades del cliente.

 Dotación de personal, cuál organización hace mantenimiento.

 Estimación de costos.

 Limitado entendimiento.

 Análisis de impacto.

 Pruebas.

 Medición de mantenibilidad.

Las actividades que incluye la administración del mantenimiento de software son:

 La corrección de errores.

 Mejoras de las capacidades.

 Eliminación de funciones obsoletas y optimización.

11
ESTE DOCUMENTO CONTIENE LA SEMANA 7
Considerando que los cambios son inevitables, son creados mecanismos de evaluación, control y
posterior modificación. Los cambios que sean realizados en el software después de este estar
operando se consideran trabajo de mantenimiento.

El enfoque es preservar el valor que tiene el software en el tiempo.

El valor puede ser optimizado a medida que se amplía la base de clientes, se alcanzan requisitos
adicionales, se facilita el uso, la eficiencia y se hace uso de nuevas tecnologías. El mantenimiento
puede llegar a 20 años, en cambio el desarrollo puede darse entre 1 y 2 años.

2.6. EVALUACIÓN DE RESULTADOS, CORRECCIONES, ESTABILIZACIÓN

El mantenimiento del software consume una gran parte del presupuesto del TI (se consumen
aproximadamente dos tercios en mantenimiento y uno en desarrollo).

Gran parte del presupuesto de mantenimiento es destinado a la implementación de nuevos

requerimientos y no a la reparación de bugs. Estos porcentajes varían de una empresa a otra.

La reparación de errores en el desarrollo del sistema no es lo más costoso de las actividades

realizadas por mantenimiento. La evolución del sistema para el enfrentamiento de otros entornos
y necesidades nuevas o cambiantes consume un mayor esfuerzo del mantenimiento.

Suele ser óptimo en costos derivar esfuerzos en el diseño e implementación del sistema, todo esto
con el fin de minimizar gastos en cambios futuros.

Añadir nuevas funciones posteriores a la entrega es bastante costoso debido a que consume
tiempo aprender el funcionamiento del sistema y analizar el impacto en los cambios de
presupuesto.

Sin embargo, el trabajo que se realiza a lo largo del desarrollo del software es más fácil de
comprender y cambiar, reduciendo los costos de evolución.

El enfoque principal del mantenimiento es confirmar el óptimo rendimiento de una aplicación y las
funciones de este son (Sommerville, 2012):

 Corregir defectos: en el momento que son encontradas fallas en el sistema, se procede a

la corrección. Esta es la función más extensa y suele ser considerada por algunos autores
como mantenimiento.

 Mejorar el rendimiento: se enfoca en que las aplicaciones funcionen de manera óptima y

eficaz, es decir, que el rendimiento de estas sea el mejor.

12
ESTE DOCUMENTO CONTIENE LA SEMANA 7
  Adaptar el sistema o la aplicación a un entorno cambiante.

2.7. CONTROL DE CAMBIOS

El control de cambios es considerado la actividad de gestión de configuración con mayor
relevancia, cuyo enfoque es establecer un mecanismo estricto de control de cambios,
comenzando desde la base de que los cambios se producirán. Generalmente mezcla
procedimientos humanos y herramientas automáticas.

Pressman (2005) menciona que existen dos tipos de cambios fundamentales:

 Corrección de un defecto: comúnmente los clientes catalogan todos los cambios en este
ítem.

 Mejora del sistema: comúnmente los programadores catalogan en este punto.

Como forma de solución del problema de determinar de qué tipo es un cambio, es relevante la
trazabilidad de los requisitos. Generalmente se establecen varios niveles de control de cambio
(Pressman, 2005):

 Control de cambios informal: previo a que el elemento de configuración del software

forme parte de la línea base, la persona que desarrolló el elemento de configuración del
software puede realizar cambios justificado en él.

 Control de cambios al nivel del proyecto o semiformal: al pasar la revisión técnica formal
el elemento de configuración del software pasa a convertirse en una línea base. El
encargado del desarrollo puede realizar cambios si posee la aprobación de:

 El comité de control de cambios: el cambio causa impacto sobre otros elementos de

configuración del software.

 Control de cambios formal: comienza a funcionar cuando se comercializa el producto,

en otras palabras, cuando se transfieren los ECS a la Biblioteca Maestra. Los cambios
deben ser aprobados por el comité de control de cambios.

Pressman (2005) plantea que en una correcta detección de controles de cambios de

requerimientos de las organizaciones de desarrollo de software se identifican las siguientes
actividades:

 Análisis de la solicitud: al recibir la solicitud del cliente interno o externo, esta debe ser
analizada por el líder de la implementación. Los puntos de análisis relevantes son el

13
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 alcance y el tiempo, todo esto con el fin de identificar si la solicitud es viable para ser
realizada sobre el mismo requerimiento o si de lo contrario sería mejor manejarla como
un requerimiento nuevo. El análisis realizado con respecto al alcance debiera tener ayuda
de las áreas involucradas en la solicitud, para determinar de manera clara el impacto y los
elementos que se ven afectados por ella.

 Valorar el cambio: se debe establecer la factibilidad de la solicitud ya sea por un cliente

interno o uno externo. Para esto se deben tomar en cuenta todos los requisitos
observando el impacto del cambio. Es en este punto donde entra la trazabilidad de los
requisitos.

 Analizar modificación: el análisis de la solicitud debe ser llevado a cabo por el líder de la
implementación, todo esto con el fin de tener noción del impacto de la modificación y
establecer puntualmente las modificaciones solicitadas que afectan el requerimiento
completo.

 Documentar cambio: a modo de mantener un mayor control de los cambios solicitados se

recomienda realizar una clara documentación, evitando ambigüedades en las
modificaciones que serán realizadas a los requerimientos. Esto también se centra en
mantener un control de las modificaciones realizadas en el documento de requerimiento,
para de esta forma mantener informado al equipo de trabajo y clientes sobre qué
actualizaciones han sido realizadas sobre los documentos, cuál fue el motivo del cambio y
quién lo aprobó.

Aprobación de control de cambios:

 Aprobar cambios: posterior al análisis de impacto del cambio, se procede a tomar una
decisión. De ser aceptado el cambio, tras negociar con el cliente se continúa con la
implementación de dicho cambio. De lo contrario, se negocia con el cliente el siguiente
paso a realizar.

 Planear cambio: posterior a la aprobación formal del cambio aprobado se planifica el

tiempo que se requerirá y los recursos necesarios para realizar dicho cambio.

 Realizar cambio: una vez planeado el cambio aprobado se procede a realizar las
modificaciones necesarias en los productos involucrados.

 Revisar cambio: una vez que el cambio fue realizado se debe llevar a cabo una verificación
para identificar que el requerimiento incorpore todas las modificaciones establecidas y
que estas hayan sido aprobadas.

14
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 Actualizar línea base: se considera recomendable el uso del nuevo requerimiento como
línea base, todo lo cual se realiza con el fin de trabajar siempre con la última versión del
requerimiento.

 Informar: al ser realizada la modificación, esta debe ser informada a los interesados en el
cambio, de modo que el cliente pueda verificarlo.

 Entregable control de cambios: como se mencionó antes, es importante hacer uso del
documento que apoye a la identificación de la solicitud, realizada por los clientes tanto
externos como internos. La documentación no puede ser ambigua y debe ser validada por
ambas partes, es decir, el cliente y la empresa.

15
ESTE DOCUMENTO CONTIENE LA SEMANA 7
COMENTARIO FINAL

Una de las principales causas de crisis de software es la etapa de mantenimiento en el ciclo de

vida. Esta herramienta administra las etapas, documentos y el software involucrado en cada
requerimiento de cambio minimizando y controla los efectos del mantenimiento.

Los beneficios otorgados por la herramienta de administración automatizada de mantenimiento

son fáciles de evaluar ante los cambios perfectivos o adaptativos.

La administración de un cambio correctivo se supone que es bastante burocrática ante el

requerimiento de una respuesta inmediata. Ahora bien, la herramienta previene este tipo de
casos.

Frente a un cambio correctivo respaldado por el controlador de cambios, la herramienta antes

mencionada automáticamente acorta los plazos para el análisis del mismo. El consejo de control
debe entregar un plan de actividades que concuerde con la rapidez de la solución del cambio.

16
ESTE DOCUMENTO CONTIENE LA SEMANA 7
REFERENCIAS
Carbajo, F. (s. f.). Gestión, implantación y mantenimiento de proyectos software. En: Análisis y
diseño detallado de aplicaciones informáticas de gestión (1º DAI). Consultado el 25 de mayo
de 2015 en http://goo.gl/BA2ZfB.

Pressman, R. (2005). Ingeniería de Software. 6.ª edición. México: MacGraw-Hill Interamericana.

Sommerville, I. (2012). Ingeniería de Software. 9.ª edición. México: Pearson.

Whitten, J. & Bentley, L. (2008). Análisis de Sistemas. 7.ª edición. México: MacGraw-Hill
Interamericana.

PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:

IACC (2015). Etapa V: implantación y mantenimiento. Ingeniería de Software. Semana 7.

17
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 18
ESTE DOCUMENTO CONTIENE LA SEMANA 7