1

Metodología de Implementación de Sistemas

Distintos participantes deforman la necesidad del cliente, el usuario tampoco sabe lo que necesita.
¿Como se mide si tuvo éxito de un sistema de información?

 Utilización del Sistema de Información

 Satisfacción del usuario (Como el sistema mejora el trabajo de los usuarios)
 Actitud favorable del usuario hacia los responsables del sistema.
 Logro de objetivos (Cumplimiento de metas planeadas)
 Recompensa financiera
Metodología: Enfoque de un problema de manera total, organizada, sistemática y disciplinada.
El uso de metodologías aceptadas es un modo inteligente de minimizar riesgos, calcular costos, asignar
recursos y tiempos.

Objetivos de las metodologías podemos mencionar:

 Describir como hacer técnicamente para obtener el producto (proceso)
 Servir como elemento de comunicación (herramientas de documentación).
El proceso de comunicación en el momento de desarrollo es de gran trascendencia para:
 Que el analista interprete las necesidades del usuario.
 Lograr que los constructores interpreten las especificaciones, construyendo lo diseñado.
La comunicación hacia el futuro es de gran trascendencia para que quienes se ocupen de la utilización,
operación y mantenimiento del sistema, tengan la información suficiente para realizar sus tareas.
Prototipos como herramienta de comunicación
Son representaciones del sistema en desarrollo para que el analista pueda representar su visión final a los
ojos del usuario. Pueden limitarse la visión externa del sistema (imágenes de pantallas y listados) o simular
su comportamiento incluyendo alguna funcionalidad de la aplicación.
Al presentar el prototipo al usuario se completa el ciclo de comunicación, validando los requerimientos y
facilitando los ajustes que se detecten. En la actualidad las metodologías dominantes son: la
metodología de análisis y diseño estructurado y diseño orientado a objetos.
Metodologías de análisis y diseño estructurado
Propone la construcción de un "modelo lógico" del sistema mediante la descomposición gradual de los
requerimientos del negocio, para llegar a funciones elementales, sobre las cuales se detallan las
especificaciones para la programación y se realizan los ajustes necesarios para la implementación física.
La descomposición del sistema facilita su comprensión por parte del usuario y desarrolladores como su
construcción y mantenimiento.
El análisis se realiza desde dos visiones complementarias, la de datos y la de procesos.
 Los procesos, específicos para el sistema tratado, interactúan con los datos. DFD
 Los datos se encuentran disponibles tanto para estos procesos, como para otros que los requieran, en
un entorno de integración de múltiples aplicaciones.
Este enfoque permite, facilitar la reutilización de datos, para lograr una integración eficaz y efectiva de las
aplicaciones.
Metodologías orientadas a objetos
A diferencia de los métodos estructurados, que separan datos de procesos, el enfoque de análisis y diseño
orientados a objetos (ADDO) une datos y procesos en artefactos denominados “objetos”. Un objeto puede
ser un lugar, una persona o una cosa relevante para el sistema, por ejemplo un cliente, una factura, un
empleado, un proveedor.
Tiene por objetivo la construcción de un modelo que interprete la complejidad del sistema objeto y la
 2

determinación de su equivalente lógico. La implementación física posterior dependerá de los lenguajes y

bases de datos utilizados.
En los términos ADDO un objeto es todo conjunto cohesionado (adherido fuertemente, atraído
internamente), integrado por:
 Atributos (datos organizados)
 Servicios (referentes lógicos de los procesos de transformación, operaciones, los cuales reciben y
entregan información al exterior del objeto por medio de parámetros)
 Métodos (forma en que se implementan los servicios; un mismo servicio puede implementarse con
diferentes métodos, dependiendo de la tecnología que se utilice)
El armado conjunto de atributos, servicios y métodos se denomina “encapsulado” (provoca “ocultamiento
de información”, haciendo visibles y accesibles los datos solo mediante los servicios implementados):
 Protege los datos del uso arbitrario
 Oculta los detalles de la implantación interna a los usuarios de un objeto, por lo que los usuarios conocen
los servicios que puede solicitar del objeto, pero desconocen los detalles de cómo se llevan a cabo.
 Al separar el comportamiento del objeto de su implantación, permite la modificación de esta sin que se
tengan que modificar las aplicaciones que lo utilizan, en la medida que se mantengan los servicios.
Los objetos tienen las siguientes características:
1) Clasificación: Una clase es un grupo de objetos que tiene atributos y comportamiento similares.
2) Identidad o instanciación: Objetos con iguales atributos y servicios son distinguibles entre sí, debido a que
tienen una característica distintiva de “identidad”.
3) Jerarquía y herencia: Las clases se encuentran relacionadas jerárquicamente, y comparten atributos y
servicios tomando como base esa relación jerárquica. Una clase puede incluir sub-clases.
Esta es una característica fundamental y trascendente, ya que permite que conociendo el comportamiento
de la “clase” se sabe que la subclase tiene el mismo comportamiento, más otros comportamientos
adicionales específicos de ella.
4) Polimorfismo: Un mismo servicio puede comportarse de manera diferente en distintas instancias de una
misma clase, por aplicación de un método diferente.
Durante el proceso de diseño se realiza la “segmentación”, esto es la asignación de responsabilidades a una
clase de objetos, para lo que se requiere.
Se “centralizan” todas las funciones que correspondan al mismo objeto, es decir, utilizan los mismos datos y
realizan la misma transformación, generando economías en el desarrollo y el mantenimiento al garantizar la
reusabilidad.
Para unificar varias herramientas se construyó un lenguaje unificado de modelado, conocido como UML.

Distinción entre "metodología" y "técnica". La técnica se considera como un componente de la metodología,

como el medio o procedimiento que se usa para realizar la metodología misma.
El Ciclo de vida del SI tiene 2 grandes etapas: COSTRUCCIÓN Y VIDA PRODUCTIVA
 3

Proyecto: Lo concibo, construyo y lo pongo en funcionamiento

Beneficio: Expectativa de que el proyecto produzca un beneficio (reducción de costos, mayores clientes…)
en términos económicos. Luego empieza a quedar obsoleto y los beneficios caen. El beneficio se tiene que
medir para saber si implementar el proyecto o no.

Costos de operación y mantenimiento: Crecen cuando se empieza a implementar. El tiempo que requiera
para que funcione decentemente debe ser el menor posible, cuando más tarde, más caro. Luego bajan hasta
que coincide con el período en que ya no da tanto rendimiento.
Discontinuación: En el punto de obsolescencia el sistema cuesta más que lo que genera.

INTERRELACIÓN ENTRE CICLO DE VIDA, MODELOS DE DESARROLLO Y METODOLOGÍAS DE ANÁLISIS Y

DISEÑO:
La aplicación de diferentes tecnologías concurre en la incorporación y puesta en marcha de sistemas de
información, las principales son:
 Tecnologías de modelos de desarrollo.
 Tecnologías de gestión de proyectos para el control del proceso de selección, desarrollo, incorporación
y operación de los sistemas.
 Tecnología de análisis y diseño de software.
Ciclo de vida: Etapas por las que pasa un sistema a lo largo de su vida, desde su concepción hasta el abandono
en su uso. Etapas:
a) Definición: Incluye el establecimiento de la visión externa del sistema, sus límites y alcances, la
estimación del costo y esfuerzo requerido y la decisión de incorporarlo. Esta tarea es la de mayor impacto
en el ciclo de vida y en el costo del sistema. Con la correcta ejecución se podrá:
 Identificar las necesidades del usuario.
 Determinar el alcance del proyecto.
 Identificar alternativas de realización.
 Realizar el cálculo de costo-beneficio y el plan global de trabajo de las alternativas de solución,
incluyendo tanto el desarrollo del proyecto como de la operación posterior.
La definición de requerimientos debe ser:
 Suficiente para estimar el grado de complejidad del desarrollo
 Suficiente para estimar el esfuerzo y las inversiones necesarias
 Suficiente para estimar razonablemente el costo incremental de operar y mantener el sistema
 Suficiente para poder evaluar el grado de cumplimiento de los objetivos
En esta etapa la participación de usuario es trascendente. El proceso de comunicación entre usuarios y
analistas funcionales, y entre éstos y analistas técnicos resulta fundamental para comprender
adecuadamente los requerimientos reales que debe cumplir el nuevo sistema de información.
b) Incorporación: Incluye todas las actividades necesarias para su adquisición y/o construcción y puesta en
marcha. Incluye las siguientes etapas o fases secuenciales:
 Organización y planeamiento;
 Ejecución y control (Análisis y diseño, Adquisición, construcción y prueba, Puesta en Marcha);
 Finalización.
La puesta en marcha incluye las tareas de:
 Entrenamiento a usuarios
 Conversión y/o vuelco de datos
 Instalación de hardware y relacionados
 Prueba operativa, seguimiento y ajustes
 4

 Operación inicial del sistema

Un sistema puede ser un excelente desarrollo, pero inútil. Con la implantación se corona la tarea de
desarrollo, verificándose la correcta interpretación de los requerimientos del usuario y el buen desarrollo
de las tareas posteriores.
c) Operaciones o utilización: La utilización corresponde a la vida útil del sistema, durante la cual estará
sometido a mantenimiento, es decir, ampliaciones y correcciones. El mantenimiento, en particular
cuando requiere aplicación de significativa cantidad de recursos, debe tratarse como un proyecto en sí
mismo. Durante la etapa de operación del sistema una de las actividades distintivas es la de resolver la
continuidad o el abandono. La continuidad se puede desaconsejar por los siguientes motivos:
 Alto costo de mantenimiento
 Limitaciones de funcionalidad que impiden realizar las ampliaciones correspondientes
 Funcionalidades cubiertas por otras aplicaciones o falta de necesidad de seguir operando el sistema,
por haber dejado de aportar funcionalidades necesarias.
d) Abandono: Por último, el sistema es dejado de lado, siendo o no remplazadas sus funcionalidades por
otro. En caso de remplazo, las actividades de transición correspondientes al abandono se deben
considerar en el nuevo proyecto.

Ciclo de Vida del Desarrollo:

1. El ciclo de vida es la serie de fases por las que atraviesa el desarrollo de un producto de software,
desde su inicio hasta su puesta en marcha.

2. En general se pueden identificar las siguientes etapas genéricas

Visión Global del Desarrollo de Sistemas

Análisis  Definición del problema Responde a QUÉ
 identificación de la solución Usuario activo
 análisis de factibilidad
 estimación de esfuerzo, recursos y duración
 identificación de riesgos
 Especificación de requerimientos
Diseño  Si se trata de realizar el desarrollo: Diseño lógico y Físico. Responde a CÓMO
 Si se trata de adquisición de sistema existente: identificación de las partes
a customizar y adaptaciones a realizar
Desarrollo  Si se trata de un nuevo desarrollo: Codificación del sistema. (Es el más costoso)
 Si se trata de adquisición de sistema existente: configuración y
parametrización del sistema.
Prueba Comprobación del funcionamiento del sistema: Usuario activo
 Pruebas unitarias: Lo hace el programador para ver si funciona.
 Prueba de Sistemas: El usuario ve si satisface su expectativa.
 5

 Pruebas de Aceptación de Usuario: Todos los sistemas juntos en una

simulación de la vida real.
Otras Clases de pruebas.
Capacitaciones
Implement Implantar el nuevo sistema. Usuario activo
ación Estrategias posibles:
 Paralela: Ambos sistemas al mismo tiempo.
 Cambio Directo: Es una sucursal o área pequeña.
 Estudio Piloto
 Por Fases: Primero un área y después se van incorporando de a poco.
Producción Monitoreo del sistema para detectar: Usuario activo
 Errores
 Modificaciones
 Mejoras

Las Necesidades / Requerimientos

 Requerimientos funcionales: Usuarios finales, uso del día a día
 Requerimientos técnicos:
 Requerimientos de hardware: Equipos físicos
 Requerimientos de sistema operativos y software adicional
 Requerimientos de seguridad: Roles y perfiles
 Requerimientos de escalabilidad, integración y performance
 Requerimientos de soporte y mantenimiento
 Facilidad de uso
Hacer o Comprar?
Ningún paquete va a satisfacer la totalidad de los requerimientos.

 El Desarrollo de los Proyectos de Implementación de Paquetes:

Funcionalidad

del Paquete (80%)

Requerimientos
 Análisis: Identificación
de las Brechas
Brecha (20%)  Diseño: Diseño de
adaptaciones para
cubrir la brecha
Funcionalidad
del Paquete (50%)
Requerimientos
Si no se planificaron bien los
requerimientos, van a
aparecer requerimientos no
previstos que seguramente no
Brecha (50%)
estén cubiertos por el paquete
Requerimientos
no previstos
 6

Brecha:

1) Adaptar los procesos de negocio de la empresa a los procesos basados en mejores prácticas que están
incluidos en el paquete de software
2) Adaptar el paquete a los procesos de la empresa
a) Explorar todas las opciones de configuración al máximo
b) Modificar el código del paquete

Compra de Paquetes de Software de Aplicaciones

Positivo
 Menor costo de desarrollo
 Menores tiempos de implementación
 Mayor seguridad
 Tercerización del mantenimiento de la aplicación
 Implementación de mejores prácticas del
mercado
 Facilita la estandarización de procesos a lo largo
de la organización
 Utilización de estándares probados de desarrollo
 Utilización de lenguajes de programación
probados y estándar
 Utilización de motores de bases de datos
estándar
Negativo
 No adaptable para organizaciones con
necesidades particulares (aunque tiene varias
funciones parametrizables).
 Difícil articulación e integración con otros
sistemas existentes en la organización.
(middleware)
 No se dispone de las fuentes
 Precio final = Costo final? (costos ocultos de
implementación)
 Probable rigidez ante futuras necesidades de
información

Algunas consideraciones sobre la incorporación de sistemas del mercado (paquetes de software)

Si bien estos sistemas ofrecen una funcionalidad estándar flexibilizada en forma paramétrica, es habitual
que no cumplan con todos los requerimientos funcionales y de integración con el resto de los sistemas de
la organización.
Si fuera necesario cumplir con requerimientos no cubiertos por el paquete ya parametrizado, nos
encontraríamos ante la necesidad de modificar el producto, construir agregados por fuera del producto,
construir agregados por fuera del producto o complementar el producto con tareas manuales.
Por lo tanto los requerimientos no cubiertos por el paquete pueden dar lugar a:

 Incorporar el paquete, sin esos requerimientos

 Realizar adecuaciones y desarrollos complementarios para cumplir con esosrequerimientos.
 Alguna situación intermedia.
La detección y explicitación de la brecha entre requerimientos y disponibilidades debe realizarse en forma
temprana, antes de la adquisición misma del paquete, ya que la cobertura de ellapuede generar costos
tales que, de haberlos conocido anteriormente, podrían haber cambiado la decisión tomada, tanto hacia la
compra de otro paquete como un desarrollo a medida.
Tanto las adecuaciones como la implementación del paquete en sí mismo, requieren un enfoque de ciclo de
vida y metodológico.
 7

Enfoques para el desarrollo de Sistemas

Los enfoques de los ciclos de vida de los proyectos pueden variar continuamente desde enfoques
predictivos u orientados a plan hasta enfoques adaptativos u orientados al cambio.

La diferencia entre enfoques radica en la distribución y superposición de sus fases

Enfoques o Modelos de Desarrollo:
 Predictivos u Orientados al Plan (waterfall)
 Iterativos e Incrementales (Spiral)
 Adaptativos (Ágiles)
 Por etapas (Stagewise): Este modelo considera que las actividades se secuencian una tras la otra, es
decir no comienza la siguiente si no finalizó la anterior. La característica distintiva de este modelo
es la secuencialidad. Requiere la documentación previa y completa de los requerimientos y el
usuario deja de tener contacto con el desarrollo en la etapa inicial y sólo lo recupera en la
implementación. La mayor debilidad de este enfoque reside en que como sólo se puede “ver” el
sistema cuando se completa el desarrollo, bien sea durante la capacitación como durante la puesta
en marcha, recién en esas etapas avanzadas resulta posible detectar la necesidad de realizar una
considerable cantidad de modificaciones y ampliaciones sobre lo ya construido para que el sistema
cumpla sus fines. A mayor duración del desarrollo, resulta mayor el riesgo de necesidad de realizar
el “mantenimiento previo a la operación”. La detección tardía de necesidades de modificación
provoca un significativo aumento de costos y una demora en la implementación.

Predictivos u Orientados al Plan (waterfall)

1. El alcance del proyecto, el tiempo y costo requeridos para lograr dicho alcance, se determinan lo antes
posible en el ciclo de vida del proyecto
2. Se atraviesan distintas fases secuenciales o superpuestas.
3. No puede comenzarse una fase si no ha terminado la anterior
4. Suele denominarse waterfall (cascada) porque, como en las cascadas, una vez que se mueve a la
siguiente fase, es difícil volver atrás. Por esto se lo llama Rígido.

1. La metodología de cascada presenta varios inconvenientes significativos:

 Riesgo de Cronograma
 Flexibilidad limitada
 Participación de usurarios reducida
 8

2. Se recomienda este modelo cuando:

 el producto a entregar se comprende bien,
 existe una base práctica significativa en la industria,
 el producto debe ser entregado en su totalidad para que tenga valor para los grupos de
interesados.

Iterativos e Incrementales (Spiral)

No se pueden definir con claridad y precisión los requerimientos (alta incertidumbre) al inicio. Este método
es mejor para lidiar con la incertidumbre.

1. En las sucesivas fases se repiten de manera intencionada una o más actividades a medida que aumenta
el entendimiento del producto por parte del equipo.
2. Las iteraciones desarrollan el producto a través de una serie de ciclos repetidos, mientras que los
incrementos van añadiendo sucesivamente funcionalidad al producto.
3. Desarrollan el producto de forma iterativa y con incrementos graduales.
4. Cada iteración genera un feedback sobre el desarrollo del producto que permite ajustar los
requerimientos e incrementar la participación y el compromiso de los usuarios.

Se recomienda este modelo cuando:

1. una organización necesita gestionar objetivos y alcances cambiantes,
2. para reducir la complejidad de un proyecto,
3. cuando la entrega parcial de un producto beneficia y genera valor para uno o más grupos de
interesados sin afectar el entregable o conjunto de entregables finales.

Adaptativos (Ágiles)
Establece 12 principios. Las metodologías ágiles proponen la realización de desarrollos cortos con alta
participación del usuario, sin previa planificación de actividades más allá de una definición de alcances
referencial y del tiempo, y son tendientes a una implementación inmediata. Se utilizan para poner
soluciones en funcionamiento lo más rápido posible, PT se obtiene rápido y se mejora en el timpo.

1. Los enfoques o modelos adaptativos pretenden responder a niveles altos de cambio y a la participación
continua de los interesados.
2. Los métodos adaptativos también son iterativos e incrementales, pero difieren de los anteriores en que
las iteraciones son muy rápidas (normalmente con una duración de 2 a 4 semanas) y de duración y
costo fijos.
 9

3. Los proyectos adaptativos generalmente ejecutan varios procesos en cada iteración, aunque las
iteraciones iniciales pueden concentrarse más en las actividades de planificación.

Se recomienda este modelo cuando:

1. Los entornos cambian rápidamente
2. Los requisitos y el alcance son difíciles de definir con antelación
3. Es posible definir pequeñas mejoras graduales que aportarán valor a los interesados.

Abordaje Ventajas Desventajas

Predictivos • Alta efectividad cuando los requisitos
del producto se conocen desde el
comienzo
• Funcional en proyectos de gran
envergadura.
• Permite realizar el valor del producto
cuando el producto debe ser
entregado en su totalidad.
Iterativos e • Alta flexibilidad ante requerimientos
Incrementales cambiantes
• Facilidad para introducir mejoras.
• Fácil ensamble en proyectos de alta
complejidad o de gran envergadura
• Inflexibilidad antes los cambios de alcance
• Creciente riesgo de cronograma cuando
los requerimientos son difusos.
• Baja participación y compromiso de los
interesados
• Inconvenientes para desarrollar productos
que sólo se pueden aprovechar si se
entregan de una sola vez
• Dificultades para entregar productos en el
corto plazo

Adaptativos • Alta flexibilidad ante requerimientos • Dificultades para ensamblar proyectos

cambiantes.
• Alta participación de interesados.
• Facilidad para introducir mejoras.
• Entregas rápidas de entregables
terminados y utilizables.
grandes o de gran complejidad
• Inconvenientes para desarrollar productos
que sólo se pueden aprovechar si se
entregan de una sola vez.

Factores Clave del Éxito

 Apoyo y compromiso gerencial

 Comunicaciones claras e involucramiento del usuario
 Tener en cuenta el nivel de complejidad y la gestión de riesgos
 Calidad de la administración de la Implementación
 10

El manifiesto ágil:

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Esto es, aunque valoramos los

Individuos e Proces os y
interacciones herramientas elementos de la derecha

Software Documentación
extensiva
Sobre
funcionando

Colaboración Negociación
con el cliente contractual

valoramos más los de Respuesta

Seguir un plan
ante el cambio
la izquierda.

Ágil es un conjunto de valores, principios y prácticas que son base para la toma de decisiones en un
proyecto
Cambio de paradigma:

Tendencias actuales:
Las condiciones del entorno actual (globalización, negocios en línea, mercado cambiante) demandan:

 Componentes de software fáciles de agregar, modificar, reemplazar o reconfigurar (sistemas

flexibles).
 Sistemas escalables.
 Conectividad con múltiples plataformas.
 Sistemas posibles de instalar/correr en ambientes diversos.
Esta tendencia lleva a las organizaciones a adoptar procesos de desarrollo más cortos para aplicaciones a
compartir con proveedores, clientes y/ó socios de negocios que proporcionen soluciones rápidas y no
desestabilicen sus sistemas de procesamiento de transacciones y bases de datos organizacionales
esenciales.
 11

SCRUM

1º: Caso de negocios, 2º Visión del proyecto, 3º Lista de requerimientos (cada requerimiento es un
producto independiente y se ordena dependiendo del valor que le agrega al negocio), 4º Sprint (ejecución
de 2 semanas a 2 meses)

 Una de las metodologías ágiles más populares

 Adaptativa, iterativa, rápida, flexible y eficaz
 Equipos multi-funcionales, auto-organizados y empoderados.
 El trabajo se divide en ciclos de trabajo cortos y concentrados
 Compatible con los productos y el desarrollo de servicio en todo tipo de industrias y en cualquier
tipo de proyecto
RUP
 Metodología que divide el proceso en 4 fases: Concepción, Elaboración, Construcción y Transición.
Utilizable para cualquier tipo de proyecto. Cada fase tiene sus actividades asociadas
 Metodología iterativa con desarrollo incremental
 La documentación se basa en ciertos diagramas y para esto, utiliza el UML. (Ejemplos de diagramas
son: Para el análisis: Casos de Uso, Diagramas de estados – Para el diseño: Diagramas de clase,
Diagramas de componentes, Diagrama de comunicaciones, etc.)
Desarrollo Rápido de Aplicaciones (XP)
 Proceso de Creación de Sistemas funcionales en tiempo muy corto.
 Proceso no secuencial. Partes clave del desarrollo se realizan en paralelo.
 Utilizadas para el enfoque de prototipos y con herramientas de cuarta generación.
 Colaboración estrecha entre usuarios y especialistas de sistemas.
 No se genera casi documentación.
 Técnica utilizable: diseño conjunto de aplicaciones (JAD).
 12

Planeamiento Estratégico de Sistemas de Información

El área de sistemas tiene por objetivo asegurarse de que la gerencia tenga la información necesaria para la
toma de decisiones (mejor información, menor incertidumbre, sistemas operativos más eficientes).
Planifica y ejecuta.

Los SI desde una perspectiva Estratégica

1. Los sistemas de información (SI) y su tecnología relacionada (TI) son activos que reditúan valor a las
Organizaciones (así como edificios, maquinarias, etc.).
2. La decisión de construir o mantener un sistema de información se fundamenta en la certeza de que los
rendimientos y/ o el valor de ésta inversión serán superiores a los obtenidos para cualquier otro
activo.

3. Las organizaciones invierten en sistemas y tecnología de la información porque reditúan un valor

económico real para su negocio.
Variables de Negocio

Mejores decisiones administrativas

Valor
Es determinado Procesos de negocios más eficientes
de SI
por
su contribución Rentabilidad más alta
sobre

Relación entre Estrategia de SI y Estrategia de Negocios

Lo que una empresa pueda conseguir (metas corporativas) dependerá también de lo que sus sistemas sean
capaces de hacer (capacidad para utilizar sistemas información y tecnología relacionada):
 13

Decisiones críticas de T.I. - Participación de la dirección

¿Cuánto invertir en T.I.? Para mantener el área de sistemas y sistemas actuales e Invertir en nuevas
tecnologías
¿En qué proceso de negocios debemos invertir presupuestos de T.I.? Depende del plan estratégico de la
empresa
¿Qué capacidades de T.I. deben implementarse en la Empresa?
¿Qué tan buenos necesitan ser en realidad nuestros servicios de T.I.?.

¿Qué riesgos de Seguridad y privacidad aceptamos?.

¿Quién es el responsable si una iniciativa de T.I fracasa?

Planificación estratégica de los SI IV

 14

Puesta en marcha de Planes de SI - Proyectos de Sistemas

Las organizaciones plasman en su plan de sistemas el conjunto de proyectos de sistemas de información

que intentarán reportar el mayor valor de negocios posible.

Para que esto suceda existen ciertas herramientas que brindan apoyo en la determinación de viabilidad
estratégica, operativa, técnica y económica de proyectos de sistemas:

Evaluación y selección de software

 Identificación de necesidades. Análisis de requerimientos.
 Identificación de proveedores. Contacto y búsqueda de propuestas.
 Preselección.
 Evaluación definitiva con enfoque costo/beneficio.
 Negociación y adquisición.
Cartera de Proyectos
El enfoque de la cartera de proyectos permite evaluar la totalidad de proyectos disponibles a una
organización en función de la maximización del valor total de la cartera, entendiéndose por ello, la
búsqueda de aquella mezcla de proyectos que mayor valor aporten a la compañía, en función del Plan
Estratégico de Negocios

(pintar como ppt)

Factores a tener en cuenta en los planes de sistemas:

 El medio ambiente en el cual la institución opera.
 La estructura organizativa.
 La cultura y la política.
 Tipo de institución.
 Apoyo y compresión de la alta gerencia.
 Grupos de interés afectados por el sistema. Posibles ganadores y perdedores. Nivel de poder de los
mismo.
 Tipo de tareas y decisiones que deben ser soportados por el sistema.
 Sentimiento y aptitudes de las trabajadores que lo usarían.
 15

 Historia de la institución. Proyectos anteriores de inversiones en sistemas, habilidades existentes ,

recursos humanos . " Dime cual es tu historia y te diré cual es tu histeria "
 16

Capítulo 13: ESTRATEGIA DE SISTEMAS Y TECNOLOGÍAS DE LA INFORMACIÓN

El valor de la tecnología informática para la organización
Para establecer una estrategia de TICS que agregue valor al negocio debemos tener en cuenta como la
tecnología puede agregar valor al negocio. En tal sentido, podemos conceptualizar que la tecnología puede
agregar valor por alguna o ambas de dos vertientes, ellas son: REDUCCION DE COSTOS Y DIFERENCIACION.
La clave del éxito de la estrategia de TICS es determinar en qué aspectos buscar reducir el costo y en cuales
buscar una ventaja competitiva.
Como regla general podemos considerar que los “impulsores de la decisión” de las inversiones de TICS
deberían tener en cuenta en forma significativa el nivel de comoditización del componente de que se trate:
A mayor comoditización del producto/servicio a incorporar, menor el costo.
A menor comoditización del producto/servicio a incorporar, mayor la diferenciación.

CONCEPTUALIZACIÓN DE ESTRATEGIA
Estrategia como intención o “plan” (“ESTRATEGIA PLANEADA “a priori, planeada en un “plan”)
Propone el establecimiento de acciones explicitadas de manera deliberada en función de hipótesis
previamente establecidas. Originó el llamado “planeamiento estratégico”. Lideró la concepción de las
estrategias de negocios, producto final el “plan estratégico”, consistente en un extenso documento en el que
se detallan las tácticas, los programas, presupuestos y objetivos.
Estrategia como resultante o acción (“ESTRATEGIA EJECUTADA” a posteriori, emergente de la realidad) Desde
otro punto de vista la estrategia es la serie de decisiones entre alternativas de comportamiento, consientes
o no, que determinan el comportamiento (individual u organizacional) en un período de tiempo.
Estrategia como proceso continuo. Orientación, plan, acción, y adaptación
La “visión estratégica” nos revela por qué cada estrategia es diferente. Es una mirada que modela la
estrategia en su conjunto, un constructo abstracto formado en función de una multiplicidad de aspectos
subjetivos, distinguiéndose entre ellos los valores, la formación y trayectoria de todos y cada uno de los
diferentes integrantes de la organización. La visión estratégica es un acto de creación colectiva realizado en
cada organización, irrepetible en otra organización. Encontramos varios modelos de uso generalizado que
ayudan a realizar el análisis estratégico y su puesta en práctica como ser: Modelo de las cinco fuerzas,
Modelo de la cadena de valor, Modelo de las competencias centrales, Visión basada en los recursos internos.

ESTRATEGIA Y SUB ESTRATEGIAS. LA ESTRATEGIA GENERAL Y LA ESTRATEGIA DE SI/TICs

Desde el punto de vista sistémico podemos subdividir la estrategia en subestrategias de menos nivel.
 Estrategia de nivel superior o corporativo, atiende a la definición de los lineamientos que tienen impacto
en toda la organización.
 Estrategia de negocios, vinculada a una actividad en particular.
 Estrategias funcionales, dedicadas a la asignación de recursos. Dentro de estas últimas encontramos la
estrategia de sistemas de información.
La estrategia general sirve como referencia a las distintas estrategias funcionales, las que deben
necesariamente encontrarse enmarcadas en ella.
El Alineamiento es la vinculación que debe existir entre las estrategias de negocio y de tecnologías de la
información. Este modelo expone claramente cómo impacta la utilización de la tecnología en los negocios,
demostrando la interdependencia existente entre la estrategia del negocio y la estrategia de la organización,
requiriéndose una comprensión conjunta del negocio, mediante la construcción de los artefactos
organizativos plasmados en términos, estructuras y procesos, y la implementación tecnológica, ejecutada en
términos de arquitectura, infraestructura y decisiones de aprovisionamiento.
 17

Dominios: Se refieren al planeamiento, constituyen la dimensión de

 Estrategia de negocios integración estratégica cuyo objetivo es la efectividad
 Estrategia de TI
 Organización, estructuras y procesos Se refieren al ámbito de acción, cómo se organizan los recursos
 TI para ejecutar la estrategia, el objetivo es la eficiencia

Alineamiento directo, horizontal y vertical:

 Entre la estrategia de negocios y la estrategia de TICs
 Entre estructuras y procesos en el negocio y entre estructuras y procesos en TICs
 Entre estructuras y procesos del negocio y de TICs

Alineamiento cruzado entre los dominios:

El alineamiento es un requisito central para que todo intento de transformación organizacional resulte
efectivo y eficaz, más aún, la necesidad de alineamiento es creciente con el avance tecnológico, habiendo el
mismo generado una mayor utilización de la tecnología en los procesos de negocios. Con relación al grado
de integración de la tecnología con los procesos de negocios, podemos marcar 3 niveles:
 Conexión, se utiliza a las TICs como soporte para las actividades diarias y la toma de decisiones como una
herramienta distinguible de la actividad humana.
 Inmersión, “SI” esta inmerso como parte del negocio.
 Fusión, la tecnología está fundida en el negocio mismo de manera tal que no se puede distinguir un límite
entre el negocio y el uso de la tecnología. La fusión no implica alineamiento.
La fusión no implica el alineamiento: El impacto negativo en los resultados, producto de la falta de
alineamiento, crece con el avance en la utilización de la tecnología.
Estrategia de Sistemas y Tecnologías de la Información
La estrategia debe identificar el lugar al que queremos llegar, tener claridad sobre el punto de partida y así
establecer la (supuesta) mejor manera de recorrer ese camino, considerando los recursos disponibles al
inicio y los que pueden obtenerse en el mismo camino. Una complejidad adicional es que el destino objetivo
se va a modelar durante el viaje mismo.
Por lo tanto una estrategia efectiva de SI/TICs incluye:
 Visión estratégica, visión del estado al cual queremos llegar.
 Plan estratégico, planeamiento de las actividades para llegar a ese estado.
 Implementación de la estrategia, la ejecución de las acciones.
 Estrategia emergente, análisis de lo efectivamente realizado.
 Estrategia adaptada, mecanismos de adaptabilidad que permitan los ajustes correspondientes en la
visión, el planeamiento y la ejecución de la estrategia.

EL PROCESO ESTRATEGICO DE SISTEMAS Y TECNOLOGIAS DE LA INFORMACION

El proceso estratégico es continuo. Etapas:
 Formulación de la visión estratégica
 Elaboración del plan táctico
 Implementación de la estrategia: Pueden surgir adaptaciones que provoquen cambios en el plan y,
eventualmente, en la visión. El proceso estratégico debe considerar revisiones explícitas de la estrategia
a efectos de generar las intervenciones necesarias para revisar la implementación de la estrategia, el
plan táctico e, inclusive, la visión estratégica. Esas revisiones pueden originarse por: Eventos de revisión,
calendarizados en forma preestablecida o por nuevos hechos que pueden provocar significativos
cambios, tanto contextuales como internos.
 18

FORMULACION DE LA VISION ESTRATEGICA

Esta es la etapa creativa, donde se determinan los grandes lineamientos estratégicos con validez en un plazo
extendido, idealmente superior a los 5 años. El alineamiento entre la estrategia de negocios, la estructura y
las estrategias funcionales, incluyendo la SI/TI se debe gestar en esta etapa.
Deben identificarse las ventajas competitivas que se pueden obtener mediante la utilización de la Tecnología
Informática (visión externa) para, desde ellas, modelar la estrategia general del negocio y la combinación de
recursos y competencias requeridas para su obtención (visión interna), identificando las acciones necesarias
para disponer de esos recursos y competencias.
En esta etapa se requiere una clara percepción del contexto en el cual se desarrollará la estrategia, teniendo
en cuenta los siguientes elementos:
CONTEXTO EXTERNO: Identificación de oportunidades y amenazas. (Ej. Fuentes de financiamiento,
tecnologías disponibles y evolución prevista, oferta de recursos humanos y tercerizaciones, mercado de
demanda, mercado competidor, disposiciones regulatorias y marco sociopolítico general)
CONTEXTO INTERNO: identificación de fortalezas y debilidades. (Ej. Distribución de poder en la organización,
competencias disponibles, cultura organizacional, estructuras y procesos, tecnología en utilización.)
Los lineamientos que debe incluir la visión estratégica corresponden a temas que cumplen las siguientes
características:
 Tienen impacto en el largo plazo
 Provocan costos de cambio
 Dan un marco para orientar las acciones tácticas
En tal sentido se destacan las decisiones sobre el perfil tecnológico, estructura organizativa, arquitectura
tecnológica, el establecimiento de un marco para la priorización de proyectos y el esquema de
abastecimiento.
Perfil Tecnológico
Si la organización va a tener un enfoque de exploración de nuevas tecnologías o de explotación de tecnologías
ya maduras (en la organización o el resto del mercado), es la primera gran pauta de alineamiento para el
resto del plan.
Estructura organizativa
Es el nivel de distribución o concentración de las decisiones de SI/TI a lo largo de la organización, con un
fuerte impacto práctico sobre uniformización o no de arquitecturas e infraestructuras tecnológicas.
 Si como visión se busca uniformar tanto la arquitectura como las aplicaciones, la estructura debe
considerar un área de TICs común a todas las líneas de negocios.
 Si como visión se busca uniformar arquitectura, pero dar cierto nivel de autonomía aplicativa, la
estructura debería contemplar un área de TICs centralizada para establecer la arquitectura, implementar
la infraestructura y dar pautas generales sobre aplicaciones, mientras que áreas de TICs dependientes de
cada línea de negocios dispondrían de autonomía para la implementación de aplicaciones.
 Si como visión se busca dar una autonomía absoluta a una o varias líneas de negocios, la estructura
debería implementar un área independiente de TICs en esa o esas líneas.

Arquitectura tecnológica
Describe conceptualmente la estructura y comportamiento de los diferentes elementos de hardware,
software de base y comunicaciones a utilizar, dando elementos sobre los cuales basarse para luego
incorporar equipamiento y desarrollar aplicaciones. También se puede definir a la arquitectura como la
organización fundamental de un sistema, encarnada en sus componentes, sus relaciones entre sí y el medio
ambiente y los principios que gobiernan su diseño y evolución.
 19

Integrando la arquitectura tecnológica encontramos: Tipo o tipos de equipamiento a utilizar; Sistema/s

operativos a utilizar; Sistema/s de gestión de bases a utilizar, esquema de comunicaciones a utilizar;
arquitectura/s aplicativas a utilizar; estándares a utilizar en cada uno de los elementos anteriores.
Una arquitectura estándar y flexible permite crecimientos y reordenamientos a la vez que también permite
la resignación de los recursos humanos y materiales. Sin embargo, debe analizarse cada negocio en particular
ya que en algunos casos puede no justificarse.
La arquitectura determina: INFRAESTRUCTURA, GRADO DE INTEGRABILIDAD DE LOS COMPONENTES DE HW
Y SW Y POTENCIALIDAD DE APLICACIONES.
Marco para la priorización de proyectos
En la organización, la cantidad de proyectos propuestos por sus integrantes es superior a la cantidad de
proyectos que se pueden realizar, esto tanto por razones económicas como financieras y operativas.
Esquema de abastecimiento
Desde la gestión interna integral del área de sistemas hasta la tercerización completa de la misma.
Outsourcing: La contratación externa de todos o parte de los recursos tecnológicos, actividades humanas y
las tareas de gestión asociadas a la entrega de servicios de TICs a un proveedor externo. Principales factores
para outsourcing: reducción de costos, no atender a competencias centrales, obtener soporte especializado.
Insourcing: El aprovisionamiento interno, la incorporación dentro de la organización de los recursos
tecnológicos, actividades y gestión de esos recursos en forma interna. Principales factores para insourcing:
atender competencias centrales, resguardar confidencialidad, obtener mayor flexibilidad en la asignación de
recursos.
Habitualmente las organizaciones operan con esquemas mixtos, donde se tercerizan algunos recursos y
actividades, y se mantienen otros en forma interna.
Las diferentes actividades sobre las cuales definir el esquema de abastecimiento pueden agruparse de la
siguiente manera: INCORPORACION Y MANTENIMIENTO DE APLICACIONES, CONFORMACION DEL EQUIPO
DE TRABAJO, EQUIPAMIENTO Y COMUNICACIONES.
La visión estratégica y el esquema de gobierno de SI/TI
El establecimiento de un esquema de gobierno explícito de TICs, que responda a la visión estratégica es un
elemento fundamental para garantizar el alineamiento de los planes, decisiones y acciones relacionadas con
SI/TI en la organización toda con esa visión.

ELABORACION DEL PLAN TÁCTICO

El plan táctico debe identificar las acciones necesarias para llevar a cabo la visión estratégica, enmarcadas
en el largo plazo con especial detalle en los próximos años. Deben identificarse las acciones para realizar la
transformación entre la situación actual y la situación objeto. El tiempo de duración de los proyectos no
debería superar un año.
Pueden identificarse los siguientes sub planes:
Plan de recursos humanos
Debe garantizar la disponibilidad de los recursos con las competencias necesarias para llevar adelante el plan
estratégico. El mayor desafío de este plan está dado cuando se resuelve un cambio de arquitectura
tecnológica para balancear la capacitación de los colaboradores actuales con la incorporación o contratación
de expertos en las nuevas tecnologías. El plan de recursos humanos se materializa en las actividades de
capacitación y de incorporación de recursos a realizar.
Plan de proyectos de infraestructura (transformación de recursos físicos
La infraestructura incluye los componentes elegidos para implementar la arquitectura, en el marco del perfil
tecnológico definido y el esquema de abastecimiento dado.
Las principales consideraciones para definir el plan de infraestructura son: ciclo de vida, ajustes,
adaptabilidad, escalabilidad, Mantenimiento, Seguridad.
 20

El plan de proyectos de infraestructura se materializa en la descripción de cada uno de los proyectos a

realizar, con su definición de objetivos, identificación de recursos (humanos, físicos y materiales) y plazos
esperados.
Plan de proyectos de Sistemas de información
El plan de proyectos es el producto de la priorización de los proyectos identificados según el marco
establecido y las disponibilidades dadas por el plan de recursos humanos y de recursos físicos. Incluye la
identificación de cada proyecto, sus objetivos, recursos asignados y puntos de control para considerarlo
exitoso. La priorización de proyectos en función de los objetivos estratégicos es de fundamental importancia,
considerando la inversión en tiempo y recursos, y los costos de oportunidad originados en los proyectos no
priorizados.
La elaboración del plan, que normalmente se realiza en niveles intermedios de la organización, debe tener
presente el marco dado por la visión estratégica. Cuanto más explícito este marco menor subjetividad en el
armado del plan.

LA ESTRATEGIA DE SISTEMAS DE PYMES

Los estudios sobre el nivel actual de la utilización de la tecnología informática en las Pymes indican que su
uso está en general orientado a las tareas básicas de la oficina, por lo cual resulta posible lograr un
crecimiento significativo de la contribución estratégica que la tecnología les puede brindar.
En las Pymes del área de software y servicios informáticos hay un limitante para su crecimiento dado por la
falta de recursos capacitados.

Administración del Área de Tecnología de la Información

Gerencia de Sistemas reportando a la

dirección general para poder tomar
decisiones.
Considera las TI como una inversión, con
un rol estratégico

Área de sistemas de staff, no

estratégica, débil.
Depende generalmente de
Administración y finanzas.
Estadío 1 de la evolución de TICs.
Se lo considera como un centro de
costos, no de inversión
 21

Reporte indirecto, matricial al CIO que

reporta a la Dirección General.

Área de sistemas:

 Diseño y desarrollo: Puede estar tercerizado o parcialmente tercerizado)

o Análisis funcional
o Programación
o Control de calidad
 Tecnología informática (Hardware)
o Infraestructura
o Comunicaciones: Redes informáticas
o Mesa de ayuda
 Operaciones:
o Operaciones CPU
o Implementaciones
La Vida en el Área de Sistemas
 Planificar: Evolución de proyectos. Es inversión y crecimiento.
 Ejecutar: Desarrollo de mejoras. Es inversión.
 Controlar: Solución de incidentes (La mayor parte del tiempo)
 22

Procesos del Área de Sistemas

Procesos del Área de Sistemas

Gestión de la demanda:
 Administración de los nuevos requerimientos
 Administración del portfolio de proyectos
 Definición del Plan Estratégico, Táctico y Operativo
 Identificación de oportunidades de mejoras
 Nuevas tecnologías
 Mejores prácticas
Subsistemas de Gestión de la demanda:

 Administración de Aplicaciones: Programas que se usan (software de aplicación) para:

 Gestionar la vida útil de las aplicaciones
 Parches de seguridad
 Administración de Incidentes: Resolver los problemas de usuarios. Identificar niveles de
prioridad
 Administración y Mantenimiento de Infraestructura:
 Microinformática (uso personal)
 Aplicaciones en servidores
 Soportan los software de sistemas
 Redes
Control de Gestión y de las Contrataciones: Se encargan de administrar las contrataciones con terceros.
Seguimiento de LSA (Level Service Agreement).
 Tercerizados:
 Equipos externos que se tercerizan para determinadas áreas
 Equipos de proyectos externos
 Contratos eventuales y generales
 Hardware
 Software (licencias)
 Otros
 23

 Contrataciones para proyectos

Oficina de Gestión de Proyectos y Programas (PMO)

La oficina de administración de proyectos es el elemento dinamizador de las mejores prácticas en
administración de proyectos y programas. Esta oficina se encarga de:
 Definir las políticas y estándares para la administración de Proyectos.
 Establecer medidas de evaluación para el control de la Gestión.
 Brindar soporte metodológico y logístico a los líderes de proyectos.
 Capacitar al equipo de líderes de proyectos.
 Controlar la totalidad de los proyectos que se ejecutan midiendo su performance y cumplimiento.
 Ser el nexo entre los proyectos y la Alta Gerencia.
 Detectar posibles mejoras e implementarlas.
 Realizar el seguimiento de la satisfacción de los clientes finales de los proyectos.
Seguridad de la Información
 Encargados de la seguridad de la información
 Control de accesos
 Físicos
 Lógicos
 Administración de accesos
 Perfiles
 Usuarios
 Claves

Operación del Centro de Procesamiento de Datos (CPD)

 Encargados de la administración del Centro de Procesamiento de Datos (CPD)
 Administración de los procesos automáticos
 Administración de los procesos batch
 Administración de los transportes entre ambientes
 Administración de los back ups

Gestión de Cambios y la Configuración

Los incidentes son anunciados por los
usuarios clave
El analista aprueba lo que hizo el
programador al entorno de calidad (el
cambio autorizado por los usuarios
clave lo hace “operaciones”, es un
tercero que solo copia, no puede
modificar ni ver los datos)
El usuario clave autoriza a
operaciones para copiar el entorno de
calidad en el entorno productivo.
 24

Entorno de desarrollo: Para hacer pruebas, modificar el código. Se usan datos falsos para proteger los
datos de la empresa.
Entorno de calidad: Copia de la base de datos productiva, es probada por los usuarios clave (no puede ser
usada por los programadores

Entorno de producción
Roles y Responsabilidades
Rol Responsabilidad
Gerente de Sistemas • Responsable del Área
(CIO) • Gestiona los diferentes recursos y proyectos
• Participa en la priorización de los requerimientos/proyectos.
Líder de Proyecto • Realiza la planificación del proyecto
• Participa en la definición de las condiciones de aceptación de los productos
resultantes del proyecto.
• Evalúa productos, servicios y proveedores
• Negocia técnicamente y selecciona el producto / proveedor
• Identifica y gestiona los riesgos del proyecto.
• Organiza, controla y dirige el proyecto
• Controla el desempeño del proveedor
• Informa el estado de avance del proyecto. Detecta desvíos y toma acciones
correctivas y/ó preventivas.
Analista Funcional • Releva las necesidades del usuario y elabora la documentación correspondiente a la
etapa en la que se encuentre el proyecto.
• Participa en la elaboración y ejecución del plan de pruebas.
• Participa de las pruebas de aceptación del usuario
• Verifica y analiza los resultados de la prueba
• Es responsable de la puesta en producción de los productos.
Analista Técnico • Efectúa el Diseño técnico en función del Diseño Funcional recibido.
• Evalúa las opciones técnicas disponibles para los requerimientos relevados.
• Brinda soporte en la codificación del producto.
Analista Programador • Realiza la codificación y testeo unitario del producto de software de acuerdo al
diseño recibido.
Analista Tester • Confecciona el Plan de Prueba
• Coordina las actividades de testing con los distintos participantes.
• Diseña, carga, valida y ejecuta los casos de prueba.
• Registra y realiza el seguimiento de defectos detectados.
• Verifica y analiza los resultados de las pruebas.
• Actúa como soporte en la prueba de aceptación del usuario.
• Emite el Informe final de pruebas y lo distribuye.
Analista Quality • Participa en la elaboración del Plan de Calidad del proyecto.
Assurance • Brinda soporte en la generación de los documentos entregables en cada etapa del
proyecto.
• Realizar las tareas de Control de Calidad en todos los productos determinados en el
Plan de Calidad del proyecto.
• Realiza el seguimiento del Plan de Calidad del Proyecto.
Administrador de la • Distribuye los componentes a testear
Configuración • Distribuye los componentes a producción
Administrador/Analista • Asegura la disponibilidad del ambiente necesario para la prueba.
del ambiente de • Instala los componentes a testear en el ambiente de prueba
prueba • Gestiona la preparación del ambiente.
 25

Administrador/Analista • Es responsable del mantenimiento de la seguridad, creación y eliminación de los

de la Seguridad accesos a los distintos sistemas, módulos, opciones de menú dinámico.
Informática
Administrador/Analista • Monitorea las diferentes bases de datos implementadas.
de Base de Datos • Analiza las adaptaciones o incorporaciones en temas de base de datos.
• Responsable de la implementación de nuevas bases de datos o mejoras a las
existentes

Gestión de Proyectos

El Concepto de “Proyecto”
¿Qué es un proyecto?
Es un esfuerzo temporal que se realizar con el fin de crear un producto o brindar un servicio único, de
modo de logar ciertos objetivos, con restricciones de recursos y plazos.

Una vez que la estrategia se encuentra establecida, resta ponerla en práctica. Esto se logra mediante la
gestión de los colaboradores y los recursos materiales (dinero, recursos tecnológicos) podemos
conceptualizar dos tipos de actividades en la gestión: las operaciones y los proyectos.
 Operaciones: El funcionamiento de la actividad diaria, es decir que los sistemas de información se
encuentren funcionando sin inconvenientes.
 Proyectos: Un objetivo a alcanzar, por ejemplo, implementar un nuevo sistema.
Principales diferencias: Por un lado, las operaciones son actividades repetitivas, se van sucediendo sin límite
de continuidad y tienen recursos humanos y materiales. Por el lado de los proyectos cada proyecto es único
requiere de decisiones específicas, tienen un inicio y fin cuando se llega al objetivo y se asignan recursos
humanos y materiales en forma específica durante la duración del proyecto.
Gestión de operaciones
El objetivo es que los sistemas de información se encuentren funcionando sin inconvenientes incluyendo
procesos de calidad y la implementación de un conjunto de indicadores que permita a la dirección tener
control de las operaciones de las áreas.
Administración de proyectos
Tiene como objetivo la eficiencia en la generación del producto objetivo es decir lograr el producto deseado
a menor costo. Ese conjunto de proyectos se agrupa en un programa de de proyectos con el objetivo de
facilitar la coordinación por ejemplo resolviendo restricciones de recursos y coordinando secuencia de
actividades.
 26

Características de un proyecto:

 Está limitado en el tiempo: Tiene fecha de comienzo y finalización. (esfuerzo temporal)

 Para crear un Producto, servicio o resultado único, nunca antes se hizo.
 Objetivos bien determinados.
 Elaboración progresiva con actividades interrelacionadas (múltiples)
 Genera entregables intermedios y finales definidos
 Existe un auspiciante
 Requiere recursos (que por definición, son limitados)
 Costo y tiempos definidos
 Contiene un plan de actividades

Todo proyecto pasa por las siguientes fases:

Definición de limites y alcances de estudio de factibilid: Tiene por objetivo llegar a un acuerdo en cuanto a
los límites y alcances del sistema y los beneficios esperados de su realización a los efectos de:
 Facilitar la priorización de proyectos
 Proveer la base para la realización del proyecto
Las principales actividades son:
 Identificar las necesidades del usuario
 Determinar el alcance del proyecto, enunciando sus principales funciones y explicitando sus límites
 Identificar alternativas de realización
 Realizar el cálculo de costo-beneficio (tangibles e intangibles) y el plan global de trabajo de alternativas
de solución, tanto del del desarrollo del proyecto como d la operación posterior
Los productos típicos son: Documentos de requerimientos y alternativas de realización; Documentos de
límites y alcances; Documentos de soporte d3e costos y beneficios esperados
Organización y planeamiento: Tiene por objetivo sentar las bases para la realización del proyecto,
incluyendo la estructura organizativa que se dará al ismo, la asignación de recursos humanos y materiales y
el plan de trabajo a nivel general.
Las principales actividades son:
 Desarrollar el plan de trabajo
 Armar el grupo de trabajo
 Establecer los procedimientos de control y comunicación
 Establecer la documentación a utilizar.
Los productos típicos son: Estructura organizativa y afectación de personal y recursos; Plan de Proyecto;
Documentación a utilizar; Procedimientos de comunicación y control; Detalle de principales riesgos.
Análisis y diseño: Tiene por objetivo realizar la descripción completa del sistema para que luego, según la
metodología seleccionada, se puedan ejecutar las tareas de construcción (desarrollo, customización…)
Las principales actividades son:
 Desarrollar el plan de trabajo a nivel de detalle del resto de las tareas de ejecución y control
 Identificar los datos intervinientes, estructurarlos
 Definir en detalle la visión externa del sistema y las reglas de negocios
 Definir la visión interna del sistema
Los productos típicos son: Plan de proyecto ajustado; Informe de control de avance, desvíos y ajustes;
Documento de diseño del sistema; Especificaciones para la construcción del sistema.
 27

Adquisición, construcción y prueba: Tiene por objetivo la elaboración del producto a entregar
Las principales actividades son:
 Ejecutar las acciones necesarias para obtener el producto
 Ejecutar las acciones necesarias para aprobar el producto
 Preparar documentación para el producto y el usuario.
Los productos típicos son: Plan de proyecto ajustado; Informe de control de avance, desvíos y ajustes;
Producto; Documentación sobre el producto y para usuarios.
Puesta en marcha: Incluye las actividades necesarias para la puesta operativa del producto
Las principales actividades son:
 Entrenamiento a usuarios
 Conversión y vuelco de datos
 Instalación de hardware y relacionados.
Los productos típicos son: Plan de proyecto ajustado; Informe de control de avance, desvíos y ajustes;
Producto en producción.
Finalización: Incluye las actividades necesarias para dar por concluido el proyecto, en especial, la revisión
crítica del proceso de este a los efectos de capitalizar la experiencia para los próximos proyectos.
Las principales actividades son:
 Aceptación por el usuario
 Revisión y actualización final de la documentación
 Repaso de problemas, aprendizaje en el grupo y fuera de él sobre los inconvenientes que tuvieron
 Resignación de recursos liberación de espacios
Los productos típicos son: Informe de cierre de proyecto; Identificación de oportunidades de nuevos
proyectos.

Administración de Proyectos Profesional

Es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto,

con el objetivo de:

 Analizar el problema
 Definir una alternativa de solución
 Identificar las actividades del proyecto y planificarlas
 Alinear el trabajo con los objetivos de negocio
 Minimizar los posibles riesgos
 Estimar y generar los recursos
 Capacitar a los miembros del equipo
 Definir claramente los roles y sus responsabilidades
 Involucrar a todos los interesados (audiencia), en forma temprana y logrando su compromiso
 Establecer los procesos de comunicación durante el proyecto
 Controlar el avance del proyecto y tomar acciones correctivas/preventivas.
 28

Variables de un Proyecto / Restricción Múltiple

Variables de ajuste en un proyecto: Si una cambia, se alteran las otras.

 Alcance: Todo lo que está incluido en el proyecto, lista

completa de requerimientos
 Tiempo: Cuanto mayor es el alcance, más tiempo se
necesita
 Recursos: + Recursos, - Tiempo, + Costos
 Costos: - Recursos, + Tiempo
 Calidad: Gran alcance, poco tiempo, pocos costos y
recursos empeoran la calidad
 Riesgos: A menor calidad, mayores riesgos
Fases de un Proyecto
 Inicio: Planificación inicial, alcance inicial y estimación
de tiempos y costos. Los siguientes 3 se repiten hasta llegar al
cierre:
 Planificación detallada
 Ejecución
 Control
 Cierre

La gestión de proyectos incluye la aplicación práctica de habilidades, herramientas y técnicas en la

actividad del proyecto para tender a alcanzar el producto esperado, el costo y el tiempo esperados. Esta
misma gestión está compuesta por dos partes importante que son la visión técnica y las cuestiones
humanas. La técnica incluye artefactos administrativos para gestionar las actividades mientras que la
humana incluye técnicas de negociación, liderazgo y manejo en grupos en trabajo en general.
Técnicas y herramientas de administración de Proyectos
Planificación:
La planificación de proyecto es la fuente básica de información para el control de proyecto.

La planificación del proyecto implica estimar:

 Costos (presupuesto)
 Tareas y tiempos (cronograma)
 Recursos humanos y físicos
¿Por qué es difícil estimar?
 Inexperiencia del estimador, falta de una base de datos de conocimientos.
 Incertidumbre sobre los posibles cambios de alcance, precios, etc.
 Presión política de la organización
 Inestabilidad de los requerimientos
 Nuevas tecnologías
 29

¿Para qué se planifica?

 Para asegurar que todo el trabajo este identificado,

 Para dar a las actividades un orden lógico,
 Para identificar los riesgos potenciales,
 Para obtener el compromiso del equipo
¿Con qué herramientas se cuenta?

 Confección de cronograma para reflejar y monitorear las tareas, tiempos y sus recursos asociados.
 Planilla de presupuesto estimado y real.
 Planilla de riesgos: sus probabilidades de ocurrencia, grado de impacto y acciones de mitigación y
contingencia
 Informe de avance: para mostrar el avance real del proyecto respecto de lo estimado

Diagrama de Gantt

Visto en función del tiempo

Muestra:
 Gráficamente la relación del tiempo entre las tareas en un proyecto.
 Indica la sucesión de tareas,
 Tareas paralelas
Diagrama Pert
Enfocado en la secuencia lógica de las tareas
Tres componentes:

 los eventos
 las actividades (que llevan de un evento al otro)
 las no actividades (dependencias entre dos eventos que no representan ninguna actividad).

Permite identificar el camino crítico (muestra los pasos que deben completarse a tiempo para no retrasar
el proyecto).
 30

Principales herramientas utilizadas en la gestión de proyectos:

Estructura de descomposición del trabajo (EDT) y análisis de procedencias
La descomposición de las tareas necesarias para la concreción del producto objeto del proyecto es a juicio
de los autores, la actividad principal para facilitar la posterior gestión del proyecto. La cantidad de niveles de
descomposición depende tanto de la naturaleza del elemento como de las características de su producción
y la etapa del proyecto. El objetivo esencial del EDT es facilitar la coordinación de actividades y el control
efectivo del avance del proyecto en alcance plazo y costo para poder ejecutar las correcciones necesarias en
tiempo y forma.
Diagrama de barra y de red
Muestra la duración de las tareas sobre un eje del tiempo, y como las actividades del proyecto fluyen de
principio a fin, exponiendo las procedencias y dependencias. Facilita la visión de interrelaciones ya que las
tareas se exponen en forma de red en lugar de en forma de línea, a la vez que dificulta la visión temporal de
las actividades.
Análisis de la duración del proyecto
Hay que determinar cuál es el tiempo mínimo de duración del proyecto y cuáles son las actividades que
determinan esa duración. Los métodos conocidos como método del camino crítico y técnica de revisión y
evaluación de programas tienen como objetivo determinar ese tiempo. Con ellos se explican las actividades
que si se demoran impactan en la duración del proyecto conformando el camino crítico. Mientras el primero
supone que los tiempos de las actividades se conocen en forma determinística, el otro supone que el tiempo
para realizar una actividad es una variable aleatoria que sigue distribución de probabilidades.
Estimación de tiempos y costos.
Los costos del proyecto incluyen los insumos en general para los cuales normalmente se solicita un
presupuesto y la aplicación del tiempo de los colaboradores asignados. Una de las técnicas mas difundidas
es la conocida como el análisis de puntos de función, puede utilizarse para estimar el esfuerzo requerido para
el proyecto en estudio en función de la comparación de los puntos de función de los proyectos utilizados
como base de estimación y el esfuerzo real insumido. Este modelo busca determinar una medida de las
funciones cubiertas independiente de la tecnología que se utilice, la calidad de los recursos, el ambiente, etc.
Los pasos son. Se definen las tareas llevadas a cabo en base a atributos externos. Se toman todas las horas
hombres aplicadas en la totalidad de las tareas y se realiza un ajuste final llegando a la cantidad de horas
hombres por punto de función ajustada.
Aspectos humanos.
Comportamiento de los miembros de la empresa. Problemas principales: Resistencia al cambio, problemas
de comunicación e interpretación, problemas de asignación efectiva de recursos, modificaciones al alcance
no consideradas como cambio y falta de habilidades.
Ejecución del plan y control de avance.
Mediante la descomposición de las tareas cada persona sabe lo que debe hacer y en caso de tener
inconvenientes en realizarlo puede advertir en forma temprana tanto el problema como el impacto del
problema al responsable del proyecto para que se realicen los ajustes que corresponda. Mediante la
comparación entre el plan del proyecto y el registro de actividades se pueden determinar las siguientes
variaciones. Variación costos, plazo y alcance. Estas nos permiten determinar el presupuesto y el camino
critico ajustado y trabajando con los tres ejes determinar las tareas necesarias para recuperar el plazo original
y respetar el presupuesto.
Gestión de problemas y cambios.
Típicamente ante problemas se cuenta con los siguientes recursos en forma individual o combinada.
 Ejecución de tareas adicionales,
 Refuerzo de dotaciones o contrataciones adicionales
 31

 Reducir alcances, esto significa reasignar recursos para resolver el problema. Una situación que el
responsable debe evitar es la inclusión de cambios sin advertirlos como tales.
Estructura y proyecto.
Cada enfoque estructural tiende a diferentes efectos en la eficiencia y efectividad en el logro de los proyectos
encarados, en tal sentido podemos mencionar:
 Grupos de proyectos armados sobre una organización funcional: Pocas personas trabajan tiempo
completo en el proyecto. Generalmente del área de sistemas.
 Grupos de proyecto armados como una organización matricial: Los colaboradores en general mantienen
la dependencia jerárquica manteniendo la dependencia original.
 Grupos de proyectos independientes (se arma un grupo de colaboradores en los que son asignados al
proyecto, dejando de trabajar en sus áreas originales.

Riesgos:
El riesgo es un evento o condición inciertos que, si se produce, tiene un efecto positivo o negativo sobre al
menos un objetivo del proyecto, ya sea, el plazo, el costo, el alcance o la calidad.
Gestión de Riesgos: Incluye a todos los procesos relacionados con la planificación, gestión, respuesta,
seguimiento y control de los riesgos de un proyecto, con el objeto de:
Aumentar la probabilidad e impacto de los POSITIVOS

Reducir la probabilidad e impacto de los NEGATIVOS

Factores de Riesgo
1. Evento de Riesgo: Qué puede suceder en detrimento del proyecto
2. Probabilidad de Riesgo: Cuál es la probabilidad de qué ocurra el evento
3. Cantidad de Riesgo: La severidad de las consecuencias
Registro de Riesgos
Herramienta que permite llevar un registro de los riesgo a lo largo del proyecto:
 Lista de riegos
 Lista de posibles respuestas
 Causa de los riesgos
 Categorías de Riesgos
Análisis Cualitativo y Cuantitativo de Riesgos
Análisis Cualitativo: Se utiliza para calificar los riesgos en función del impacto y probabilidad de ocurrencia.
Permite construir la matriz de probabilidad e impacto
 32

Análisis Cuantitativo:
 Cuantificar los posibles resultados del proyecto y sus probabilidades.
 Evaluar la probabilidad de lograr los objetivos específicos del proyecto
 Identificar los riesgos que requieran una mayor atención en función del impacto cuantificado en el
proyecto:
 Valor monetario esperado = Probabilidad de ocurrencia x Valor del evento
 Árboles de Decisión
 Simulación (Método de Montecarlo)

Estrategias para Responder a Riesgos

Riesgos Negativos:
 Evitar: Eliminar el riesgo eliminando la causa
 Transferir: Trasladar las consecuencias del riesgo a una tercera parte. Se transfiere la
responsabilidad de la gestión, pero no elimina el riesgo
 Mitigar: Reducir la probabilidad o el impacto del evento.
 Aceptar:
 Plan de Contingencia: Plan de mitigación en caso que surjan riesgos no previstos
 Reservas: Fondos o plazos adicionales para usar en caso que se produzca el evento.
Riesgos Positivos:

 Explorar
 Compartir
 Mejorar

Factores de Éxito de un Proyecto

Aspectos generales
 Identificar las necesidades del negocio
 Reconocer los límites que marca la organización
Aspectos de Organización
 Metodología utilizada
 Aprobación formal
 Obtener los recursos
 Armar el plan detallado y comunicarlo
 33

 Establecer y respetar los mecanismos de control

 y reporte
Cuestiones de ejecución

 Atender los desvío

 Identificar y resolver imprevistos

Seguridad y Control de los SI

La creciente distribución de la capacidad de cómputo, en conjunto con la posibilidad de acceso a los
sistemas de información desde las más diversos lugares lleva a las siguientes preguntas claves a la hora de
protegerlos de diversas amenazas:
 ¿Cómo hago para que los datos sean accesibles , pero a la vez estén protegidos (privacidad)?
 ¿Cómo lograr qué accedan las personas que están autorizados y qué puedan hacer solamente las
operaciones para las cuales están debidamente autorizados ?
Dado el alto grado de penetración de la informática en la vida cotidiana doméstica y organizacional,
cualquier tipo de fallo en los sistemas de información pueden producir catástrofes importantes.
Muchos de los fallos ocurren cuando surgen problemas de seguridad, por ejemplo cuando:
 DISPONIBILIDAD: Acceder a la información dónde y cuándo se requiere.
 INTEGRIDAD: La información que manejan los sistemas solo es manipulada por los usuarios y está
completa.
 CONFIDENCIALIDAD: La información sido accedida solo por personas autorizadas.
Concepto de Seguridad Informática:
La Seguridad Informática es el conjunto de medidas preventivas y detectivas destinadas a preservar la
Integridad, Disponibilidad y Confidencialidad de la INFORMACION y RECURSOS INFORMATICOS

 Medidas preventivas: Evitan que algo falle antes de que ocurra

 Medidas detectivas: Son después de que se den las fallas

Control Interno vs. Auditoria de Sistemas

El control interno es el conjunto de tareas y funciones inherentes a la propia actividad de la organización
que tratan de verificar que los procesos se realizan según lo establecido (la realización de los controles son
parte de las tareas del proceso).
La auditoría es el conjunto de acciones puntuales y ajenas a los procesos auditados, cuyo objetivo es
identificar y probar el funcionamiento del esquema de control interno de las Organizaciones, incluyendo la
revisión del cumplimiento de determinadas normativas y objetivos asociados.
Dentro de este espectro, las auditorías de sistemas tienden a verificar el diseño y funcionamiento del
esquema de control interno establecido en los procesos de TI de las Organizaciones.
La Auditoria de Sistemas se ejerce sobre los procesos de tecnología informática (controles generales de TI)
y/ o sobe los sistemas de información (controles aplicativos).
 34

Las tareas de la Auditoria son:

 Entender los procesos de sistemas que se llevan a cabo en la Organización, asociar las amenazas y
vulnerabilidades a las que se encuentran expuestos estos procesos y los sistemas informáticos, e
identificar los controles que actualmente posee y/ o debería poseer la Organización para mitigarlos.
 Analizar exhaustivamente el cumplimiento de todos los controles que rigen sobre los procesos de
sistemas (controles generales de TI) y/ o sobre los sistemas de información (controles aplicativos).
 Enumerar las deficiencias y/ o ausencias de control detectadas.
 Estimar la probabilidad de ocurrencia de las vulnerabilidades no controladas adecuadamente.
 Evaluar el impacto en las finanzas y en la Organización de dichas vulnerabilidades.
 Proponer tareas de control a implementar y/ o mejoras en los controles que se efectúan.
Las técnicas posibles de utilizar en la auditoria son:
 Entrevistas y revisión de documentación.
 Control del flujo completo de transacciones.
 Utilización de herramientas de auditoria automatizadas.

RIESGOS:
Concepto de Amenazas y Vulnerabilidades:
Los riesgos son amenazas que, de materializarse a través de la explotación de vulnerabilidades, pueden
atentar contra la seguridad de los recursos e información de las Organizaciones.

Amenaza: evento o acción que afecte el normal funcionamiento de los sistemas y/ o procesos.
Vulnerabilidades: debilidades inherentes a los sistemas y procesos bajo análisis que facilitarían a un
atacante violar la confidencialidad, integridad y disponibilidad de los sistemas (datos y programas).
La falta de control de las vulnerabilidades acrecienta las posibilidades de que las amenazas se materialicen
Origen de las amenazas:
 Factores técnicos.
 Factores de organización.
 Factores del entorno.
Combinados con malas decisiones gerenciales o la falta de decisión.

Ejemplos de Amenazas y Vulnerabilidades:

Amenazas Vulnerabilidades
“Desastres naturales o _Data Center ubicado en importantes zonas inundables.
siniestros que dañen o _Ausencia de paredes ignífugas en el Data Center.
destruyan el Data Center,_Mecanismos de detección/ extinción de incendios inexistentes o con un
en forma parcial o total”inadecuado funcionamiento.
_El personal que ejecuta las tareas de administración del equipo no esta
debidamente capacitado para ejecutar sus tareas.
“Manipulación inadecuada _Mecanismos de protección de datos críticos inadecuados.
de los datos” _Backups resguardados en lugares con inadecuada protección física.
 35

_Utilización de datos de Producción para la realización de pruebas.

_Cargas y/o actualización masiva de datos ejecutadas en forma errónea o
no autorizada.
_Falta de acuerdos con terceros y personal propio, de no divulgación de
datos restringidos y/o confidenciales.
“Robo y o divulgación de _Existencia de cuentas de usuario con sus contraseñas por defecto.
credenciales” _Existencia de cuentas de usuario anónimas y/o genéricas.
_Contraseñas almacenadas en sitios inseguros.
_Mecanismos de autenticación inexistentes o implementados
inadecuadamente.
_Falta de concientización de usuarios sobre aspectos de seguridad en el
uso/ conservación de sus contraseñas.
_El personal que administra la seguridad no está debidamente capacitado
para desarrollar sus tareas.
_Contraseñas entregadas a personas que no resultan ser responsables de la
cuenta de usuario.
“Nuevos desarrollos y/o _Inoportuna detección de fallas en los desarrollos efectuados.
cambios sobre el sistema _Los desarrollos no se ajustan con lo requerido por el negocio.
inadecuados” _Los desarrollos y/ o las pruebas son efectuadas sobre el entorno de
Producción.
_Implementación de cambios y/o nuevos desarrollos que no fueron
testeados ni aprobados.
_Imposibilidad de volver a la versión anterior de la aplicación tras una
implementación errónea.
“Intrusión de virus y/o _Ausencia de software antivirus.
software malicioso ” _Actualizaciones del software antivirus inadecuadas o inoportunas.
_Redundancia de hardware de contingencia inexistente o implementado
inadecuadamente.
_Errores y/o demoras considerables durante la restauración de los servicios
informáticos

Medición de Amenazas y vulnerabilidades

La evaluación global del riesgo es una función de:
La probabilidad de que la causa ocurra (Altamente probable, Posible, Poco probable).

El impacto resultante del riesgo en reportes financieros, compliance, operaciones, etc.

Matriz de impacto y probabilidad
A los efectos de su medición, los riesgos son valorizados en función de la combinación entre la
probabilidad de que estos ocurran y el impacto resultante de su materialización.
 36

CONTROLES:

Los controles son Acciones/ Medidas (preventivas o detectivas) destinadas a minimizar el impacto que
puede tener un riesgo o reducir la probabilidad de ocurrencia del mismo.

También se los puede definir como un conjunto de métodos, políticas y procedimientos organizacionales
que......
 Resguardan los activos de la organización
 Hacen exactos y fiables a los sistemas de información
 Cumplen con las normas gerenciales

Clasificación de Controles – Naturaleza

MANUAL VS. AUTOMÁTICO

Clasificación de Controles – Oportunidad

PREVENTIVO VS. DETECTIVO
Los controles preventivos evitan que las amenazas entren en las organizaciones, pero es más costoso
Los detectivos son posteriores, una vez que el problema ya está dentro de la organización. Es peor porque
el daño ya está hecho

Controles preventivos Controles detectivos

Eliminan problemas en el origen
Generan calidad en los procesos
Las excepciones pueden predecirse
Las excepciones podrían impactar
significativamente
Detectar errores que son difíciles de predecir
Identificar riesgos que ocurren esporádicamente
Se utilizan como complemento de los controles
preventivos
 37

Clasificación de Controles – Resumen

Entorno de Control de los Sistemas Información

Tipos de controles:

 Controles Generales: Controles amplios que monitorean el funcionamiento eficaz de los

procedimientos programados en todas las Áreas de aplicación.
Los controles generales son aquellos que están incrustados en los procesos y servicios de TI.
Algunos ejemplos son: Desarrollo de sistemas, Administración de cambios, Seguridad, etc.

Controles Generales Descripción

Control de Audita el proceso de desarrollo de sistemas para asegurar que siga las pautas
Implementación de calidad para el desarrollo, conversiones y pruebas.
Control de Software Monitorea el uso del software de sistemas y evita el acceso no autorizado a los
programas de aplicación y al software de sistemas.
Control de Hardware Cuida que el equipo esté protegido físicamente contra incendios y extremos
de temperatura y humedad. Debe garantizar la continuidad operativa ante
desastres, implementando respaldos tanto de hardware como de datos.
Control de Operaciones Ejercido sobre la labor del centro de cómputos. Garantiza que los
de Computación procedimientos programados se apliquen de forma congruente y correcta al
almacenamiento y procesamiento de datos.
Control de Seguridad Garantiza que los archivos de datos de negocios no sufran accesos no
de los datos autorizados, alteraciones o destrucción.
Control Administrativo Normas, reglas, procedimientos y disciplinas de control formalizados. Asegura
que los controles generales y de aplicación de la organización se apliquen y
cumplan debidamente.

 Controles de Aplicación: Controles específicos y exclusivos de cada una de las aplicaciones

computarizadas.
Los controles incluidos en las aplicaciones del proceso de negocios se conocen por lo general como
controles de aplicación. Ejemplos: Integridad (Completitud), Precisión, Validez, Autorización,
Segregación de funciones, etc.

Controles de Aplicación Descripción de los mismos

Control de Entrada Verifica la exactitud e integridad de los datos cuando entran en el sistema. Son
controles para evitar errores en las entradas, conversiones y/ó ediciones de
datos. Es posible establecer totales de control.
Control de Determina si los datos están completos y son exactos durante la actualización.
Procesamiento Se pueden establecer totales de control de serie, el cotejo por computadora y
verificaciones de edición.
 38

Control de Salida Monitorea que los resultados del procesamiento sean correctos, estén
completos y se distribuyan debidamente

¿Qué medidas se pueden implementar para las amenazas existentes? (Algunos ejemplos)

 Virus: Antivirus, restringir/ proteger los medios de almacenamiento de datos portables (memorias usb,
cintas de backups, dvd’s, diquetes, etc.)
 Personas intrusas: Firewalls, Sistemas de detección de intrusiones.
 Desastres: Resguardos completos y/ó incrementales, Espejado de discos, Planes de Recuperación en
caso de desastres.
 Fallos de Software: Controles de entrada, Implementar metodología estandarizada para el
desarrollo/mantenimiento de sistemas y efectuar auditorías sobre el uso de la misma, Controles de
salida.
 Problemas de telecomunicación: Cifrado, Firma Digital, Certificado Digital, Integridad del mensaje.
 Seguridad en Transacc. Electrónicas: Transmisión Electrónica Inviolable (SET- Tarj. Crédito), E-cash

Criterios para el desarrollo de una Estructura de Control

Importancia de los datos: ¿qué datos queremos proteger? Cuanto mayor sea el valor de los datos para la
organización, mayores serán los controles necesarios.
Eficiencia de los controles utilizados: Crear controles específicos en sectores críticos de la organización.

Evaluación del nivel de riesgo: ¿qué sucede si no construyo la estructura de control? ¿qué riesgos asumo?
¿cuál seria el impacto para la organización?

REVISIÓN DE PROCESOS
1. Cuando se realiza la Revisión de un Proceso es importante entender el propósito o el objetivo de ese
proceso y como está conectado o alineado con la estrategia del negocio
2. Para obtener el entendimiento completo del proceso, identificamos y evaluamos los riesgos inherentes
al proceso que pueden dar lugar a que el objetivo del proceso no sea alcanzado
3. Luego, identificamos y evaluamos los controles que mitigan los riesgos clave identificados en el
procesos
4. Finalmente, testeamos los controles para determinar si los controles están operando como fueron
diseñados o tienen la intención de hacerlo durante el periodo de prueba
 39

Procesos de TI - Algunos ejemplos

Aspectos éticos y legales de las tecnologías de la información

¿Qué es la Ética?
Moral: es el conjunto de normas sociales que regulan el comportamiento de los individuos que la integran.

Ética: es la rama de la filosofía que tiene como objeto de estudio a la moral.

Utiliza el método de la filosofía para evaluar la correctitud de las acciones.
Ramas:

 Ética normativa
 Metaética
 Ética aplicada
Teoría ética: es una teoría respecto a la moral.
Clasificación:
 Consecuencialistas
 Utilitarismo
 Deontológicas
 Teoría de Kant
Utilitarismo
Principio utilitario (Bentham): Una acción es correcta en la medida que sus consecuencias producen la
mayor cantidad de felicidad agregada neta en los individuos involucrados.

Características del cálculo:

Felicidad = placer
Felicidad neta = felicidad – infelicidad
Felicidad agregada = Σ felicidad individual
Ética kantiana

Su teoría relaciona razón, libertad y moral.

Ley moral: conjunto de principios o reglas llamados imperativos.
 40

Imperativo categórico:

“Obra sólo según una máxima tal que puedas querer al mismo tiempo que se torne ley universal”.
“Obra de tal modo que uses la humanidad, tanto en tu persona como en la de cualquier otro, siempre
como un fin, nunca sólo como un medio”.
Ética de la computación
Es la disciplina que reflexiona sobre los “problemas éticos agravados, transformados o creados por la
tecnología de la computación” (Maner, 1980).
Es “el análisis de la naturaleza e impacto social de la tecnología de la computación y de la correspondiente
formulación y justificación de políticas para un uso ético de dicha tecnología” (Moor, 1985).
Disciplina que estudia la forma en la que las computadoras presentan “nuevas versiones de problemas y
dilemas morales usuales, exacerbando viejos problemas y forzando la aplicación de las normas morales
ordinarias en dominios no registrados (Johnson, 1985).
Temas de la Ética de la Computación

 Privacidad
 Identidad digital
 Propiedad intelectual
 Alfabetización informacional
 Jurisdicción legal en Internet
 Responsabilidad por la calidad de los SI
 Impacto físico, psíquico y social de las TICs
Introducción a la Propiedad Intelectual

Propiedad Intelectual: propiedad sobre objetos inmateriales

Clasificación de acuerdo al tipo de objeto:

 Derechos de Autor
 Propiedad Industrial
Jerarquía constitucional: Art. 17 de la Constitución Nacional: “Todo autor o inventor es propietario
exclusivo de su obra, invento o descubrimiento, por el término que le acuerde la ley”.
Derechos de Autor

Autoridad de aplicación: Dirección Nacional de Derechos de Autor

Objeto de regulación: obras científicas, literarias, artísticas o didácticas.
Derechos comprendidos:

 Derechos morales
 Derechos patrimoniales
Derechos conexos
Titulares del derecho:

 Autor: durante su vida.

 41

 Herederos o derechohabientes: 70 años a partir del 01/01 del año siguiente al fallecimiento del
autor.
 Modificaciones sobre obras preexistentes, con autorización del autor original.
 Empleadores por los programas de computación elaborados por sus empleados, salvo estipulación
en contrario.
Propiedad Industrial
Patentes de invención: Ley N° 24.481 “Ley de patentes de invención y modelos de utilidad”.

 Invención
 Patente
 Duración: 20 años improrrogables desde la fecha de solicitud.
Marcas y designaciones: Ley N° 22.362 “Ley de marcas y designaciones”. Plazo: 10 años, renovables
indefinidamente
Autoridad de Aplicación: Instituto Nacional de la Propiedad Industrial (INPI)
42
43
44