Guia TI 8A Gestión de Software

GUÍA DIDÁCTICA
DOCENTE
GESTIÓN DE SOFTWARE
NIVEL: OCTAVO
CARRERA: TECNOLOGÍAS
DE LA INFORMACIÓN
TUTOR: ING. JAVIER

MENDOZA LOOR,
MGS.
SEDE SANTO DOMINGO DE

LOS TSÁCHILAS – LA
CONCORDIA
2021 – IS
UNIVERSIDAD TÉCNICA LUIS VARGAS TORRES DE
ESMERALDAS SEDE SANTO DOMINGO DE LOS TSÁCHILAS –
LA CONCORDIA
GUIA DIDÁCTICA DOCENTE DE PROGRAMACIÓN IV
PERIODO ACADÉMICO: 2020 – 1S (AGOSTO 2020 – DICIEMBRE 2020)
DATOS INFORMATIVOS
Facultad: Ingenierías. Carrera: Tecnologías de la información
Asignatura: Gestión de Software Código: TICSI223837
Nivel académico: Octavo Profesor: Ing. Javier Mendoza Loor, Mgs.
Email: [email protected] Contacto telefónico: 0993991076
INDICE DE CONTENIDOS
DETALLE DEL CONTENIDO Y METODOLOGÍA DE CONSTRUCCIÓN DE LA GUÍA 1
INTRODUCCIÓN.......................................................................................................................1
OBJETIVO GENERAL...............................................................................................................2
Conocer los conceptos de gestión de software para llevar a cabo las actividades de
planificación, organización de las aplicaciones, componentes de software, ejecución y control
del desarrollo de proyectos software............................................................................................2
UNIDAD I: Componentes de la gestión de Software...................................................................2
1.1 Introducción.............................................................................................................2
1.2 Clasificación del Software........................................................................................3
1.2.1 Software de sistema..............................................................................................3
1.2.2 Software de aplicación..........................................................................................4
1.2.3 Software de programación....................................................................................5
1.3 Gestión de Inventario de Software............................................................................6
1.3.1 ¿Por qué hacer un inventario de software?...........................................................6
1.3.2 ¿Cómo hacer un inventario de software?..............................................................7
1.3.3 Contrastar la información de los inventarios.........................................................8
1.3.4 Recopilar la información de los derechos de uso..................................................9
1.3.5 Información complementaria para conformar el inventario..................................9
1.4 Gestión de licencias y parches................................................................................10
1.4.1 Gestión de licencias de software.........................................................................11
1.4.2 Gestión de parches para sistemas operativos......................................................11
1.4.3 ¿Por qué es tan importante la gestión de licencias y parches?.............................12
1.4.4 ¿Cómo es un proceso de Gestión de Parches eficaz?..........................................13
1.4.5 Mejores prácticas de gestión de parches.............................................................15
1.5 Software como servicio (SaaS)...............................................................................16
1.5.1 ¿Qué es Software as a Service?..........................................................................16
1.5.2 Requisitos, Costo – Beneficios...........................................................................16
1.5.3 Soluciones de tecnologías SaaS..........................................................................17
UTELVT. 2021 IS – Ing. Javier Mendoza Loor, Mgs.

LA CONCORDIA
1.5.4 Softwares hospedados.........................................................................................18
1.5.5 Cómo alcanzar el éxito con el SaaS....................................................................20
1.6 Control de versiones del software...........................................................................20
1.6.1 ¿Qué es el control de versiones?.........................................................................20
1.6.2 Ventajas de los sistemas de control de versiones................................................22
1.6.3 ¿Qué es el Git?....................................................................................................24
1.6.4 Herramientas Git.................................................................................................24
1.6.4.1 Clientes Git GUI para Linux...............................................................................24
1.6.4.2 Clientes Git para Windows.................................................................................25
1.6.4.3 Clientes Git multiplataforma...............................................................................26
1.7 Despliegue y distribución de software....................................................................28
1.7.1 ¿En qué consiste el despliegue de Software?......................................................28
1.7.2 Servicios de despliegue.......................................................................................28
1.7.3 ¿Qué significa la distribución de software?........................................................28
1.7.4 Distribución automatizada de software...............................................................29
1.8 Empaquetado de software.......................................................................................29
1.8.1 ¿Qué es el empaquetado de aplicaciones?...........................................................29
1.8.3 Software personalizado.......................................................................................31
1.8.4 Diferencia entre Software empaquetado y software personalizado.....................31
1.8.5 Empaquetado de software corporativo................................................................32
1.8.6 Ejemplos de paquetes de software......................................................................32
Laboratorio de la unidad 1..................................................................................................34
Trabajo grupal autónomo de investigación de la unidad 1..................................................34
UNIDAD II: Planificación de proyectos de Software.................................................................35
2.1 Introducción............................................................................................................35
2.2 Objetivos de la Planificación de Proyectos de Software.........................................35
2.2.1 Principios y consideraciones para la Planificación..............................................35
2.3 Ciclo de Planificación de Proyectos de Software....................................................36
2.3.1 Negociación de Compromisos............................................................................37
2.3.2 Descomposición de Requerimientos...................................................................37
2.3.3 Estimación del Tamaño de un producto de Software..........................................37
2.3.4 Desarrollo de Itinerario del Proyecto..................................................................37
2.3.5 Término de fase y/o actividades..........................................................................37

LA CONCORDIA
2.3.6 Generación y entrega de productos.....................................................................37
2.3.7 Puntos de control o Hitos del proyecto...............................................................38
2.3.8 Estimación de Recursos......................................................................................38
2.4 Plan del proyecto de desarrollo de Software...........................................................38
2.4.1 ¿Para qué se usa el plan del proyecto?................................................................39
2.5 Fallas en la Planificación........................................................................................39
2.6 Especificación de Requerimientos..........................................................................40
2.6.1 Principios para una buena especificación............................................................41
2.6.2 Terminología y modelo de referencia para el ciclo de vida del Software............42
2.6.3 Especificación del Software................................................................................44
2.7 Procesos y productos del ciclo de vida...................................................................44
Laboratorio de la unidad 2..................................................¡Error! Marcador no definido.
UNIDAD III: Mediciones en producto y proceso de Software...................................................49
3.1 Introducción............................................................................................................49
Trabajo individual autónomo de investigación unidad 3....................................................49
Trabajo grupal de Investigación Unidad 3..........................................................................49
Laboratorio de la Unidad 3.................................................................................................49
UNIDAD IV: Aseguramiento de la calidad del Software...........................................................49
4.1 Introducción............................................................................................................49
Laboratorio Unidad 4.........................................................................................................49
Trabajo grupal de investigación Unidad 4..........................................................................49
Rúbrica 1: Para informe de investigación...................................................................................50
Rúbrica 2: Para evaluar actividad de laboratorio........................................................................51
Rúbrica 3: Para evaluar actividades grupales.............................................................................52

LA CONCORDIA
DETALLE DEL CONTENIDO Y METODOLOGÍA DE CONSTRUCCIÓN DE LA GUÍA

Estimado/a estudiante, la metodología que utilizaremos en la guía didáctica, implica su
participación activa con la guía del docente, de manera flexible de acuerdo a la
realidad de cada uno de ustedes. Se construye la guía didáctica en base a los
contenidos del silabo planificado de acuerdo a la asignatura. (Leer el silabo entregado
por el docente)
● CONTENIDOS
Los mismos son obtenidos de la unidad que consta en el silabo y además la
planificación correspondiente realizada para las temáticas a impartir según
considere el docente.
● TRABAJO AUTÓNOMO DE INVESTIGACIÓN
Trabajo que realizará cada estudiante después de las tutorías virtuales según lo
indique el docente.
● LABORATORIOS A DESARROLLAR
Se desarrollan Laboratorios en cada unidad.
● RÚBRICA CON LA QUE SE EVALUARÁ SU TRABAJO
Establecido por la comisión de las áreas pertinentes, para la evaluación a los
estudiantes.
INTRODUCCIÓN
La asignatura corresponde a la unidad de formación profesionalizante, al campo de
formación de la praxis profesional, de carácter teórico – práctico, para los estudiantes
de la carrera de Tecnologías de la Información, tiene como propósito conocer la
gestión de Software, planificación, organización de las aplicaciones y componentes de
software disponibles en la infraestructura de TI. Esto incluye, la planificación de
proyectos de software, mediciones en producto y proceso de software, aseguramiento
de la calidad del software.
Dada la complejidad de la gestión de software en la infraestructura de TI, se hacen

necesarios paradigmas y metodologías que puedan seguir de manera sistemática hasta
llegar a la correcta finalización. Entre ellos, los procesos de gestión inventario, gestión
de Inventario de software, gestión de licencias o parches, software como servicio,
control de versiones del software, despliegue de software, empaquetado de software,
identificación de las brechas de seguridad o los procesos de instalación automatizados
y estandarizados, control del software de extremo a extremo, garantizar que todos los
activos y clientes han sido revisados en busca de amenazas, están actualizados con la
última versión y cumplen con las políticas de activos de la empresa.
UTELVT. 2021 IS – Ing. Javier Mendoza Loor, Mgs. Pág. 1

OBJETIVO GENERAL
Conocer los conceptos de gestión de software para llevar a cabo las actividades de
planificación, organización de las aplicaciones, componentes de software, ejecución y
control del desarrollo de proyectos software.
UNIDAD I: Componentes de la gestión de Software.
1.1 Introducción
Gestión de Software es la gestión, planificación y organización de las aplicaciones

y componentes de software disponibles en su infraestructura TI. Esto incluye, por
ejemplo, los procesos de inventario, la identificación de las brechas de seguridad
o los procesos de instalación automatizados y estandarizados. La gestión de
licencias o parches también forma parte del control del software de extremo a
extremo. Garantiza que todos los activos y clientes han sido revisados en busca
de amenazas, están actualizados con la última versión y cumplen con las políticas
de activos de TI. (Deskcenter, 2021)
Figura 1: Gestión de Software
La seguridad también desempeña un papel importante en el ámbito del control

del software. Los procesos de instalación estandarizados, los distintos conceptos
de derechos y roles o el registro y análisis de las versiones existentes y los niveles
de parches evitan, por ejemplo, los accesos no autorizados y los ataques de
hackers, y forman parte de la gestión de riesgos de extremo a extremo.
Los responsables de TI suelen tener un presupuesto limitado. Una administración

de software inteligente y holística puede ahorrar costos de forma inteligente; el
software que no se utiliza puede identificarse inmediatamente y los activos caros
pueden filtrarse automáticamente.
Demasiadas cosas que hacer y poco tiempo. Esa es la típica jornada de trabajo de
un responsable de TI. El control inteligente del software aumenta su
productividad y eficiencia y ahorra tiempo al automatizar los procesos y
estandarizar los flujos de trabajo. Los resultados de las tareas terminadas
pueden documentarse fácilmente.
La correcta gestión de software es clave para la satisfactoria conclusión del

mismo, empezando desde las etapas iniciales de planificación, pasando por la
identificación de requisitos, el estudio de recursos, el uso de las adecuadas
metodologías de producción y desarrollo, ejecución y codificación, y finalmente
el mantenimiento de estos a lo largo del periodo de tiempo requerido para el
proyecto o acordado con el cliente.
1.2 Clasificación del Software
La palabra Software traducida literalmente seria: partes blandas o suaves de la

computadora en contraposición al hardware (partes duras) El software es
entonces el conjunto de los componentes lógicos necesarios que hacen posible la
realización de tareas específicas. Los componentes lógicos incluyen, entre
muchos otros, las aplicaciones informáticas; tales como el procesador de texto,
que permite al usuario realizar todas las tareas concernientes a la edición de
textos; el software de sistema, tal como el sistema operativo, que, básicamente,
permite al resto de los programas funcionar adecuadamente, facilitando también
la interacción entre los componentes físicos y el resto de las aplicaciones, y
proporcionando una interfaz amigable con el usuario. (Tecnologia e Informatica,
2021) Se puede clasificar en:
 Software de sistema.
 Software de aplicación.
 Software de programación.
1.2.1 Software de sistema
Su objetivo es desvincular adecuadamente al usuario y al programador de los

detalles del sistema informático en particular que se use, aislándolo
especialmente del procesamiento referido a las características internas de:
memoria, discos, puertos y dispositivos de comunicaciones, impresoras,
pantallas,
teclados, etc. El software de sistema le proporciona al usuario y programador
adecuadas interfaces de alto nivel, herramientas y utilidades de apoyo que
permiten su mantenimiento. (Tecnologia e Informatica, 2021) Incluye entre
otros:
 Sistemas operativos (Windows, Linux, MacOS)
 Controladores de dispositivos (Drivers, Codecs)
 Herramientas de diagnóstico (Everest, Antivirus)
 Herramientas de Corrección y Optimización (Ccleaner)
 Servidores (FileZilla, WampServer)
 Utilidades (RedoBackup)
Figura 2: Software de Sistema
1.2.2 Software de aplicación
Es aquel que permite a los usuarios llevar a cabo una o varias tareas específicas,
en cualquier campo de actividad susceptible de ser automatizado o asistido, con
especial énfasis en los negocios. (Tecnologia e Informatica, 2021) Incluye entre
otros:
 Aplicaciones ofimáticas (Office, OpenOffice)
 Software educativo (Hot Potatoes, Jclic, Moodle, Dokeos, Prezi)
 Software empresarial (ERP, CRM)
 Bases de datos (Oracle, Mysql, sqlserver)
 Telecomunicaciones (por ejemplo Internet y toda su estructura lógica,
Skype, Messenger)
 Software médico (Historia Clinica Digital)
 Software de Cálculo Numérico y simbólico (Matlab, Matematica)
 Software de Diseño Asistido (Corel, AutoCad,PhotoShop)
 Aplicaciones para Control de sistemas y automatización industrial
 Software de Control Numérico (CAM)
Figura 3: Software de Aplicación
1.2.3 Software de programación
Un software de programación es el conjunto de utilidades y herramientas

utilizadas para el desarrollo, programación o creación de programas o
aplicaciones informáticas por parte de los programadores. Dichas utilidades y
herramientas pueden hacer uso de diversos lenguajes de programación y
metodologías de desarrollo a través de, como mínimo, un editor de texto y un
compilador. Es el conjunto de herramientas que permiten al programador
desarrollar programas informáticos, usando diferentes alternativas y lenguajes
de programación, de una manera práctica. (Tecnologia e Informatica, 2021)
Incluye entre otros:
 Compiladores
 Intérpretes
 Enlazadores
 Depuradores
 Entornos de Desarrollo Integrados (IDE): Agrupan las anteriores
herramientas, usualmente en un entorno visual, de forma tal que el
programador no necesite introducir múltiples comandos para compilar,
interpretar, depurar, etc. Habitualmente cuentan con una avanzada
interfaz gráfica de usuario (GUI).
Figura 4: Software de programación
1.3 Gestión de Inventario de Software
El desconocimiento del software instalado en las empresas es un problema

mucho más frecuente de lo que solemos pensar. ¿Manejamos adecuadamente
nuestros inventarios? ¿Controlamos toda licencia de software existente en
nuestra empresa? ¿Tenemos un buen control de stock disponible?
Una respuesta afirmativa a las anteriores cuestiones pasa por disponer de una
correcta gestión de inventarios. Además de repercutir favorablemente en el
presupuesto, evitará numerosos problemas en el caso de recibir alguna auditoría
de cualquier fabricante. Pero hay dos preguntas iniciales que responder antes
que cualquier otra: ¿por qué hacer un inventario de software? Y, ¿cómo hacer un
inventario de software? (Evergreen, 2020)
1.3.1 ¿Por qué hacer un inventario de software?
“Conozco perfectamente todo el software instalado en mi empresa”. “Como

mis usuarios no son administradores de sus ordenadores, solo pueden utilizar lo
que les he instalado”. “Mi equipo de Administradores de Sistemas es muy
profesional, confío plenamente en él”.
Es habitual escuchar estas frases en incontables organizaciones, siempre dichas

desde el más absoluto convencimiento y confianza. Por desgracia, la realidad
más habitual es que en las empresas hay mucho más software instalado del que
imaginamos. Y para saber cómo hacer un inventario de software adecuado, hay
que tenerlo en mente. Así pues, existen múltiples razones por las que se puede
llegar a tener software no controlado:
 Entornos de prueba que no se gestionan con el mismo rigor que los
productivos.
 Migraciones o actualizaciones de productos.
 Cambios de equipamiento entre distintos usuarios.
 Pruebas temporales de productos.
 Diseño no óptimo de las autorizaciones en los sistemas.
 Pruebas de concepto para el desarrollo de software
Como consecuencia de lo anterior, pueden existir productos que han quedado
“olvidados” en los sistemas. Asimismo, estos productos pueden haberse
instalado sin que el responsable correspondiente tenga conocimiento de ello. Y
esta situación es ideal para algunos fabricantes que basan gran parte de su
actividad comercial en auditorías agresivas, como Oracle, IBM, SAP, Micro Focus,
Microsoft, Software AG, VMware - Dell, McAfee, Adobe, Autodesk, BMC o TIBCO.
En consecuencia, cuando una empresa llega al convencimiento de la necesidad
de recopilar información acerca del software instalado y tener un óptimo control
de inventarios, tiene que resolver la siguiente cuestión: ¿cómo hacer un
inventario de software? El concepto resulta similar, en cierto modo, a un control
de almacén con su correspondiente software. (Evergreen, 2020)
1.3.2 ¿Cómo hacer un inventario de software?
No se puede abordar la problemática acerca de cómo hacer un inventario de

software sin tener en cuenta los diferentes ámbitos que existen. Resulta habitual
apoyarse en una herramienta de inventario de hardware y software (con
funcionalidades de Network Discovery, Network Inventory, Network Monitor,
Asset Tracking, Inventory Software, etc.). Aquí empieza nuestra primera elección:
¿centrarse en análisis de servidores o en análisis de puestos de trabajo?
Si bien generalmente los puestos de trabajo tienen un sistema operativo
estándar (Windows, Linux o Mac OS), en el mundo de los servidores podemos
encontrar soluciones “propietarias” que restringen las posibilidades de
elección del software de inventario. La siguiente elección será escoger entre un
programa de inventario cuyo funcionamiento se base en agentes o que funcione
sin ellos. Generalmente, podemos dar por supuesto que las herramientas
basadas en agentes proporcionan una mayor inmediatez para obtener la
información. Cuando se
instala, desinstala o se modifica un producto existente, éstos informan de la
variación ocurrida.
Figura 5: Gestión de inventario de Software
En cambio, con las herramientas sin agentes, es necesario ejecutar un

“descubrimiento” o “escaneo” para obtener la información y saber bien
cómo hacer un inventario de software. Pero la rapidez de las herramientas
basadas en agentes se contrarresta con la problemática derivada de instalar los
propios agentes. ¿Están instalados en todos los equipos, incluidos los de prueba,
desarrollo, test, etc.? ¿Está actualizada su configuración? Un fallo en este
componente puede generar una situación negativa si se presenta un fabricante
para ejecutar una auditoría.
Igualmente, otra elección que debemos llevar a cabo es entre programas para
inventarios que solo realicen inventarios de lo existente u otra herramienta que
permita contrastar la información de los inventarios con las licencias adquiridas.
(Evergreen, 2020)
1.3.3 Contrastar la información de los inventarios
Tener un buen control de inventarios con el software de gestión de inventarios

que se hubiera seleccionado, es solo resolver la primera parte del problema. En
consecuencia, podemos tener una gestión de inventarios excelente, obtenidos
con la mejor aplicación de inventario y, aunque ésta permita conocer todo el
software instalado y tener un inventario de red completo, podría no resolver el
problema principal.
En realidad, este problema consiste en asegurar que nuestra empresa utiliza
correctamente el software instalado. De este modo, ante una auditoría no habrá
ningún riesgo que se traduzca en una elevada reclamación económica. Así, para
determinar cómo hacer un inventario de software que sea lo más útil posible.
Por tanto, la información del inventario se debe completar con los datos sobre
las licencias adquiridas por nuestra organización, e incluso con las licencias de
software libre utilizadas. Es decir, con los derechos de uso de software efectivos
que pueden disfrutar nuestros usuarios. (Evergreen, 2020)
1.3.4 Recopilar la información de los derechos de uso
Muchas veces resulta terriblemente complejo recopilar esta información. Hay

muchos motivos por los que su localización es complicada o, a veces,
directamente imposible. A continuación señalamos algunos ejemplos a tener en
cuenta para saber cómo hacer un inventario de software:
 Adquisiciones realizadas hace muchos años.
 Compras gestionadas por personas que ya no están en la empresa.
 Derechos de uso provenientes de otras empresas pertenecientes al
mismo grupo empresarial.
 Licencias procedentes de empresas con las que se ha producido una fusión.
 Derechos de uso adquiridos conjuntamente o dentro de la licencia de
software de otro producto.
Existen otras muchas situaciones que convierten la tarea de recopilar la
información de los derechos de uso en un proceso arduo, complicado y, a veces,
imposible. Por tanto, deben tenerse muy en cuenta para saber cómo hacer un
inventario de software.
También hay que considerar que, probablemente, cada empresa adquiere,
elimina y modifica muchos productos a lo largo del tiempo. La tarea de recopilar
esta información y alimentar la herramienta correspondiente, suele implicar la
dedicación completa de alguna persona. Ha de tenerse inevitablemente en
cuenta este coste a la hora de tomar la decisión de poner en marcha un sistema
de inventario.
1.3.5 Información complementaria para conformar el inventario
No es conveniente autoengañarse pensando que, aunque no hayamos localizado

dicha información, el fabricante la tendrá. Cuando un fabricante realiza una
auditoría de software, parte de la base de que el cliente tiene que demostrar los
derechos de uso que posee, de manera que todo aquello que no se pueda
demostrar, sencillamente, no existe.
En este sentido, y centrándonos en cómo se hace un inventario de software, las
herramientas que permiten incorporar las licencias adquiridas a la información
del inventario informático añaden una visión interesante. Proporcionarán
información de las licencias necesarias según el inventario de hardware y
configuraciones existentes simultáneamente.
Para tener claro cómo hacer un inventario de software no hay que quedarse en
una mera recopilación de información, es necesario también saber interpretarla.
Hay muchas circunstancias que pueden suponer que los derechos de uso
adquiridos no sean válidos en una situación determinada. Probablemente, la
parte más delicada y no automatizable de cómo hacer un inventario de software,
sea interpretar la información.
Tal vez, nuestras licencias fueron adquiridas para utilizarse en una ubicación
concreta y distinta a la actual. Quizá fueron compradas para usarse con
determinado software que ya no tenemos. O fueron suministradas con algún
condicionante sobre la duración del derecho de uso. Puede que se obtuvieran
para unas máquinas distintas a las actuales.
Por consiguiente, es necesario tener en consideración diversos supuestos en
función de cada escenario de licenciamiento para saber cómo hacer un
inventario de software. (Evergreen, 2020)
1.4 Gestión de licencias y parches
Los editores de software (como Adobe, Microsoft) auditan de manera periódica

los entornos de sus clientes para detectar, controlar y prevenir la piratería,
infracciones de los derechos de autor y el uso ilegal del software. Fallar en una
de estas auditorías podría causar un daño irremediable en la reputación del
negocio, multas y posibles medidas legales. Por lo tanto, para evitar
consecuencias debido al incumplimiento de una auditoría, las empresas
necesitan asegurarse de cumplir con la licencia de software en todo momento.
La gestión de parches implica tener una vista centralizada de los parches
aplicables para los endpoints en una red, a fin de poder clasificar los sistemas
vulnerables, altamente vulnerables y saludables de un vistazo. Esto ayuda a
detectar los sistemas que necesitan atención para que se puedan tomar las
medidas adecuadas para proteger la red ante ataques cibernéticos.
1.4.1 Gestión de licencias de software
Según un estudio realizado, el 69% de los ejecutivos de TI no están seguros de

cómo cumplir los acuerdos de licencia de software. Dado que las reglas de
cumplimiento de software son cada vez más estrictas, se ha vuelto crucial para
los administradores de TI garantizar que su organización no tenga software sin
licencia. (ManageEngine, 2021) Esto se puede lograr siguiendo estos pasos:
 Mantener un inventario de software actualizado: Es imprescindible que
pueda visualizar todo el software instalado en su red para lograr el
cumplimiento del software. Para monitorear y obtener visibilidad de todas
las instalaciones de software dentro de la red, debe analizar el inventario
de software regularmente.
 Alertas en tiempo real por incumplimiento: Configure alertas en tiempo
real para cuando no tenga las licencias suficientes, para que pueda tomar
medidas de inmediato.
 Prohibir las aplicaciones no comerciales: Los administradores de TI pueden
bloquear las aplicaciones no comerciales dentro de sus redes, para evitar
sorpresas.
 Realizar auditorías internas de las licencias de software: Al realizar
auditorías internas frecuentes podrá asegurarse de contar con las licencias
necesarias para evitar multas inesperadas.
Cumplir con la licencia de software es solo un aspecto de la gestión de licencias
de software. Gestionar las licencias de software también implica optimizar el uso
de licencias para reducir el gasto de TI. Eso se puede lograr al hacer lo siguiente:
1 Monitorear el uso de las aplicaciones comerciales para determinar si las
licencias se están utilizando de manera eficiente.
2 Reducir los costos al desinstalar las aplicaciones que no se están
utilizando en los sistemas.
3 Renovar las licencias según las estadísticas de uso de software.
1.4.2 Gestión de parches para sistemas operativos
Teniendo en cuenta la gran cantidad de parches que se lanzan cada día, es

imposible que los administradores de TI hagan todo manualmente. Por lo tanto,
necesita una solución de gestión de parches automatizada que le permita
automatizar todo el ciclo de vida de la gestión de parches para los sistemas y
aplicaciones de Windows. Dicho software está orientado a superar las
vulnerabilidades que debilitan la seguridad, corrompen los datos críticos del
sistema o afectan la disponibilidad del sistema.
Para los administradores de TI es difícil crear una solución de seguridad sin
comprender cuán vulnerables son sus sistemas. Buscan un software de
implementación de parches que no solo realice la implementación de parches
sino que también busque vulnerabilidades de red, identifique las correcciones y
parches de seguridad faltantes, que los aplique de inmediato y mitigue los
riesgos.
La gestión de parches para el sistema operativo incluye descubrir el sistema,
identificar las actualizaciones necesarias, implementar los parches, correcciones,
actualizaciones de seguridad e informes de parches relevantes para simplificar el
trabajo de los administradores de red. Los administradores de red pueden elegir
esta solución de software de gestión de parches completamente automatizada y
jamás tendrán que preocuparse por parchear los sistemas operativos.
1.4.3 ¿Por qué es tan importante la gestión de licencias y parches?
La aplicación de parches no sólo permite que los sistemas y las aplicaciones

funcionen sin problemas, sino que además es una de las actividades
fundamentales para mantener la seguridad de las organizaciones actuales. Dejar
los equipos sin parchear los hace vulnerables a los ciberataques, y el riesgo es
todo menos teórico. De hecho, según el Instituto Ponemon, la mayoría de las
violaciones de datos (57%) pueden atribuirse directamente a atacantes que
explotan una vulnerabilidad conocida que no había sido parcheada.
Un rápido repaso a los titulares relacionados con la seguridad ofrece multitud de
ejemplos, desde Equifax (culpable: una vulnerabilidad de Apache Struts sin
parchear desde hace dos meses) hasta SingHealth (con datos para 1,5 millones
de pacientes expuestos gracias a una versión obsoleta de Outlook).
Todos ellos dieron lugar a incidentes de seguridad considerablemente difundidos
y a violaciones de datos que podrían haberse evitado con una gestión de parches
más rigurosa y eficiente.
La repentina lucha por conseguir que los empleados teletrabajen durante la crisis
de la COVID ha agravado el problema, ya que los atacantes tratan de explotar
habitualmente las vulnerabilidades de las soluciones populares de Redes
Privadas Virtuales (VPN), (NinjaRMM, 2021) incluyendo:
 Citrix (CVE-2019-19781)
 Palo Alto (CVE-2020-2021)
 Pulse Secure (CVE-2019-11510)
 SonicWall (CVE-2020-5135).
Si algunas de las organizaciones más grandes y mejor financiadas del mundo
tienen dificultades con el proceso de gestión de parches, ¿qué posibilidades
tienen las PYMES con una asistencia de TI limitada?
Algunas de las mayores dificultades de la aplicación de parches se centran en el
hecho de que el proceso puede llevar mucho tiempo, ser complicado y perturbar
a los usuarios finales. Como resultado, es fácil posponer la aplicación de parches
o simplemente hacer que las actualizaciones importantes se pierdan por el
camino. Y con más de 18.000 CVEs publicadas en 2020, no es de extrañar que
muchas organizaciones tengan dificultades para mantenerse al día.
Desafortunadamente, el riesgo que suponen los sistemas sin parches es cada vez
mayor. Una vez que se ha revelado una vulnerabilidad y se ha publicado un
parche, las organizaciones tienen que aplicar el parche antes de que los
atacantes empiecen a explotarlo activamente. Ese margen de tiempo se está
reduciendo drásticamente, con numerosos ejemplos recientes en los que los
atacantes fueron capaces de lanzar ataques abusando de nuevas
vulnerabilidades antes o apenas unos días después de su divulgación.
Una vez que se han desarrollado las hazañas, éstas consiguen expandirse y
adaptarse rápidamente. Las herramientas de escaneo como Shodan, nmap y
masscan hacen que sea trivial para los atacantes el identificar sistemas
vulnerables y así poder lanzar campañas dirigidas.
Para muchas pequeñas empresas, la solución para estar al tanto de los ciclos de
aplicación de parches es externalizar la carga a los proveedores de servicios
gestionados (MSP). (NinjaRMM, 2021)
1.4.4 ¿Cómo es un proceso de Gestión de Parches eficaz?
A continuación se presenta una plantilla de 10 pasos, la cual destaca las

consideraciones fundamentales que deben incluirse en cualquier plan de gestión
de parches. Antes de entrar en este flujo de trabajo, deberá asegurarse de que
ha establecido funciones y responsabilidades claras para cada paso, y de que
todas las partes interesadas clave están completamente a bordo. (NinjaRMM,
2021)
Paso 1: Descubrimiento
En primer lugar, debe asegurarse de que se dispone de un inventario completo
de la red. En el nivel más básico, esto incluye conocer los tipos de dispositivos,
los sistemas operativos, las versiones del sistema operativo y las aplicaciones de
terceros. Muchas infracciones se originan porque hay sistemas descuidados u
olvidados a los que el departamento de TI ha perdido la pista. Las MSP deberían
utilizar herramientas que les permitan escanear los entornos de sus clientes y
obtener instantáneas completas de todo lo que hay en la red.
Paso 2: Categorización
Segmentar los sistemas gestionados y/o los usuarios según el riesgo y la
prioridad. Por ejemplo, por tipo de equipo (servidor, portátil, etc.), sistema
operativo, versión del sistema operativo, función del usuario, etc. Esto le
permitirá crear políticas de parcheo más granulares en lugar de adoptar un
enfoque de política única para todos.
Paso 3: Creación de la política de gestión de parches
Cree los criterios de aplicación de parches estableciendo qué se va a parchear,
cuándo y bajo qué condiciones. Por ejemplo, puede querer asegurarse de que
algunos sistemas/usuarios reciban parches con mayor frecuencia que otros y de
forma automática (el programa de parches para los usuarios finales de
ordenadores portátiles puede ser semanal, mientras que los parches para los
servidores pueden ser menos frecuentes y más manuales). También es posible
que quiera tratar los distintos tipos de parches de forma diferente, ya que
algunos tienen un proceso de despliegue más rápido o más extenso (piense en
las actualizaciones del navegador frente a las del sistema operativo;
actualizaciones críticas frente a las no críticas, por ejemplo). Por último, querrá
identificar las ventanas de mantenimiento para evitar interrupciones (tenga en
cuenta las zonas horarias para “seguir el sol” en la aplicación de parches, etc.)
y crear excepciones.
Paso 4: Supervisar los nuevos parches y vulnerabilidades
Entender los calendarios y modelos de publicación de parches de los
proveedores e identificar fuentes fiables para la divulgación oportuna de
vulnerabilidades. Crear un proceso para evaluar los parches de emergencia.
Paso 5: Prueba de parches
Cree un entorno de pruebas o, al menos, un segmento de pruebas para evitar
que los problemas imprevistos le sorprendan. Esto debería incluir la creación de
copias de seguridad para facilitar la reversión en caso necesario. Valide el
despliegue con éxito y controle los problemas de incompatibilidad o
rendimiento.
Paso 6: Gestión de la configuración
Registre y comunique cualquier cambio que se vaya a realizar mediante parches.
Esto le resultará útil en caso de que se encuentre con algún problema de
despliegue de parches más allá del segmento o entorno de prueba inicial.
Paso 7: Despliegue de parches
Siga las políticas de gestión de parches establecidas que creó en el Paso
3. Paso 8: Auditoría de parches
Realice una auditoría de la gestión de parches para identificar cualquier parche
fallido o pendiente y asegúrese de seguir vigilando cualquier problema
inesperado de incompatibilidad o rendimiento. También es una buena idea
recurrir a usuarios finales específicos que puedan ayudar aportando su
percepción de la situación.
Paso 9: Elaboración de informes
Elabore un informe de cumplimiento de parches que pueda compartir con sus
clientes para obtener visibilidad de su trabajo.
Paso 10: Revisar, mejorar y repetir
Establezca una cadencia para repetir y optimizar los pasos 1-9. Esto debería
incluir la eliminación progresiva o el aislamiento de cualquier máquina obsoleta o
sin soporte, la revisión de sus políticas y la revisión de las excepciones para
verificar si todavía se aplican o son necesarias.
1.4.5 Mejores prácticas de gestión de parches
A medida que la demanda de una gestión de parches eficaz sigue siendo más
integral, los MSP necesitan mejorar sus propios procesos y ofertas o se arriesgan
a quedarse atrás. Aquí hay tres claves para que los MSP ofrezcan servicios de
gestión de parches más inteligentes, más eficientes y más eficaces en 2021.
1) Automatice todo lo posible
La aplicación de parches es un juego en el que es muy fácil quedarse atrás, sobre
todo si todavía depende de la identificación, evaluación e implementación de
parches de forma manual. El software de gestión de parches automatizado y
basado en la nube software de gestión de parches permite a los MSP programar
escaneos de actualización regulares y garantizar que los parches se apliquen en
condiciones específicas o de forma automática.
2) Mitigar la necesidad de validar constantemente el despliegue de parches
A pesar de que la automatización de parches es cada vez más popular,
lamentablemente los MSP no siempre pueden dar por sentado que las
soluciones de parches automatizadas funcionan como se promete. Esto implica
una validación manual que requiere mucho tiempo. Desarrollar scripts o
procesos para
aliviar esa carga (o mejor aún, utilizar soluciones que no requieran una doble
comprobación) es una inversión que merece la pena.
3) Agilizar los informes
Todo lo que haga como MSP debe comunicarse como valor añadido a sus
clientes. La gestión de parches no debería ser una excepción, pero la entrega de
informes de auditoría de gestión de parches debería ser una excepción, pero la
entrega de informes de auditoría de gestión de parches debería ser los más
automática posible. Al fin y al cabo, cuanto más tiempo le lleve la elaboración de
informes, menos tiempo tendrá para ofrecer servicios adicionales y hacer crecer
su negocio.
1.5 Software como servicio (SaaS)
Software como un Servicio, abreviado ScuS (del inglés: Software as a Service,

SaaS), es un modelo de distribución de software donde el soporte lógico y los
datos que maneja se alojan en servidores de una compañía de tecnologías de
información y comunicación (TIC), a los que se accede vía Internet desde un
cliente.
1.5.1 ¿Qué es Software as a Service?
SaaS, o Software as a Service, es una forma de poner a disposición softwares y

soluciones de tecnología por medio de la internet, como un servicio. Con este
modelo, la empresa no necesita instalar, mantener y actualizar hardware y
software. El acceso es fácil y simples: sólo es necesario contar con una conexión
a internet.
Las aplicaciones SaaS también son llamadas softwares basados en Web, software
on demand o softwares hospedados. Independientemente del nombre, ellos son
ejecutados en los servidores de las empresas proveedoras, que tienen la
responsabilidad de gestionar el acceso y mantener la estructura de datos, la
conectividad y los servidores necesarios para el funcionamiento del servicio.
1.5.2 Requisitos, Costo –
Beneficios Requisito
Las aplicaciones de SaaS están disponibles desde cualquier equipo o dispositivo,
en cualquier momento y lugar, mediante la Cloud Computing de SaaS. Si se tiene
disponibilidad de Internet en todas partes, las plataformas de SaaS tienden a
tener altos índices de adopción, junto con prácticamente ninguna necesidad de
capacitación.
Costo
Las plataformas de SaaS tienen menores costos iniciales en comparación con el
software tradicional. Como se basan en suscripción, los costos son mucho
menores. Cuando los proveedores de SaaS administran la infraestructura de TI,
disminuyen los costos tanto de hardware y software como de mano de obra.
Beneficios
Los sistemas de SaaS permiten a las empresas regular el cumplimiento de los
requisitos de software continuamente, según sus necesidades comerciales y la
demanda de los clientes. Muchos proveedores de SaaS también ofrecen
personalización para que cada empresa pueda satisfacer necesidades
individuales. Además, muchas proporcionan interfaces para programación de
aplicaciones (API, por sus siglas en inglés), lo que permite la integración con las
aplicaciones existentes.
Dado que el proveedor gestiona todas las actualizaciones, las plataformas de
SaaS eliminan la necesidad de descargar e instalar la aplicación. El proveedor de
SaaS también se ocupa de la disponibilidad, de manera que los clientes no deban
agregar hardware, software ni ancho de banda a medida que la base de usuarios
crece.
Con el modelo de Software como Servicio, las empresas obtienen los avances y
las funciones de los modelos tradicionales de software, sin el mantenimiento
continuo ni los grandes costos iniciales (los costos de licencias son más bajos o
gratuitos). Además, el SaaS ya está instalado y configurado, lo que significa que
las empresas pueden comenzar a operar más rápidamente.
1.5.3 Soluciones de tecnologías SaaS
Con el SaaS, los desarrolladores pueden dar servicio de asistencia a una gran
cantidad de clientes con una única versión de un producto. Este enfoque permite
a las empresas crecer con la rapidez necesaria sin reemplazar infraestructura
costosa ni agregar personal de TI. Asimismo, el precio del SaaS basado en
suscripciones puede ayudar a mantener los costos de presupuesto de TI al
mínimo en comparación con un software local o empaquetado. Dado que
simplifica procesos y disminuye los costos de adquisición de clientes, la
popularidad del SaaS ha crecido y es probable que continúe así.
Si ha utilizado un servicio de correo electrónico basado en web, como Outlook,
Hotmail o Yahoo! Mail, entonces ya ha usado una forma de SaaS. Con estos
servicios, usted inicia sesión en su cuenta a través de Internet, a menudo desde
un explorador web. El software de correo electrónico se encuentra en la red del
proveedor de servicios, donde también se almacenan los mensajes. Puede
obtener acceso a su correo electrónico y a los mensajes almacenados desde un
explorador web en cualquier equipo o dispositivo conectado a Internet.
Los ejemplos anteriores son servicios gratuitos para uso personal. Para el uso en
una organización, puede alquilar aplicaciones de productividad, como correo
electrónico, colaboración y calendario; y aplicaciones empresariales sofisticadas,
como CRM (administración de las relaciones con el cliente), ERP (planeamiento
de recursos empresariales) y administración de documentos. Usted paga por el
uso que hace de estas aplicaciones a través de una suscripción o conforme al
nivel de uso. (Azure, 2021)
Figura 6: Soluciones de tecnologías SaaS
1.5.4 Softwares hospedados
Tradicionalmente, los negocios han tenido que crear y mantener una

infraestructura para ejecutar aplicaciones on-premise. Con el modelo de
software como servicio (SaaS), los negocios pueden usar aplicaciones que están
hospedadas online. Esto les permite reducir los costos, ya que solo pagan por lo
que usan; disponer de actualizaciones de funcionalidad sencillas y sin
complicaciones; e integrarlas fácilmente con sus datos y sistemas actuales.
Los proveedores de aplicaciones que crean aplicaciones basadas en el modelo
SaaS saben que puede resultar caro y complejo ser el propietario de la
infraestructura donde se hospedan estas aplicaciones, así como su uso, sobre
todo cuando la demanda de los clientes es variable.
Tanto si es una compañía que busca un entorno de nube donde implementar sus
soluciones on-premise actuales, como si es un proveedor de aplicaciones que
está evaluando una plataforma de Cloud donde implementar una nueva
aplicación u oferta de SaaS, debe plantearse lo siguiente:
 ¿Puedo usar el lenguaje de programación y la plataforma de aplicación que
prefiera?
 ¿Puedo usar el sistema operativo y el entorno donde ya están
implementadas mis aplicaciones existentes?
 ¿Qué compromisos o contratos exigirá mi proveedor de la nube? ¿Tendré
que realizar una inversión inicial?
 ¿Con qué rapidez puedo responder a los picos y a los periodos de calma en
la demanda de mis clientes o en las cargas informáticas de las aplicaciones?
 ¿El proveedor de nube tiene experiencia en mantener una infraestructura
global, redundante y resistente?
 ¿Qué consideraciones de seguridad ha tenido en cuenta mi proveedor de la
nube?
Hospedaje de aplicaciones mediante AWS
Amazon Web Services (AWS) ofrece recursos informáticos de confianza,
escalables y económicos en los que hospedar sus aplicaciones. (AWS, 2021)
Puede combinar los siguientes componentes de AWS o usarlos por separado
para hospedar sus aplicaciones:
Amazon Elastic Compute Cloud (Amazon EC2). Ofrece capacidad de cómputo
variable en la nube. Para definir el entorno virtual de Amazon EC2, debe
especificar el sistema operativo, los servicios, las bases de datos y la pila de la
plataforma de aplicaciones necesarios para la aplicación hospedada. Amazon
EC2 ofrece una consola de gestión integral y API para la gestión de sus recursos
informáticos.
Amazon Simple Storage Service (Amazon S3). Proporciona una sencilla interfaz
de servicios web que permite almacenar y recuperar la cantidad de datos que
desee, en cualquier momento y desde cualquier parte de la web. Ofrece
seguridad, una alta disponibilidad y una gran duración. Amazon S3 también
almacena varias copias redundantes de sus datos.
Amazon Relational Database Service (Amazon RDS). Facilita la configuración,
el funcionamiento y el escalado de una base de datos relacional en la nube.
Proporciona una capacidad de base de datos rentable y de tamaño variable, a la
vez que administra las tareas de administración de base de datos que más
tiempo requieren.
Amazon CloudFront. Ofrece un sistema de entrega de contenido de alto
desempeño distribuido a escala mundial. Su aplicación puede utilizar Amazon
CloudFront para distribuir o transmitir contenido fácilmente a los usuarios con
una baja latencia, con altas velocidades de transferencia de datos, sin
compromisos y con una integración con Amazon S3 óptima.
Amazon Simple Queue Service (Amazon SQS). Ofrece a la aplicación un
sistema de colas seguro y de alto desempeño que le permite distribuir el
trabajo entre los procesos de la aplicación de forma fiable.
Amazon DevPay. Es un sencillo servicio de administración de cuentas y
facturación online que le permite vender aplicaciones que están integradas en
Amazon Web Services, o que se ejecutan sobre este servicio.
1.5.5 Cómo alcanzar el éxito con el SaaS
Como el SaaS es diferente a los softwares tradicionales, es importante que se lo

trate de manera diferente. Para tener una experiencia fructífera con el SaaS, ten
en cuenta estos pasos:
 Realiza un seguimiento del uso de productos.- El modelo de SaaS
proporciona datos y estadísticas sobre tus clientes.
 No te detengas después del SaaS.- Teniendo en cuenta que el software
como servicio elimina gran parte del trabajo del comienzo (por ejemplo,
la instalación y el mantenimiento continuo), es importante continuar
implementando ofertas atractivas y desarrollando estrategias dentro del
plan de marketing.
 Evita confiar en una estrategia tradicional.- La internet cambia
constantemente. Por eso. siempre es buena idea cambiar tu servicio y
lanzar nuevas iteraciones en vez de apegarte al ritmo más lento de los
lanzamientos de softwares tradicionales.
 Conoce las opiniones.- Conéctate con los clientes y utiliza el feedback
para mejorar las futuras interacciones de productos.
1.6 Control de versiones del software

1.6.1 ¿Qué es el control de versiones?
El control de versiones, también conocido como "control de código fuente", es la

práctica de rastrear y gestionar los cambios en el código de software. Los
sistemas
de control de versiones son herramientas de software que ayudan a los equipos
de software a gestionar los cambios en el código fuente a lo largo del tiempo. A
medida que los entornos de desarrollo se aceleran, los sistemas de control de
versiones ayudan a los equipos de software a trabajar de forma más rápida e
inteligente. Son especialmente útiles para los equipos de DevOps, ya que les
ayudan a reducir el tiempo de desarrollo y a aumentar las implementaciones
exitosas. (Atlassian, 2020)
El software de control de versiones realiza un seguimiento de todas las
modificaciones en el código en un tipo especial de base de datos. Si se comete
un error, los desarrolladores pueden ir hacia atrás en el tiempo y comparar las
versiones anteriores del código para ayudar a resolver el error, al tiempo que se
minimizan las interrupciones para todos los miembros del equipo.
Para casi todos los proyectos de software, el código fuente es como las joyas de
la corona, un activo valioso cuyo valor debe protegerse. Para la mayoría de
equipos de software, el código fuente es un repositorio del conocimiento de
valor incalculable y de la comprensión sobre el dominio del problema que los
desarrolladores han recopilado y perfeccionado con un esfuerzo cuidadoso. El
control de versiones protege el código fuente tanto de las catástrofes como del
deterioro casual de los errores humanos y las consecuencias accidentales.
Los desarrolladores de software que trabajan en equipos están escribiendo
continuamente nuevo código fuente y cambiando el que ya existe. El código de
un proyecto, una aplicación o un componente de software normalmente se
organiza en una estructura de carpetas o "árbol de archivos". Un desarrollador
del equipo podría estar trabajando en una nueva función mientras otro
desarrollador soluciona un error no relacionado cambiando código. Cada
desarrollador podría hacer sus cambios en varias partes del árbol de archivos.
El control de versiones ayuda a los equipos a resolver este tipo de problemas al
realizar un seguimiento de todos los cambios individuales de cada colaborador y
al contribuir a evitar que el trabajo concurrente entre en conflicto. Los cambios
realizados en una parte del software pueden ser incompatibles con los que ha
hecho otro desarrollador que está trabajando al mismo tiempo. Este problema
debería detectarse y solucionarse de manera ordenada sin bloquear el trabajo
del resto del equipo. Además, en todo el desarrollo de software, cualquier
cambio puede introducir nuevos errores por sí mismo y el nuevo software no es
fiable hasta que se prueba. De este modo, las pruebas y el desarrollo van de la
mano hasta que está lista una nueva versión.
Un buen software de control de versiones soporta el flujo de trabajo preferido de
un desarrollador sin imponer una forma determinada de trabajar. Idealmente,
también funciona en cualquier plataforma, en vez de ordenar qué sistema
operativo o cadena de herramientas deben utilizar los desarrolladores. Los
sistemas de control de versiones excepcionales facilitan un flujo sencillo y
continuo de cambios en el código en vez del mecanismo frustrante y burdo del
bloqueo de archivos, que da luz verde a un desarrollador a expensas de bloquear
el progreso de los demás. (Atlassian, 2020)
Los equipos de software que no utilizan ninguna forma de control de versiones a
menudo se encuentran con problemas como no saber qué cambios que se han
hecho están disponibles para los usuarios o la creación de cambios incompatibles
entre dos partes no relacionadas que tienen que desvincularse y revisarse
exhaustivamente. Si eres un desarrollador que nunca ha utilizado el control de
versiones, puede que hayas añadido versiones a tus archivos, quizás con sufijos
como "final" o "más reciente", y que después hayas tenido que enfrentarte con
una nueva versión final. Quizás has convertido en comentarios bloques de
código, porque quieres desactivar una determinada función sin eliminar el
código, con el miedo de que pueda utilizarse más adelante. El control de
versiones es una forma de solucionar estos problemas.
El software de control de versiones es una parte esencial del día a día de las
prácticas profesionales del equipo de software moderno. Los desarrolladores de
software individuales que están acostumbrados a trabajar con un sistema de
control de versiones potente en sus equipos suelen reconocer el increíble valor
que el control de versiones también les da incluso en los proyectos pequeños en
los que trabajan solos. Una vez acostumbrados a las potentes ventajas de los
sistemas de control de versiones, muchos desarrolladores no se plantearían
trabajar sin ellos incluso para los proyectos que no son de software. (Atlassian,
2020)
1.6.2 Ventajas de los sistemas de control de versiones
Utilizar un software de control de versiones es una práctica recomendada para

los equipos de software y de DevOps de alto rendimiento. El control de versiones
también ayuda a los desarrolladores a moverse más rápido y permite que los
equipos de software mantengan la eficiencia y la agilidad a medida que el equipo
se escala para incluir más desarrolladores.
Los sistemas de control de versiones (VCS) han experimentado grandes mejoras
en las últimas décadas y algunos son mejores que otros. Los VCS a veces se
conocen como herramientas de SCM (Gestión del código fuente) o RCS (Sistema
de control de revisiones). Una de las herramientas de VCS más populares hoy en
día se llama Git. Git es un VCS distribuido, una categoría conocida como DVCS,
que explicaremos con más detalle después. Al igual que muchos de los sistemas
de VCS más populares disponibles hoy en día, Git es gratuito y de código abierto.
Independientemente del nombre que tengan, o del sistema que se utilice, las
principales ventajas que deberías esperar del control de versiones son las
siguientes. (Atlassian, 2020)
1. Un completo historial de cambios a largo plazo de todos los archivos.
Esto quiere decir todos los cambios realizados por muchas personas a lo
largo de los años. Los cambios incluyen la creación y la eliminación de los
archivos, así como los cambios de sus contenidos. Las diferentes
herramientas de VCS difieren en lo bien que gestionan el cambio de
nombre y el movimiento de los archivos. Este historial también debería
incluir el autor, la fecha y notas escritas sobre el propósito de cada
cambio. Tener el historial completo permite volver a las versiones
anteriores para ayudar a analizar la causa raíz de los errores y es crucial
cuando se tiene que solucionar problemas en las versiones anteriores del
software. Si se está trabajando de forma activa en el software, casi todo
puede considerarse una "versión anterior" del software.
2. Creación de ramas y fusiones.
Si se tiene a miembros del equipo trabajando al mismo tiempo, es algo
evidente; pero incluso las personas que trabajan solas pueden
beneficiarse de la capacidad de trabajar en flujos independientes de
cambios. La creación de una "rama" en las herramientas de VCS mantiene
múltiples flujos de trabajo independientes los unos de los otros al tiempo
que ofrece la facilidad de volver a fusionar ese trabajo, lo que permite
que los desarrolladores verifiquen que los cambios de cada rama no
entran en conflicto. Muchos equipos de software adoptan la práctica de
crear ramas para cada función o quizás para cada publicación, o ambas.
Existen muchos flujos de trabajo diferentes que los equipos pueden elegir
cuando deciden cómo utilizar la creación de las ramas y las fusiones en
VCS.
3. Trazabilidad.
Ser capaz de trazar cada cambio que se hace en el software y conectarlo
con un software de gestión de proyectos y seguimiento de errores como
Jira, además de ser capaz de anotar cada cambio con un mensaje que
describa el propósito y el objetivo del cambio, no solo te ayuda con el
análisis de la causa raíz y la recopilación de información. Tener el historial
anotado del código a tu alcance cuando estás leyendo el código,
intentando entender lo que hace y por qué se ha diseñado así, puede
permitir a los desarrolladores hacer cambios correctos y armoniosos que
estén en línea con el diseño previsto a largo plazo del sistema. Esto puede
ser especialmente importante para trabajar de manera eficaz con código
heredado y es esencial para que los desarrolladores puedan calcular el
trabajo futuro con precisión.
1.6.3 ¿Qué es el Git?
Hoy en día, Git es, con diferencia, el sistema de control de versiones moderno
más utilizado del mundo. Git es un proyecto de código abierto maduro y con un
mantenimiento activo que desarrolló originalmente Linus Torvalds, el famoso
creador del kernel del sistema operativo Linux, en 2005. Un asombroso número
de proyectos de software dependen de Git para el control de versiones, incluidos
proyectos comerciales y de código abierto. Los desarrolladores que han
trabajado con Git cuentan con una buena representación en la base de talentos
disponibles para el desarrollo de software, y este sistema funciona a la
perfección en una amplia variedad de sistemas operativos e IDE (entornos de
desarrollo integrados).
Git, que presenta una arquitectura distribuida, es un ejemplo de DVCS (sistema
de control de versiones distribuido, por sus siglas en inglés). En lugar de tener un
único espacio para todo el historial de versiones del software, como sucede de
manera habitual en los sistemas de control de versiones antaño populares, como
CVS o Subversion (también conocido como SVN), en Git, la copia de trabajo del
código de cada desarrollador es también un repositorio que puede albergar el
historial completo de todos los cambios. (Atlassian, 2020)
1.6.4 Herramientas Git
Casi todos los proyectos de desarrollo y software, comerciales o personales,

ahora usan Git para el control de versiones. Explicaremos qué es Git de forma
resumida y recomendaremos los mejores clientes de Git GUI para varias
plataformas. (Hostinger, 2021)
1.6.4.1 Clientes Git GUI para Linux
QGit Es una Git GUI gratuita para Linux que puede mostrar gráficamente
diferentes ramas y te permite ver el contenido del parche y los cambios en los
archivos. Con esta herramienta, puedes ver árboles de archivo, historiales de
archivos, revisiones y diferencias.
También puedes comparar archivos y cambiar visualmente el contenido
modificado con QGit. Así mismo, es posible aplicar o formatear series de parches
a partir de confirmaciones seleccionadas y mover confirmaciones entre dos
instancias de QGit.
Puedes usar la misma semántica de confirmaciones de Git para crear nuevos
parches e implementar comandos comunes de StGit. Los scripts y las secuencias
de comandos y secuencias de comandos se pueden conectar a una acción
personalizada.
Gitg La interfaz de usuario de Gitg es fácil de usar. Puedes abrir repositorios Git
existentes guardados en tu computadora. Puedes descargar el software de forma
gratuita y tiene una licencia GPLv2. Los repositorios remotos también se pueden
ver usando Gitg.
Gitg te permite realizar operaciones Git comunes, examinar confirmaciones y
obtener una vista previa de los archivos. Puedes ver mensajes de confirmación,
confirmaciones sin seguimiento y sin etapas a través de la vista de confirmación.
La desventaja de esta herramienta es que los archivos grandes tienden a
cargarse más lentamente y no muestra el historial de un proyecto.
Git Force Es una herramienta visual frontal para Git que se ejecuta tanto en Linux
como en Windows, y es de descarga gratuita. Este software ayudará a los
principiantes ya que la interfaz es intuitiva con una función de arrastrar y soltar,
y se puede usar sin llamar a una herramienta Git de línea de comandos.
Puedes crear múltiples repositorios y ramas de Git, administrándolos todos con
Git Force. La herramienta puede soportar uno o más repositorios remotos y
puede escanear rápidamente los puntos locales.
El trabajo que realices en un repositorio de git será recogido por Git Force en la
primera actualización. Sin embargo, solo funciona con los comandos Git más
comunes y, por eso, no guarda información de estado detallada.
1.6.4.2 Clientes Git para Windows
Sourcetree Es un cliente GIT GUI gratuito y puede funcionar tanto en Windows

como en Mac. Esta herramienta es simple de usar pero potente, por lo que es
perfecta tanto para usuarios principiantes como avanzados. La interfaz limpia y
elegante hace que navegar sea fácil y sin esfuerzo.
Es una GUI con todas las funciones que hacen que tus proyectos de Git sean más
eficientes y fáciles. Puedes admitir archivos Git grandes y visualizarlos con
diagramas de ramificación detallados, lo que facilita que tú y los miembros de tu
equipo vean el progreso.
La búsqueda de confirmación local te permite encontrar cambios de archivo,
confirmaciones y ramas, mientras que el administrador de repositorios remotos
te permite buscar y clonar repositorios remotos dentro de Sourcetree. También
puedes obtener confirmaciones claras y limpias con la herramienta interactiva de
rebase.
GitHub Si tu repositorio remoto está en GitHub, entonces esta herramienta será
la más útil para ti. El software es básicamente una extensión de tu flujo de
trabajo en GitHub. Simplemente inicia sesión con tu cuenta de GitHub y ya
podrás comenzar a trabajar en tus repositorios.
GitHub Desktop es un cliente Git GUI gratuito y de código abierto. Tiene una
interfaz intuitiva que te permite administrar el código sin necesidad de escribir
comandos. Puedes crear repositorios nuevos o agregar locales y realizar
operaciones de Git con facilidad.
Crear ramas y cambiar a las existentes no es una molestia, por lo que fusionar
código con la rama maestra. Además, puede realizar un seguimiento de sus
cambios con GitHub Desktop.
Tortoise Git Este software libre y de código abierto es una interfaz de shell de
Windows para Git. Puede usarse en un entorno comercial y desarrollarse
también bajo tu propia versión. Tortoise Git se puede usar con otras
herramientas de desarrollo y cualquier tipo de archivo.
Admite tareas regulares como commit, crear ramas y etiquetas, mostrar
registros, etc. La herramienta es fácil de usar ya que se puede acceder a los
comandos directamente desde el Explorador de Windows. Los cuadros de
diálogo son descriptivos y puedes mover archivos arrastrándolos.
Existen herramientas, como TortoiseGitMerge, que ayudan a resolver conflictos y
te permiten ver los cambios que realizaste en tus archivos. Tiene un corrector
ortográfico para registrar mensajes y autocompletar palabras clave y rutas.
También está disponible en 30 idiomas diferentes.
1.6.4.3 Clientes Git multiplataforma
GitKraken No solo es confiable, eficiente, visualmente agradable y elegante de

usar, sino que también hace que las operaciones de git sean comprensibles y
agradables. Su interfaz es intuitiva, ya que permite a los usuarios realizar
rápidamente acciones básicas y tiene una función de arrastrar y soltar.
Además, puedes corregir fácilmente los errores con un solo clic.
La herramienta tiene un editor de código incorporado donde puedes comenzar
un nuevo proyecto y editar los archivos directamente en GitKraken. Además, te
permite realizar un seguimiento de tus tareas, ya que puedes sincronizar todo
con GitHub en tiempo real, organizar tareas en la vista de calendario y
mencionar a los miembros del equipo para notificarles sobre las actualizaciones.
SmartGit Al igual que su nombre, este potente cliente Git GUI tiene una interfaz
inteligente que se ve y funciona igual en diferentes plataformas.
Tiene una función de vista única donde puedes ver tu índice, árbol de trabajo y
comandos, todo en la ventana de registro.
La herramienta te permite comparar o fusionar archivos y editarlos uno al lado
del otro. Puedes resolver conflictos de fusión utilizando el Solucionador de
conflictos. SmartGit también proporciona un cliente SSH, un rendimiento
mejorado de rebase y Git-Flow que te permite configurar marcas sin
herramientas adicionales.
Se integra con plataformas Git populares como GitHub y BitBucket, lo que facilita
las solicitudes de colaboración y las revisiones de código.
Git Cola Es un cliente de Git simple pero potente que se desarrolló con Python y
es de uso gratuito. La interfaz está hecha de múltiples herramientas que puedes
ocultar y reorganizar según tus necesidades. Los cuatro paneles de la interfaz te
permiten ver aspectos separados de tu proyecto.
También tienes Git-Dag, un visualizador Dag para commits y ramas, y la lista de
atajos de teclado es útil para un flujo de trabajo más rápido y eficiente.
Además, Git Cola recordará el diseño de tu trabajo y lo restaurará a su estado
original la próxima vez que necesites hacerlo.
Además de admitir configuraciones de GUI personalizadas, la herramienta
también tiene configuraciones de idioma. Dado que Git Cola es de código
abierto, la herramienta es fácil de mantener y actualizar.
Aurees Es un cliente Git multiplataforma que es simple y rápido de usar, además
de ser de descarga gratis. Su interfaz es intuitiva y limpia. La herramienta tiene
como objetivo proporcionar un entorno sin problemas para que los usuarios
vean, editen y publiquen archivos Git.
Debes iniciar sesión en tu cuenta de GitHub para usarlo.
Aurees muestra los cambios de confirmación y fusión en las ventanas de lado a
lado, lo que hace que sea fácil para ti rastrear y resolver conflictos rápidamente.
Las etiquetas están codificadas por colores para que puedas navegar por el
repositorio con facilidad.
Con Aurees puedes hacerte una idea de qué miembro del equipo realiza los
cambios, ya que te permite explorar todos los documentos. También puedes
aplicar sangría a las confirmaciones de fusión para ver números de línea o
diferencias al comparar documentos.
1.7 Despliegue y distribución de software

1.7.1 ¿En qué consiste el despliegue de Software?
El término “despliegue de software” describe los procesos utilizados para instalar

paquetes de software o aplicaciones en dispositivos técnicos. Normalmente, un
administrador de la organización o de TI se encarga de ello, ya que no todos los
usuarios tienen los conocimientos o la autorización necesarios. El objetivo de la
distribución de software es la instalación inicial, la configuración y el
mantenimiento de múltiples aplicaciones de software en varios dispositivos de
forma rápida, automatizada, cómoda y sin errores. Esto garantiza que los
procesos operativos permanezcan intactos y que su entorno de trabajo sea
productivo.
1.7.2 Servicios de despliegue
El Despliegue de software son todas las actividades que hacen que un sistema de
software esté disponible para su uso.
El proceso de implementación general 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
ambos. Debido a que cada sistema de software es único, los procesos o
procedimientos precisos dentro de cada actividad difícilmente pueden definirse.
Por lo tanto, la "implementación" debe interpretarse como un proceso general
que debe personalizarse de acuerdo con los requisitos o características
específicos
1.7.3 ¿Qué significa la distribución de software?
Una distribución de software, también conocido como software distro, es un

conjunto de software específico (o una colección de múltiple software, incluso un
sistema operativo), ya compilado y configurado. Generalmente pueden tomar
formas de licencia, de entre la más usada es la licencia GPL u open source.
También puede tomar la forma de una distribución binaria, un instalador (.exe)
que puede
ser descargado desde Internet. Distribución de software también se puede
referir a los tipos de Otherware (como careware y donateware).
La distribución manual de software puede ser estresante y llevar mucho tiempo.
En cambio, la distribución automatizada de software agiliza sus tareas de trabajo,
ofreciendo comodidad y garantizando la satisfacción del usuario. Ahórrese los
molestos pasos intermedios y gestione todo su panorama de software con una
sola herramienta desde un puesto de trabajo central. (Deskcenter, 2021)
1.7.4 Distribución automatizada de software
Los responsables de TI suelen estar estresados y sobrecargados de tareas

rutinarias. La distribución automatizada de software le ahorra tiempo y también
reduce la carga de trabajo. La distribución automatizada de software le ahorra
tiempo y también reduce la carga de trabajo, lo que significa que puede
responder rápida y eficazmente y estructurar su gestión de TI de forma que
resulte económica. (Deskcenter, 2021)
Los humanos son la principal fuente de errores informáticos. Por lo tanto, la
definición de procesos estándar automatizados también es esencial a la hora de
desplegar el software si se quiere cerrar las arriesgadas brechas de seguridad.
Cuanto más automatizado esté un proceso, más segura será su estructura
informática. Esto significa que puede relajarse y centrarse en sus otras tareas.
(Deskcenter, 2021)
1.8 Empaquetado de software
Todos usamos software cuando estamos en nuestros dispositivos, como

computadoras o teléfonos móviles, pero no sabemos mucho sobre los tipos en
los que están disponibles. Existen dos categorías principales de estos programas
que se basan en la naturaleza de dichos dispositivos. El software empaquetado y
personalizado se describe por su creación y disponibilidad. El primero es un
programa comercial que está disponible para el público y se les vende a precios
especiales. El segundo está desarrollado específicamente para una organización
o un propósito.
1.8.1 ¿Qué es el empaquetado de aplicaciones?
El empaquetado de aplicaciones consiste en proporcionar las aplicaciones en

forma de paquetes, a los que se suele llamar en inglés software bundle o
application bundle. Estos paquetes están formados por los programas
ejecutables
de la aplicación, así como por todas las bibliotecas de las que depende y otro tipo
de ficheros (como imágenes, ficheros de audio, traducciones y localizaciones,
etc.), de forma que se proporcionan como un conjunto. Las bibliotecas de las que
depende el programa pueden haber sido enlazadas tanto de forma dinámica
como también estática. Por tanto, el usuario percibe que el paquete como un
conjunto que representa al programa en sí, cuando en realidad incluye varios
ficheros.
El empaquetado de aplicaciones permite evitar los problemas de las
dependencias tanto a la hora de instalar la aplicación como a la hora de usarla,
ya que cada paquete lleva consigo sus dependencias, y la instalación o
desinstalación de otro software no va a afectar a las dependencias de dicho
paquete.
La principal ventaja del empaquetado de aplicaciones es precisamente que se
evitan la problemática de las dependencias, y que la aplicación se puede
trasladar de un computador a otro sin necesidad de reinstalarla, ya que el
paquete de la aplicación contiene todos los ficheros necesarios para ejecutarla.
Sin embargo, como desventaja se presenta que estos paquetes ocupan mucho
más espacio en el disco, especialmente si el paquete incluye bibliotecas.
1.8.2 Software empaquetado
El software empaquetado, comúnmente conocido como paquete de software, es

un programa comercial que está disponible para el público y se les vende a
precios particulares. Su definición va como un programa o colección de
programas que se agrupan con el propósito de brindar al público diferentes
herramientas en una misma familia en un solo lugar. Estos pueden tener
funciones similares o características similares y hacer un paquete completo para
el usuario. El mejor ejemplo de este tipo de software es el programa Microsoft
Word que tiene muchas herramientas vinculadas entre sí, es del mismo
desarrollador, el tema es el mismo, pero cada dispositivo realiza su función.
Microsoft Office es famoso por escribir y hacer informes, Microsoft PowerPoint
se usa para crear presentaciones y otros discursos. Microsoft Excel se utiliza para
resolver ecuaciones e ingresar datos en hojas, etc. En algunos casos, cuando los
programas de audio y video se agrupan, también se conocen como software
empaquetado. La mayoría de ellos son productos de pago y no están disponibles
en el mercado de forma gratuita. También se denomina software que ayuda a
instalar productos en la computadora y, por lo tanto, obtiene el nombre. Pero la
definición básica sigue siendo la misma, cuando muchos softwares están
presentes en un paquete y brindan soluciones a las personas; luego obtiene el
nombre deseado. Pero la definición básica sigue siendo la misma, cuando
muchos softwares están presentes en un paquete y brindan soluciones a las
personas; luego obtiene el nombre deseado. Pero la
definición básica sigue siendo la misma, cuando muchos softwares están
presentes en un paquete y brindan soluciones a las personas; luego obtiene el
nombre deseado. (Diferenciario, 2021)
1.8.3 Software personalizado
El software personalizado se define como el programa que se desarrolla

específicamente para una organización o un propósito. El mejor ejemplo de tal
estado es el pedido de software para una empresa que quiere tener un sistema
de gestión para sus empleados y realizar un seguimiento de sus horas de trabajo.
De manera similar, cada vez que se realiza una tarea en una condición particular,
por ejemplo, personas que obtienen el trabajo de diseñar una calculadora a
través del lenguaje C ++, entonces se convertirá en un producto personalizado.
Para obtener el nombre, tiene que seguir la regla que el programa creó para las
personas que trabajan en el entorno dentro de una instalación en particular.
Estos programas de software no llegan al mercado y están diseñados
específicamente para realizar una tarea para una empresa. Casas, desarrollar
dicho programa para terceros y venderlo a sus tarifas. Es un hecho que los
precios de estos programas son mucho más altos que los que se venden
públicamente. El mejor ejemplo, en este caso, es que JPMorgan desarrolla un
plan para el departamento de gestión, se sabe que este será utilizado
correctamente por el personal y no por los demás en la empresa. Es posible que
cada uno de ellos tenga su fuente de lidiar con cosas particulares. Varios
restaurantes también tienen programas de este tipo y son utilizados
principalmente por marcas famosas como Tesco, Walmart y Sainsbury.
(Diferenciario, 2021)
1.8.4 Diferencia entre Software empaquetado y software personalizado
El software empaquetado es un programa o colección de programas que se

agrupan con el fin de proporcionar al público diferentes herramientas de la
misma familia en un solo lugar. Los softwares personalizados son programas que
no llegan al mercado y se diseñan específicamente para realizar una tarea para
una empresa.
El mejor ejemplo de software empaquetado es el programa Microsoft Office, que
tiene muchas herramientas vinculadas entre sí, como Office, PowerPoint, Access,
Note y Excel. El mejor ejemplo, en el caso del software personalizado, es
JPMorgan que desarrolla un programa para el departamento de gestión.
El software empaquetado está presente en el mercado para que todos puedan
comprarlo y usarlo, mientras que el software personalizado no está disponible
comercialmente y es exclusivo de terceros que desean usarlo.
Los precios del software empaquetado son mucho más bajos en comparación
con el software personalizado, ya que se fabrican exclusivamente.
Varias universidades e individuos han empaquetado software porque se utilizan
para múltiples propósitos. Varios restaurantes tienen programas personalizados
y los utilizan principalmente marcas famosas como Tesco, Walmart y Sainsbury.
El software personalizado es difícil de usar ya que está personalizado, mientras
que el software empaquetado es fácil de usar ya que tiene una interfaz sencilla.
(Diferenciario, 2021)
1.8.5 Empaquetado de software corporativo
La distribución de aplicaciones y parches sin una preparación adecuada conlleva

problemas muy graves que se evidencian en:
 Instalaciones no fiables que causan errores catastróficos en aplicaciones
vitales.
 Entornos no gestionados en los que no hay control sobre las aplicaciones,
los procesos, las versiones ni las licencias.
 Configuraciones no estándares que aumentan los costes de mantenimiento
de los PC.
 Aplicaciones no fiables que acaban por frustrar a los usuarios finales y
desencadenan numerosas llamadas a los centros de asistencia, lo que
termina por disminuir la productividad del departamento informático y de
los usuarios finales.
Las empresas que adoptan un enfoque estructurado para lograr la idoneidad de
sus aplicaciones invierten mucho más tiempo en los procesos de ingeniería y
documentación, pero recogen los beneficios de la reducción de costes y del
aumento de productividad de los usuarios finales. (Wise, 2004)
1.8.6 Ejemplos de paquetes de software
1.- Open Office: Fue el primer paquete informático en ofrecer al mercado un

software abierto con varias aplicaciones y herramientas sin ningún costo
económico, se denomina Open Abierto en español porque su código fuente es
abierto, pudiendo ser visto y modificado por sus usuarios, ha sido traducido a
más de treinta idiomas diferentes y está disponible para distintas plataformas,
tales
como Windows, MacOS, GNU (Linux) y Solaris. Se trata de un software sencillo
de usar, sus aplicaciones se denominan:
2.- Thinkfree Office: Está compuesto solamente por tres aplicaciones, un
procesador de texto Write, una hoja de cálculo Calcy un programa para realizar
presentaciones Show, se encuentra disponible para Linux, Macy Windows, es
compatible con Microsoft Office.
3.- Microsoft Office 365 El paquete de software de productividad de oficina
incluye Word (procesador de textos), Outlook (correo electrónico), Excel (hoja de
cálculo), Access (base de datos), OneNote (software para tomar notas) y
PowerPoint (diapositivas de presentación). Office 365 es un servicio de
suscripción basado en la nube que ofrece la suite por una tarifa mensual.
4.- Adobe Creative Suite o Cloud: Un paquete de software que incluye
aplicaciones de diseño y publicación digital, como Photoshop, InDesign,
Dreamweaver, Illustrator, Acrobat Pro y otros programas de soporte. Adobe
Creative Cloud es el servicio de suscripción basado en la nube que ofrece la suite
por una tarifa mensual.
5.- Apache OpenOffice: Paquete de software de productividad de código abierto
que incluye Writer (procesador de textos), Calc (aplicación de hoja de cálculo),
Impress (aplicación de diapositivas de presentación), Draw (aplicación de dibujo),
Base (aplicación de base de datos) y Math (editor de fórmulas).
6.- iWork: Paquete de software de productividad de oficina de Apple que incluye
las aplicaciones Pages (procesador de textos), Keynote (diapositivas de
presentación) y Numbers (hojas de cálculo). iWork para iCloud es la oferta
basada en la nube de Apple del paquete de software.
7.- Google Docs: Conjunto de aplicaciones de productividad de Google basado en
la web que incluye Docs (procesador de textos), Hojas de cálculo (hojas de
cálculo), Diapositivas (diapositivas de presentación) y Formularios. Los
documentos creados se pueden guardar en Google Drive, su servicio de
almacenamiento en la nube.
Laboratorio de la unidad 1
Tema: Trabajo colaborativo en Padlet

Objetivo: Añadir una publicación personal al trabajo colaborativo en Padlet.
Instrucciones:
1.- Seleccionar un tema relacionado con:
 Software de Sistema
 Software de aplicación
 Software Utilitario
 Software de programación
2.- Ingresar al Link de Padlet que se encuentra adjunto
3.- Incluir en la publicación
 Apellidos y nombres
 Tema
 Contenido
 Imagen
4.- Una vez terminada la publicación, debe exportar el archivo a formato
PDF. 5.- Subir el link de la publicación y el archivo PDF.
Trabajo grupal autónomo de investigación de la unidad 1
TEMAS DE EXPOSICIÓN
Grupo # 1 Tema: El Software. Clasificación del Software

Grupo # 2 Tema: Gestión de Inventario de Software
Grupo # 3 Tema: Gestión de licencias y parches
Grupo # 4 Tema: Software como servicio (SaaS)
Grupo # 5 Tema: Control de versiones del software. ¿Qué es Git?
Grupo # 6 Tema: Despliegue de software. Servicios de Despliegue
Grupo # 7 Tema: Empaquetado de software. Software empaquetado. Software
personalizado
UNIDAD II: Planificación de proyectos de Software.
2.1 Introducción
La Planificación es un proceso que comienza con una misión, metas y objetivos

que deben lograrse. Desarrolla planes, procedimientos, establece una
organización y asigna recursos y responsabilidades con el propósito de alcanzar
los objetivos propuestos. El resultado principal de la planificación es el Plan del
Proyecto.
2.2 Objetivos de la Planificación de Proyectos de Software.
El principal objetivo de la planificación en proyectos de desarrollo de software es

ordenar el qué hacer durante el proyecto y asignar adecuadamente los recursos
y tareas para cumplir los objetivos propuestos.
En general se planifica para:
 Organizar el qué hacer del proceso de desarrollo de software.
 Minimizar tiempo y costos involucrados.
 Maximizar el uso de recursos disponibles.
 Establecer hitos del proyecto.
 Medir el avance.
 Mejorar la comunicación.
 Obtener soporte técnico, de gerencia y político.
La planificación es una tarea que se desarrolla al inicio del proyecto pero rige el
resto de las fases. Una buena planificación inicial ayudará a que las metas
propuestas se cumplan y que los eventuales inconvenientes sean abordados de
mejor forma.
2.2.1 Principios y consideraciones para la Planificación
Todas las organizaciones planifican, pero por lo general no se realiza de la

manera adecuada, muchas veces la planificación se realiza de manera informal
cuando debiera ser formal. La planificación formal es aquella que es:
 Documentada.
 Uniforme y regularmente aplicada.
 Con resultados concretos, distribuidos, entendidos y comprometidos por
la organización.
En una planificación formal deben quedar claramente identificados:
 Planes
 Procedimientos
 La organización
 La asignación de recursos
 Las responsabilidades.
El proceso de planificación produce idealmente un conjunto de planes,
clasificados como esenciales y de soporte.
Los planes esenciales son aquellos que se consideran imprescindibles en cada

proyecto, dentro de estos están:
 Plan de Proyecto
 Plan de Pruebas
 Plan de Instalación
Los planes de soporte no siempre son necesarios, entre ellos están:
 Plan de Entrenamiento
 Plan de Control de Cambios.
La planificación es un proceso continuo, no es un esfuerzo que se realiza una

única vez en el proyecto. Si los mecanismos de control identifican algún
problema, probablemente los planes deberán ajustarse a esta nueva situación.
La planificación es un proceso de toma de decisiones. No se toman decisiones

futuras, sino más bien, se evalúa el impacto futuro de decisiones actuales. A
medida que se planifica se decide lo que debería hacerse y lo que no. Debe
comprometer a aquellos individuos que poseen la habilidad de poner en marcha
las cosas, obteniendo resultados concretos.
Al planificar no se intenta eliminar el riesgo, con o sin planificación existen

circunstancias que pueden atentar contra el éxito de un proyecto, la planificación
no puede prevenirlos, pero puede ayudar a reducir su impacto y a controlar el
riesgo.
La planificación de proyectos requiere soporte de la administración y de otras

áreas organizacionales. Todo el esfuerzo puede frustrarse cuando no se cuenta
con este soporte.
2.3 Ciclo de Planificación de Proyectos de Software.
El ciclo de planificación de proyectos de Desarrollo de Software, comienza

con los requerimientos iniciales y tiene las siguientes etapas:
2.3.1 Negociación de Compromisos
El jefe de proyecto y el cliente y/o usuario negocian los compromisos mutuos, los
cuales se establecen sobre la base de los requerimientos del producto de
software y objetivos del proyecto.
2.3.2 Descomposición de Requerimientos
El producto de software se divide en elementos claves denominados Estructuras

de División del Trabajo (EDTo WBS). Una EDT es un organigrama jerárquico
donde se establecen las distintas partes de un producto de software. Representa
una jerarquía de componentes o bien de procesos. La jerarquía de componentes
identifica cada uno de los componentes del software y la manera en que éstos se
relacionan. La jerarquía de procesos representa las actividades de trabajo
requeridas para desarrollar el software y sus interrelaciones. Si se usa este tipo
de EDT se deben considerar las fases, actividades y tareas estándares definidas
por la organización y también las tareas especiales del proyecto.
2.3.3 Estimación del Tamaño de un producto de Software
Una vez establecido el estándar de medición (Líneas de Código, Puntos de

Función, Puntos Objetos), se utiliza la EDT de componentes para estimar el
tamaño de cada componente del software. El tamaño total del producto de
software se obtiene al sumar los valores estimados para cada componente y al
ajustar la estimación de acuerdo a la información histórica de la organización, si
es necesario.
2.3.4 Desarrollo de Itinerario del Proyecto
El itinerario del proyecto se confecciona distribuyendo el esfuerzo estimado

dentro del marco de tiempo establecido. El itinerario debe considerar los hitos
del proyecto.
2.3.5 Término de fase y/o actividades.
El término de cada fase o actividades se establece formalmente y define un hito

o un producto.
2.3.6 Generación y entrega de productos.
En ciertas partes de itinerario es necesario que la actividad de generar el

producto sea explicita. Generalmente en proyectos de Software el producto es
un informe.
2.3.7 Puntos de control o Hitos del proyecto
El itinerario y las estimaciones resultantes se comparan con las necesidades

iniciales, si éstos se ajustan, los compromisos pueden ser hechos y el trabajo
puede proceder. Generalmente los costos son muy altos y el itinerario
demasiado largo, en este caso se requiere volver a la negociación de
compromisos y replanificar, si es necesario.
La existencia de una base de datos que registre información histórica de los

proyectos de Desarrollo de Software de una organización, permite contar con
factores de ajuste para estimaciones futuras, mejorando progresivamente el
proceso de planificación.
2.3.8 Estimación de Recursos
El tamaño del producto de software sirve de base para estimar esfuerzo

(Persona- Mes, Hombres-Hora), tiempo y costo de desarrollo. Los modelos
empíricos de estimación de costos de software cumplen este propósito. La
estimación de recursos puede hacerse en el ámbito de proyecto, de fases y de
actividades y tareas.
2.4 Plan del proyecto de desarrollo de Software.
Como se mencionó anteriormente, el Plan del Proyecto es el resultado principal

del proceso de planificación. Este plan existe sólo cuando está documentado,
distribuido, entendido y comprometido. El contenido básico del plan del
proyecto se indica en la siguiente Figura 7.
Figura 7: Contenido del Plan de Proyecto

 La Descripción del Proyecto proporciona las características generales de
éste.
 La Organización refleja la forma en que el grupo de proyecto ha sido
estructurado para llevar a cabo el trabajo y los responsables de las
funciones clave.
 Los Productos a Entregar incluyen los documentos u otro tipo de
producto, con compromiso de entrega al usuario o a otros grupos de
trabajo interno del proyecto, así como los responsables de la entrega.
 El Calendario comprende tanto las estimaciones realizadas para
confeccionar y justificar el itinerario del proyecto, como éste mismo.
2.4.1 ¿Para qué se usa el plan del proyecto?
Los proyectos de Desarrollo de Software involucran a diversos participantes y

cada uno de ellos da un uso distinto al plan del proyecto, como se muestra en la
figura 8.
Figura 8: Uso del plan de Proyecto
2.5 Fallas en la Planificación.
Los problemas más comunes que enfrentan hoy en día los proyectos de
desarrollo de software, tales como: retrasos en la entrega del producto final,
aumento de los costos de desarrollo y mantenimiento y escasa calidad del
software, se deben principalmente a una mala o escasa planificación. Las
principales causas de las fallas en la planificación de proyectos de desarrollo de
Software son las siguientes:
 Inadecuada definición del proyecto.
 Comprensión errónea del problema.
 Desconocimiento o inexperiencia de cómo planificar.
 Incumplimiento del ciclo de planificación.
 Escasa negociación de compromisos con el usuario al inicio del proyecto
 Definición incompleta de los requerimientos.
 Estimaciones optimistas.
 Supuestos y restricciones del proyecto inválidos o no verificados.
 Aplicación errónea o no-utilización de la información histórica de la
organización.
 Mala administración del proyecto.
 Fallas en el uso de los planes.
 Carencia de control de cambios.
 Escasa motivación.
 Estilo erróneo de liderazgo.
 Carencia de control y gestión.
 Organización errónea del grupo de trabajo.
2.6 Especificación de Requerimientos.
La especificación es el resultado del proceso de planificación y puede ser vista

como un proceso de representación. La ejecución del plan concluye en la
instanciación de un producto o proceso en particular. La especificación del
producto describe la visión externa del producto. La especificación del proceso
describe cómo realizar un determinado proceso.
La especificación de requerimientos es una descripción detallada y precisa de la

funcionalidad del sistema teniendo en cuenta las restricciones del mismo.
Generalmente, la especificación de requerimientos sirve como base para el
contrato entre los desarrolladores y el cliente. Como ejemplo, la especificación
del diseño de Software. Esta puede contener:
 La especificación del tipo de producto de entrada (producto de los
requerimientos), incluyendo una sintaxis formal y descripción semántica
para el documento de requerimientos (ANSI / IEEE-Std-830).
 La especificación del tipo de producto de salida (producto del diseño),
incluyendo una sintaxis formal y la descripción semántica para el
documento de diseño.
 La especificación del tipo de proceso (proceso de diseño), incluyendo una
pauta para el uso de una técnica de diseño específica, como Diseño
estructurado o Diseño Orientado a Objetos (DOO).
Esta fase trata de aclarar qué es lo que un sistema debe de hacer. Describe la
función y el rendimiento del sistema y las restricciones que gobernarán su
desarrollo. También describe la información (control y datos) que sirve de
entrada y salida al sistema. Es evidente que, en esta etapa, el sistema objetivo
está sujeto a muchos cambios antes de que sea realmente implantado.
2.6.1 Principios para una buena especificación
Para la especificación Balzer y Goldman proponen ocho principios para una

buena especificación:
 Principio 1: Separar funcionalidad de implementación.
Las especificaciones deben describir que se desea realizar, no cómo se va
a realizar.
 Principio 2: Se necesita utilizar un lenguaje de especificación de sistemas
orientado a procesos.
Si se considera un entorno dinámico, donde los cambios afectan al
comportamiento de algunas entidades, entonces los sistemas no pueden
ser representados formalmente. Por lo tanto, se puede usar una
descripción orientada al proceso, en la cual la especificación se obtiene
mediante un modelo de comportamiento deseado en términos de
respuestas funcionales ante distintos estímulos del entorno. Ejemplo,
Sistemas Empotrados.
 Principio 3: Debe abarcar el sistema del cual el software es un
componente.
Un sistema resulta de la interacción de sus componentes. Sólo dentro del
contexto del sistema completo y de la interacción entre sus partes puede
ser definido el comportamiento de un componente específico.
 Principio 4: Debe abarcar el entorno en el cual opera el sistema.
Se debe especificar el entorno en el cual el sistema opera e interactúa. Es
necesario reconocer que el propio entorno es un sistema compuesto de
objetos que interactúan, pasivos y activos. Con ello se permite especificar
la “interfaz” del sistema.
 Principio 5: Debe ser un modelo cognitivo.
La especificación debe ser un modelo cognitivo, en vez de un modelo de
diseño o de implementación, debe describir un sistema tal como es
percibido por su comunidad de usuarios y los objetivos que manipula
deben corresponderse con objetivos reales de dicho dominio.
 Principio 6: La especificación debe ser operacional.
La especificación debe ser completa y lo suficientemente formal para que
pueda usarse para determinar si una implementación propuesta satisface
la especificación, en casos de prueba elegidos arbitrariamente.
 Principio 7: La especificación debe ser tolerable con la incompletitud y
ampliable.
La especificación nunca está totalmente completa ya que el entorno en el
que existe es demasiado complejo para esto, por lo que la especificación
es una abstracción de alguna situación real o imaginada. Las herramientas
de análisis que apoyan y prueban la especificación deben ser capaces de
tratar con la incompletitud. Esto debilita el análisis.
 Principio 8: Debe ser localizada y débilmente acoplada
Los principios anteriores tratan con la especificación como una entidad
estática. Aun cuando la especificación debe servir como base al diseño y
la implementación, no es un objeto estático sino más bien dinámico ya
que sufre considerables modificaciones. Estas modificaciones se
presentan tres actividades: formulación, desarrollo, y mantenimiento.
2.6.2 Terminología y modelo de referencia para el ciclo de vida del Software.
Las especificaciones del proceso y los productos “se crean para”, “se usan en”,
“son afectadas por” y “son modificadas durante” cada fase en particular. Las
fases de acuerdo al modelo adoptado son: necesidades del Software,
requerimientos del cliente, requerimientos del diseñador, diseño del Software y
construcción. Se pueden incluir otras fases: verificación y validación, integración,
mantenimiento y entrenamiento.
El modelo de referencia es el que se muestra en la Figura 9, en la columna de la

izquierda. Aquí se distinguen los siguientes tipos de productos:
Figura 9:Terminología y modelo del ciclo de vida de referencia
Figura 10:Preguntas para cada etapa del Ciclo de Vida Estándar

2.6.3 Especificación del Software
Propósito y Contexto.
La especificación describe todas las características importantes de un producto o
proceso particular en algún formato. Las características deseables, así como el
formato adecuado para representarlas, están determinadas por el propósito y
contexto del tipo dentro del proyecto de desarrollo de Software.
Perspectiva del producto.

Las especificaciones están dirigidas a crear los productos del ciclo de vida (que
son los productos del proyecto) a satisfacción del usuario. Se caracterizan los
tipos de productos por aplicación y requerimientos de calidad.
Tipo de Aplicación.
El tipo de aplicación tiene un fuerte impacto en los productos y procesos que
necesitan ser especificados. Las posibles clasificaciones son basadas en las
características de los flujos de control del Software (secuencial, concurrente,
tiempo real), o basadas en la aplicación (comercial, sistemas, control de
procesos, científica, integrada).
Requerimientos de calidad.
Estas características tienen impactos en los aspectos que deben ser especificados
y en sus atributos. Algunas características posibles son: confiabilidad, correctitud,
tolerancia a fallas, mantenibilidad, portabilidad, amigabilidad, disponibilidad.
Perspectiva del proceso.

Se caracteriza en términos del modelo de ciclo de vida y las fases
individuales.
2.7 Procesos y productos del ciclo de
vida Comunicación.
La existencia de las especificaciones permite que los miembros del equipo
alcancen un consenso acerca de sus roles, haciendo explícitos los objetivos,
contexto y procedimientos del proyecto. Son un medio para enseñar y entrenar
al personal.
Creación de productos.
Muchas de las tareas de un proyecto están orientadas a crear, en una forma
trazable, instancias de un tipo de producto en otro (por ejemplo, un producto del
diseño a partir de los requerimientos del Diseñador). Las especificaciones
explícitas para los tipos de productos y los procesos creativos, ayudan a guiar y
controlar las tareas. Si todas las especificaciones son completas y formales, el
producto deseado puede ser creado automáticamente.
Modificación de productos y procesos.

Los proyectos de Software deben adaptarse oportunamente a los cambios. Un
cambio o aumento de requerimientos durante el mantenimiento requiere
modificar productos existentes, cambiando o no las especificaciones del
producto. El cambiar el proyecto o las características ambientales, ya sea
agregando nuevo personal o introduciendo nueva tecnología, requiere modificar
los procesos existentes y posiblemente las especificaciones subyacentes. La
existencia de especificaciones explícitas del producto y el proceso, permite
incorporar cambios en forma sistemática.
Productos de validación y verificación.

El propósito de la V&V es demostrar que algún producto del ciclo de vida, el
código por ejemplo, es consistente con el producto del ciclo de vida de tipo
diferente, el producto del Diseño por ejemplo. Este tipo de chequeo cruzado
entre productos se facilita si existen especificaciones explícitas.
Certificación de cumplimiento a lo planificado.

La certificación de calidad del Software (SQA) se refiere a la certeza de que el
desarrollo de Software se realiza de acuerdo al plan. Mucho del trabajo de SQA
es comparar los productos de Software y los procesos con sus especificaciones.
Es importante tener en cuenta los estándares.
Perspectiva del personal.

Las especificaciones se crean o son usadas por diferentes audiencias que juegan
diversos roles en el proyecto. Aunque algunas especificaciones están dirigidas
para ser usadas por máquinas, las personas deben comprenderlas. Las personas
que participan en un proyecto de software son:
 Cliente.
 Usuario final.
 Sub contratista.
 Analista de requerimientos.
 Ingeniero de especificación.
 Diseñador.
 Codificador.
 Personal de Verificación y Validación.
 Personal de SQA (Software Quality Assurance).
 Personal de SCM (Software Configuration Management)
 Personal de Mantenimiento
 Gerente.
Es por esto que los documentos deben ser elaborados con tal claridad, que toda
persona que lo lea y analice, debe entender los mismos requerimientos. En otras
palabras la documentación debe ser clara, completa y precisa.
Contenido.
El contenido se caracteriza por aquellos aspectos y atributos necesarios para el
producto o proceso.
Aspectos especiales.
Se requieren algunas definiciones previas para caracterizar el contenido tanto del
producto como del proceso.
 Dinámica. Característica relativa al uso. En un proceso pueden ser
capturadas durante su ejecución, por ejemplo, el conjunto de decisiones
tomadas por el diseñador o datos históricos sobre la cantidad de tiempo
requerida para el diseño en proyectos pasados.
 Estática. Características de un objeto relativo a su representación. Las
características estáticas de un proceso tienen que hacerse durante su
especificación (los pasos en un proceso de Diseño) Los aspectos estáticos
en un producto se describen en el producto en sí y en sus
especificaciones (estructura de datos o estructuras de control
algorítmicas).
 Funcionales. Características de un objeto de cualquier tipo relativo a sus
requerimientos de funcionamiento. (funciones como almacenar y
recuperar).
 No funcionales. Se identifican al analizar cómo son provistos los servicios
por el objeto (una de las funciones del producto debe ser provista en un
tiempo menor que “t”, el producto del diseño debe ser obtenido para un
determinado proceso dentro de un lapso de tiempo y presupuesto dado).
 Externa. Característica de un objeto visto como caja negra.
 Interna. Característica de un objeto visto como caja blanca.
Se utilizarán estas definiciones para caracterizar y explicar aspectos del producto
o proceso que se desean establecer en las especificaciones.
 Comportamiento (externo, dinámico): La respuesta externa observable
del producto o proceso frente a un estímulo estando en uso real. Puede
incluir estados externos observables, salidas o condiciones de borde en la
validez de entradas y estados.
 Interfaces (externa, estática): La estructura de la frontera entre el
producto o proceso y su ambiente.
 Flujo (interno, dinámico): La dinámica interna de un producto o proceso
en uso. Esto puede incluir los flujos de control, data, e información entre
las unidades estructurales del producto o proceso.
 Estructura (interna, estática): La organización de un producto o proceso
en partes interactuantes. Incluye la descomposición en unidades básicas.
La estructura de datos, algorítmico, o de arquitectura, así como las
interfaces internas entre superestructuras, es de interés.
Atributos.
En general cada uno de los aspectos anteriores puede ser representado en una
variedad de formas. El propósito y contexto del producto o tipo de proceso de
interés, requieren una forma adecuada para mostrar ciertos atributos. Por
ejemplo, si el flujo de datos de un producto de diseño necesita ser validado, se
puede especificar que su representación necesita exhibir los atributos de
consistente y ejecutable.
Representación.
Ciertos aspectos del Software deben ser representados de manera de exhibir
los atributos deseados. El formato de representación usado se basa en modelos y
lenguajes. Los modelos permiten la formulación de aspectos de interés. Los
lenguajes permiten un reflejo fiel de esos modelos en una forma tal que muestra
los atributos deseados. Algunos modelos son:
 Modelos funcionales.
Input - output, algebraicos, axiomáticos.
 Modelos de estado finito.
Cartas de estado.
 Modelos de estímulo repuesta.
 Modelos de redes de Petri.
 Modelos de estructura de datos.
 Modelos de flujo de información.
 Modelos de estructura de datos.
 Modelos entidad relación.
 Modelos relacionales.
Lenguajes.
Se distinguen entre Formales, semiformales e informales. Hay diferentes
paradigmas de lenguajes: imperativo, declarativo u orientado a los datos. La
elección del lenguaje se acota con el problema, las habilidades del equipo de
desarrollo y los requerimientos específicos del cliente.
Soporte.
Es necesario tener un soporte eficaz para crear las especificaciones.
UNIDAD III: Mediciones en producto y proceso de Software.
3.1 Introducción
Trabajo individual autónomo de investigación unidad 3
Investigar
Trabajo grupal de Investigación Unidad 3
Laboratorio de la Unidad 3:
UNIDAD IV: Aseguramiento de la calidad del Software.
4.1 Introducción
Laboratorio Unidad
 .
Trabajo grupal de investigación Unidad 4

Rúbrica 1: Para informe de investigación
Rúbrica: Tarea individual de investigación Valor: 10 puntos
Contenido
Desarrollo de actividades
Excelente (2 puntos) Aceptable (1,5 puntos) Suficiente (1 punto) Mejorable (0,5 punto)
Se ha profundizado en las El contenido se ajusta a lo El contenido es general, El contenido es
actividades y el contenido solicitado, pero no se ideas excesivamente excesivamente escaso.
se ajusta a lo solicitado y profundiza o se tiene generales y/o simples.
está correctamente alguna carencia.
relacionado con la
materia.
Organización
Formato y estructura
El formato es el indicado El formato es el indicado El formato es parecido al El formato es parecido al
por el tutor y se ajusta a por el tutor y se ajusta a indicado por el tutor y indicado por el tutor,
las normas APA 7ma las normas APA 7ma similar a las normas APA pero no corresponde a
edición, con todos los edición, excepto algunos 7ma edición, pero faltan las normas APA 7ma
contenidos, los apartados apartados e imágenes que algunos apartados e edición.
e imágenes que completan el contenido. imágenes que completan
completan el contenido. el contenido.
Redacción
Gramática, ortografía y puntuación
El documento no presenta El documento presenta El documento presenta El documento presenta
errores gramaticales, menos de 3 errores entre 3 y 5 errores múltiples errores
ortográficos o de gramaticales, ortográficos gramaticales, ortográficos gramaticales,
puntuación. o de puntuación. o de puntuación. ortográficos o de
puntuación en todo su
contenido.
Originalidad
Originalidad en los contenidos
Nivel adecuado de El documento se presenta Muchos contenidos son de El trabajo es similar o
originalidad, los de forma original y el copia y pega de fuentes idéntico a otros trabajos
contenidos son en general contenido en su gran consultadas, no cita las presentados.
de elaboración propia, cita mayoría de elaboración fuentes consultadas, pero
correctamente las fuentes propia, cita algunas existe contenido de
consultadas. No es similar fuentes consultadas. No elaboración propio. No es
a otros trabajos es similar a otros trabajos similar a otros trabajos
presentados. presentados. presentados.
Puntualidad
Entrega en el plazo
Excelente (2 puntos) Avanzado (1,5 puntos) Aceptable (1 punto) Mejorable (0,5 punto)
El trabajo se entrega en la El trabajo se entrega un El trabajo se presenta El trabajo no se presenta.
fecha y hora establecida, poco más tarde respecto a fuera de fecha.
incluso antes. la fecha y hora
establecida.
Rúbrica 2: Para evaluar actividad de laboratorio
Rúbrica: Evaluación de actividad de laboratorio Valor: 10 puntos
Estructura
Estructura y modelado
El laboratorio contiene El laboratorio contiene la El laboratorio se aleja El laboratorio no
la estructura y el estructura y el modelado de la estructura y el contiene la estructura
modelado solicitados solicitados por el tutor, modelado solicitados por ni el modelado
por el tutor, además no presenta mejoras. el tutor, se presumen solicitados por el tutor.
presenta mejoras mejoras. No hay mejoras
Funcionalidad
Ejecución y funcionamiento
El laboratorio funciona El laboratorio funciona El laboratorio El laboratorio no
correctamente, no correctamente, presenta funciona funciona correctamente,
contiene errores en la pocos errores en la parcialmente, presenta presenta muchos errores
ejecución, cumple con ejecución, cumple con pocos errores en la en la ejecución, no
el el ejecución, cumple
objetivo de la objetivo de la medianamente el objetivo cumple el objetivo de la
misma. misma.
de la misma.
misma.
Código ordenado y entendible Programación
Desarrolla un código Desarrolla un código Desarrolla un código poco Desarrolla un código
ordenado, utiliza buenas bastante ordenado, utiliza ordenado, no utiliza desordenado, no utiliza
prácticas de programación, pocas prácticas de prácticas de programación, prácticas de
es de fácil entendimiento. programación, es de es de mediano programación, es de
fácil entendimiento. difícil entendimiento.
entendimiento.
Diseño
Originalidad en el diseño
Nivel adecuado de El diseño se presenta de El trabajo es copia de El trabajo es similar o
originalidad en el forma original, en su otro diseño, es de poca idéntico a otros trabajos
diseño, tiene gran mayoría de elaboración propia. No presentados.
elaboración propia. No elaboración propia. No es similar a otros
es similar a otros es similar a otros trabajos presentados.
trabajos presentados. trabajos presentados.
Puntualidad
Entrega en el plazo
Excelente (2 puntos) Avanzado (1,5 puntos) Aceptable (1 punto) Mejorable (0,5 punto)
El Laboratorio se entrega El Laboratorio se entrega El Laboratorio se presenta El Laboratorio no se
en la fecha y hora un poco más tarde fuera de fecha. presenta.
establecida, incluso antes. respecto a la fecha y hora
establecida.
Rúbrica 3: Para evaluar actividades grupales.
Rúbrica: Trabajos grupales Valor: 10 punto
Secuencia
nte (2 puntos) Aceptable (1,5 puntos)Suficiente (1 punto)Mejorable (0,5 pu
as principales y secundarias Las
del ideas
grupo,principales
están presentadas
Las
y secundarias
ideas en
principales
undel
orden
grupo,
yLas
lógico.
están
ideaspresentadas
princ secundarias
en undel grupo,secundaria presentan poca secuencia carecen
orden más o menos lógico. lógica.
ntos)Suficiente (1 punto) Presenta un organizadorPresenta un organizadorPresenta un organi de texto y gráfico original de texto y gráfico algode texto y
e innovador.innovador y armónico.or
Calidad de la info
Excelente (2 puntos) Aceptable (1,5 puntos) Sufici

La presentación contiene La presentación contiene La
información importante y información importante y
relevante sobre el tema. poco relevante sobre e
tema.
Excelente (2 puntos) Aceptable (1,

El documento no presenta El docume
errores gramaticales, menos
ortográficos o de gra
puntuación.
Excelente (2 p
El Laborato en la fec estab
La Concordia, 2021/08/30
Elaborado por: Revisado por: Aprobado por:
Ing. Javier Mendoza, Mgs. Ing. Miguel Boné, Mgs. Dr. Jorge Puyol, Msc.
DOCENTE ASIGNATURA RESPONSABLE DE DIRECTOR DE
CARRERA EXTENSIÓN

Guia TI 8A Gestión de Software

Cargado por

Copyright:

Formatos disponibles

Guia TI 8A Gestión de Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guia TI 8A Gestión de Software

Cargado por

Copyright:

Formatos disponibles

GUÍA DIDÁCTICA

TUTOR: ING. JAVIER

SEDE SANTO DOMINGO DE

UTELVT. 2021 IS – Ing. Javier Mendoza Loor, Mgs.

UTELVT. 2021 IS – Ing. Javier Mendoza Loor, Mgs.

UTELVT. 2021 IS – Ing. Javier Mendoza Loor, Mgs.

DETALLE DEL CONTENIDO Y METODOLOGÍA DE CONSTRUCCIÓN DE LA GUÍA

Dada la complejidad de la gestión de software en la infraestructura de TI, se hacen

UTELVT. 2021 IS – Ing. Javier Mendoza Loor, Mgs. Pág. 1

UNIDAD I: Componentes de la gestión de Software.

Gestión de Software es la gestión, planificación y organización de las aplicaciones

Figura 1: Gestión de Software

La seguridad también desempeña un papel importante en el ámbito del control

Los responsables de TI suelen tener un presupuesto limitado. Una administración

La correcta gestión de software es clave para la satisfactoria conclusión del

1.2 Clasificación del Software

La palabra Software traducida literalmente seria: partes blandas o suaves de la

1.2.1 Software de sistema

Su objetivo es desvincular adecuadamente al usuario y al programador de los

Figura 2: Software de Sistema

1.2.2 Software de aplicación

Figura 3: Software de Aplicación

1.2.3 Software de programación

Un software de programación es el conjunto de utilidades y herramientas

1.3 Gestión de Inventario de Software

El desconocimiento del software instalado en las empresas es un problema

1.3.1 ¿Por qué hacer un inventario de software?

“Conozco perfectamente todo el software instalado en mi empresa”. “Como

Es habitual escuchar estas frases en incontables organizaciones, siempre dichas

1.3.2 ¿Cómo hacer un inventario de software?

No se puede abordar la problemática acerca de cómo hacer un inventario de

Figura 5: Gestión de inventario de Software

En cambio, con las herramientas sin agentes, es necesario ejecutar un

1.3.3 Contrastar la información de los inventarios

Tener un buen control de inventarios con el software de gestión de inventarios

1.3.4 Recopilar la información de los derechos de uso

Muchas veces resulta terriblemente complejo recopilar esta información. Hay

1.3.5 Información complementaria para conformar el inventario

No es conveniente autoengañarse pensando que, aunque no hayamos localizado

1.4 Gestión de licencias y parches

Los editores de software (como Adobe, Microsoft) auditan de manera periódica

Según un estudio realizado, el 69% de los ejecutivos de TI no están seguros de

1.4.2 Gestión de parches para sistemas operativos

Teniendo en cuenta la gran cantidad de parches que se lanzan cada día, es

1.4.3 ¿Por qué es tan importante la gestión de licencias y parches?

La aplicación de parches no sólo permite que los sistemas y las aplicaciones

1.4.4 ¿Cómo es un proceso de Gestión de Parches eficaz?

A continuación se presenta una plantilla de 10 pasos, la cual destaca las

1.4.5 Mejores prácticas de gestión de parches

1.5 Software como servicio (SaaS)

Software como un Servicio, abreviado ScuS (del inglés: Software as a Service,

1.5.1 ¿Qué es Software as a Service?

SaaS, o Software as a Service, es una forma de poner a disposición softwares y

1.5.2 Requisitos, Costo –

1.5.3 Soluciones de tecnologías SaaS

Figura 6: Soluciones de tecnologías SaaS

1.5.4 Softwares hospedados

Tradicionalmente, los negocios han tenido que crear y mantener una

1.5.5 Cómo alcanzar el éxito con el SaaS