Tabla de contenido

Ingeniería de Software ............................................................................................. 4

Tipos básicos de software: ................................................................................................... 4

Naturaleza del Software y sus Cualidades:........................................................................... 4
Clasificación de las Cualidades: ............................................................................................ 4
Cualidades Representativas: ................................................................................................ 5
Software como producto:..................................................................................................... 6
Sistema: ................................................................................................................................ 6
Modelo de procesos: ............................................................................................................ 7
Proceso de software: ............................................................................................................ 7
Las herramientas CASE ......................................................................................................... 7
Crisis del software: ............................................................................................................... 8
Paradigmas de desarrollo de software: ................................................................................9

Ciclos de vida secuenciales:..................................................................................................9

El modelo en cascada ........................................................................................................... 9
Desarrollo Evolutivo: .......................................................................................................... 10
Ingeniería de Software Basada en Componentes: ............................................................. 11
Modelo Incremental: .......................................................................................................... 13
Modelos que derivan de los anteriores:.............................................................................. 14
Modelo de Prototipado de Requerimientos ...................................................................... 14
Modelo Entrega por Etapas: ............................................................................................... 14
La Naturaleza Iterativa de los Desarrollos: .......................................................................... 14
Modelo Iterativo:................................................................................................................ 14
Modelo de Espiral: .............................................................................................................. 15
Modelo Iterativo e Incremental: ........................................................................................ 16
Ingeniería de Requerimientos ............................................................................................ 20
Requerimiento: ................................................................................................................... 20
Categorías de requerimientos ............................................................................................ 20
Tipos de requerimientos .................................................................................................... 21
Workflows de Análisis, Diseño e Implementación ............................................................... 22
Objetivos de un sistema de Workflow: .............................................................................. 22
Proceso Unificado Racional RUP......................................................................................... 23

Modelos de Calidad de Software ........................................................................................ 24

ISO 9001:2000: ................................................................................................................... 25
Conceptos fundamentales que plantea CMM:................................................................... 25
CMM como modelo: ........................................................................................................... 26
Certificación:....................................................................................................................... 27
Métricas: ........................................................................................................................... 27

1
Auditoría de Sistemas ............................................................................................. 28

Auditoría y Consultoría ...................................................................................................... 28

Tipos de Auditoría: ............................................................................................................ 29

Proceso de Auditoría ......................................................................................................... 29

Auditoría Informática: ........................................................................................................ 29
Estándares Generales: ........................................................................................................ 30
Etapas del Proceso de Auditoría:........................................................................................ 30
Métodos para Mitigar el Riesgo: ........................................................................................ 30
Metodología de Control Interno ......................................................................................... 31
Pirámide: ............................................................................................................................ 31
Tipos de Metodologías: ...................................................................................................... 31
Marco Jurídico de la Auditoría Informática: ........................................................................ 33
Derecho: ............................................................................................................................. 33
Delito informático: ............................................................................................................. 33
Principales Áreas de la Auditoría Informática: .................................................................... 33
Auditoría Física: .................................................................................................................. 33
Auditoría de la Ofimática:................................................................................................... 34
Áreas de Aplicación de la Auditoría Informática: ................................................................ 34
Auditoría de Bases de Datos:.............................................................................................. 34
Auditoría de las Aplicaciones:............................................................................................. 35
Auditoría de la Seguridad: .................................................................................................. 35
Auditoría de Redes: ............................................................................................................ 35
Modelo OSI: ........................................................................................................................ 35
Administración de Proyectos .................................................................................. 36

Proyecto: ............................................................................................................................ 36
Proyect Management: ....................................................................................................... 36
Errores Clásicos:.................................................................................................................. 36
Organizaciones: .................................................................................................................. 37
Variables más importantes del proyecto: .......................................................................... 37
Gestión del Alcance del Proyecto: ...................................................................................... 37
Alcance: .............................................................................................................................. 38
La Estructura de Descomposición del Trabajo: .................................................................. 38
Gestión del Costo del Proyecto: ......................................................................................... 38

Mediciones de Valor Ganado: ............................................................................................ 39

Índices: ............................................................................................................................. 40

Proyecciones: .................................................................................................................... 40

2
 Métodos de estimación de proyectos: ............................................................................... 41
Gestión de Recursos Humanos del Proyecto: ...................................................................... 42
Funciones Principales del Director del Proyecto: ............................................................... 42
El liderazgo involucra:......................................................................................................... 43
Pirámide de Maslow: .......................................................................................................... 43
Teoría de la Motivación e Higiene de Herzberg: ................................................................ 44
Gestión de las Comunicaciones del Proyecto: ..................................................................... 44

Gestión de Riesgos del Proyecto:........................................................................................ 44

Gestión de Abastecimiento del Proyecto: ........................................................................... 45

Contrato:............................................................................................................................. 45

3
 Ingeniería de Software
Comprende todos los aspectos de la producción de software, es decir, desde las etapas
iniciales de la especificación del sistema, lo que debe hacer, hasta su entrega y
mantenimiento. Varias personas en la construcción de multiversión de software.

Tipos básicos de software:

 System Software (Sistemas Operativos)

 Utilitarios
 Software de Aplicación

Cualquiera sea el tipo de software, requiere de información que lo acompañe para su

correcto entendimiento y uso para luego mantenerlo, caso contrario lo llevará a tener
errores que no podrán ser salvados en el tiempo.

El software tiene características que es importante conocer, veamos algunas de ellas.

Naturaleza del Software y sus Cualidades:

 El software es fácilmente modificable, lo que implica que el código responde a

una lógica y normalmente es de quien lo construye, por lo que si cambia el
actor es muy posible que cambie el código.
 No es tangible, como otros productos. Al ser intangible no es fácil imaginarse el
tamaño o la forma del software, muchas veces se cree que realizar una
aplicación o una nueva funcionalidad es algo simple, pero la mayoría de las
veces implica un gran trabajo difícil de visualizar.

Clasificación de las Cualidades:

 Externas versus internas, se pueden considerar como externas la usabilidad

del software por los usuarios, mientras que la interna es técnica, la ven
quienes codifican. Es posible que un software esté muy bien diseñado y

4
 codificado pero al usuario le resulte difícil de entender y usar, o totalmente al
revés, el usuario solicita algo que mientras lo entienda y sea fácil de usar no
importa si técnicamente está bien realizado. Lo óptimo es que cumpla con
ambas condiciones.
 Cualidades de producto y proceso. El proceso de desarrollo de software dará
un producto final que se espera que sea de calidad y satisfaga las necesidades
del cliente, para ello el proyecto deberá ser exitoso y el proceso de software
también.

Cualidades Representativas:

 Correctitud, Confiabilidad y Robustez

o Correctitud: un programa es “funcionalmente correcto” si se comporta
acorde a la especificación de la función que debería proveer.
o Confiabilidad: un programa es confiable si el usuario puede depender
de él. El software no debe causar daño físico o económico si falla.
o Robustez: un programa es robusto si se comporta “razonablemente”,
aún en situaciones que no fueron anticipadas en los requerimientos.
 Performance: afecta la usabilidad de un sistema.
 Confiabilidad: El software no debería malgastar el uso de los recursos del
sistema.
 Amigabilidad: esto ocurre si los seres humanos lo encuentran fácil de usar.
 Verificabilidad: esto ocurre si sus propiedades pueden ser verificadas
fácilmente.
 Mantenibilidad: se refiere a modificaciones que se le hacen al software
después de su lanzamiento inicial. Es software debería evolucionar
acompañando el cambio que puede ser:
o Reparativo.
o Evolutivo.
 Reusabilidad: software o componentes de él que permiten evolucionar a otra
versión con mínimas modificaciones.

5
  Portabilidad: si corre en diferentes ambientes, plataformas, entendiendo por
plataforma al hardware y sistema operativo.
 Comprensible: si es fácil de entender por otros.
 Interoperabilidad: si el software es capaz de convivir con otros.
 Productividad: la eficiencia puesta en el proceso.
 Entrega en fecha: entregar un producto en el tiempo previsto.
 Visibilidad: si todos los pasos y su actual estado están documentados
claramente.

Si el software es lo que se entrega al cliente, entonces se puede considerar un

producto.

Software como producto:

Desde los años 60 se comenzó a separar el concepto de software de hardware, fue

entonces que comenzó a constituirse como producto.

El software es tanto un producto como un objeto técnico, esto es: conocimiento

empaquetado.

La Ingeniería en Sistema se ocupa de todos los aspectos del desarrollo de un sistema

(aspectos humanos, de software, de hardware, de procesos, otros), mientras que la
Ingeniería en Software es parte de ese proceso.

La Ciencia de la Computación comprende la teoría y fundamentos, mientras que la

Ingeniería de Software comprende las formas prácticas para desarrollar y entregar un
software requerido y útil para el cliente.

Sistema:

Una colección de componentes interrelacionados que trabajan conjuntamente para

cumplir algún objetivo.

6
Modelo de procesos:

Un modelo de procesos es una descripción simplificada de un proceso del software

que presenta una visión de ese proceso.

El proceso de software consiste en actividades las cuales involucran el desarrollo de

productos de software.

Las actividades básicas son: Especificación, Desarrollo, Validación y Evolución.

Proceso de software:

Conjunto de actividades coherentes que producen un producto de software:

 Identificación y análisis de requerimientos.

 Diseño.
 Construcción.
 Implementación.
 Mantenimiento.

Los métodos son formas organizadas de producir software. Ellos incluyen sugerencias
para el cumplimento del métodos, la notación a ser usada, las reglas de validación de
modelos y guías de diseño.

Las herramientas CASE

(Computer Aided Software Engineering, Ingeniería de Software Asistida por

Computadora) son sistemas de software los cuales son diseñados para auxiliar en
actividades de rutina en el proceso de desarrollo de software. Tales como edición de
diagramas, verificar la consistencia de diagramas y mantener un registro de los testeos
efectuados.

 Upper CASE: planificación, análisis y estrategia

 Middle CASE: automatizar tareas
 Lower CASE: desarrollo e implementación, documentación

7
Crisis del software:

Existieron factores que influyeron para que el software no fuese costeable:

 La evolución de la tecnología.
 El proceso de desarrollo.
 La administración de proyectos.
 El mantenimiento del software.

Durante años el desarrollo de Software ha sido un arte, una tarea artesanal basada en
el conocimiento de los desarrolladores de código y del cliente. Se suponía que el
cliente sabía lo que necesitaba y lo solicitaba, generalmente lo hacía directamente a
los desarrolladores y en el mejor de los casos al Gerente del área de Investigación y
Desarrollo. Este tipo de práctica solo llevó a vivir “La crisis del software”, clientes
insatisfechos y pérdida de dinero para los dueños de las consultoras.

La Ingeniería en Software es una Ingeniería que abarca todos los aspectos de la

producción de software.

Los productos de Software consisten en el desarrollo de programas y toda la

documentación asociada a ellos. Los atributos esenciales son la mantenibilidad,
confiabilidad, eficiencia y usabilidad.

Los métodos son formas organizadas de producir software. Ellos incluyen sugerencias
para el cumplimento del métodos, la notación a ser usada, las reglas de validación de
modelos y guías de diseño.

Los ingenieros en Software tienen responsabilidades para con su profesión y para con
la sociedad. No están simplemente involucrados en aspectos técnicos.

La mayoría de los modelos de procesos del software se basan en uno de los tres
modelos generales o paradigmas de desarrollo.

8
Paradigmas de desarrollo de software:

 Enfoque en cascada. Totalmente secuencial, una etapa después de terminada

la anterior. Se termina, se firma y se sigue con la siguiente.
 Desarrollo iterativo. Entrelaza las actividades de especificación, desarrollo y
validación. Parte de especificaciones muy abstractas, se refina de acuerdo a las
peticiones del cliente para finalmente producir un sistema que satisfaga las
necesidades de dicho cliente.
 Ingeniería del software basado en componentes (CBSE). Supone que las partes
del sistema existen, por lo tanto, el proceso de desarrollo se enfoca en la
integración de las partes más que en su desarrollo desde el principio.

Ciclos de vida secuenciales:

El modelo en cascada

Fue el primer ciclo de vida de software, definido por Winston Royce a fines del 70.

Es el más básico de todos los modelos y sirve como bloque de construcción para los
demás modelos de ciclo de vida, plantea una visión simple basada en el concepto
que el desarrollo de software puede ser a través de una secuencia simple de fases.

Cada fase tiene un conjunto de metas bien definidas y las actividades dentro de una
fase contribuyen a la satisfacción de metas de esa fase o quizás a una subsecuencia de
metas de la fase. Existen fases discontinuas, las cuales no se solapan. Este modelo está
orientado a la documentación.

El modelo de ciclo de vida cascada, captura algunos principios básicos:

 Planear un proyecto antes de embarcarse en él.

 Definir el comportamiento externo deseado del sistema antes de diseñar su
arquitectura interna.
 Documentar los resultados de cada actividad.
 Diseñar un sistema antes de codificarlo.
 Testear un sistema después de construirlo.

9
Se realizan relevamientos de los siguientes aspectos:

 Técnicos: equipamiento, capacidad técnica de recursos.

 Funcionales: extracción completa de los Requerimientos, el 100%.
 Del Negocio: los sectores involucrados.

Su utilización es beneficiosa en:

 Productos bien definidos.

 Con metodologías técnicas bien entendidas.
 Una actualización de un mantenimiento existente.
 El traslado de un producto a una nueva plataforma.
 En un equipo de trabajo sin experiencia.

Encontramos como ventajas sobresalientes, las siguientes:

 Provee información a través del ciclo de vida y la documentación de cada fase.

 Favorece el seguimiento del proceso ordenándolo, con actividades bien
comprendidas pero complejas.

Algunas de sus desventajas son:

 Lleva mucho tiempo finalizarlo por ser tan secuencial.

 No se puede comenzar hasta tener el total de los requerimientos antes de
comenzar con el diseño.
 Es rígido, ya que no permite volver hacia etapas anteriores para corregir
errores.
 No es aconsejable para desarrollos cortos porque posee una excesiva cantidad
de documentación.

Desarrollo Evolutivo:

El Desarrollo Evolutivo consiste en desarrollar una implementación inicial, entregada

a los usuarios para sus comentarios y refinándola a través de la retroalimentación y
las versiones hasta lograr el sistema adecuado.

10
Existen 2 tipos de desarrollo evolutivo:

 Desarrollo exploratorio, donde se trabaja con el cliente para explorar sus

requerimientos y entregar un sistema final, comenzando siempre por los
requerimientos del sistema que se entienden mejor. El sistema crece,
evoluciona con lo que el cliente va proponiendo.
 Prototipos desechables, en este caso se centra en los requerimientos que no
están muy claros, por lo que el objetivo es comprender los requerimientos del
cliente para poder desarrollar una definición mejorada del sistema.

Visto desde la Ingeniería de Gestión, el modelo evolutivo tiene los siguientes

problemas:

 Carencia de Visibilidad del Proceso.

 Los sistemas frecuentemente son pobremente estructurados.
 Puede requerirse habilidades Especiales (Ej. En lenguajes de prototipación
rápida)

Ingeniería de Software Basada en Componentes:

Con los avances de la programación orientada a objetos, el conocimiento de sistemas

que actúan en forma similar se ha incorporado el concepto de componente reusable.

Este enfoque requiere de componentes de software reutilizables (cantidad que va

creciendo) y de un marco de trabajo de integración de estos.

Es posible que estos componentes sean sistemas por sí mismos, subsistemas o

módulos que tienen una funcionalidad específica.

Si bien las etapas de especificación de requerimientos y la de validación son similares a

otros procesos, las etapas intermedias son diferentes.

11
Desarrollemos estas etapas intermedias:

 Análisis de Componentes: teniendo la especificación de requerimientos se

buscan los componentes necesarios que cumplan con toda la funcionalidad o
con parte de ella. En este caso serán modificados, llevándolos al punto más
general posible, para que se constituyan en librerías de componentes capaces
de ser reutilizadas en más de un proyecto sin tener que modificarlos.
 Modificación de Requerimientos: si los componentes encontrados para los
requerimientos no son modificables, se pueden buscar soluciones alternativas,
modificando en parte el requerimiento, sin que deje de cumplir con la
necesidad del cliente.
 Diseño de Sistemas con Reutilización: esta etapa se relaciona con el marco de
trabajo, son los diseñadores los que tienen en cuenta los componentes que se
reutilizan para organizar el marco de trabajo que los satisfaga o bien diseñar
nuevos componentes porque no se cuenta con los necesarios.
 Desarrollo e Integración: estas etapas no son independientes, es necesaria su
integración ya que es parte del desarrollo tener en cuenta los componentes
que existen, los que se adquieren externamente y los que se desarrollan
internamente para integrarlos en un todo.

Ventajas de la Ingeniería de software Basada en Componentes:

 Reducir la cantidad de software a desarrollar.

 Reducir costos.
 Reducir riesgos.
 Permite una entrega más rápida.

Riesgos del Uso de este Modelo:

 Si depende totalmente de los componentes a reutilizar puede ser que el

producto no cumpla con las necesidades del cliente.
 Las nuevas versiones de los componentes pierden la especificidad de la
organización, se plantean generales, por lo que requiere de la necesidad de
relevar las reglas de negocio de cada cliente.

12
Modelo Incremental:

Si el desarrollo de sistema es complejo y es un proyecto a largo plazo, implica que

tiene asociado demasiados riesgos, como por ejemplo que no se termine, que no
cumpla con las necesidades del cliente que cambiaron desde que lo solicitó, que el
costo sea muy elevado, entre otros. Una forma de reducir estos riesgos es construir
sólo una parte de sistema, organizando por versiones lo que se incrementa.

En el modelo incremental requiere del 100% de los requerimientos al comienzo del

ciclo de vida, se toman subconjuntos de requerimientos y se desarrollan en versiones
siempre incrementando el producto de software. El documento de requerimientos es
escrito al capturar todos los requerimientos necesarios para el sistema completo, es el
que sirve de guía para los incrementos.

Este modelo es compatible con el modelo cascada, no obstante el Modelo Incremental

provee algunos beneficios significativos para los proyectos:

 Construir un sistema pequeño es siempre menos riesgoso que construir un

sistema grande.
 Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los
requerimientos planeados para los niveles subsiguientes son correctos.
 Si un error importante es realizado, sólo la última iteración necesita ser
descartada.
 Reduciendo el tiempo de desarrollo de un sistema, decrecen las probabilidades
que esos requerimientos de usuarios puedan cambiar durante el desarrollo.
 Si un error importante es realizado, el incremento previo puede ser usado.
 Los errores de desarrollo realizados en un incremento, pueden ser arreglados
antes del comienzo del próximo incremento.

Tanto el modelo de desarrollo incremental como el modelo de desarrollo evolutivo

construyen una serie de grandes versiones sucesivas de un producto. La diferencia
radica en el conocimiento de los requerimientos, mientras que la aproximación
incremental presupone que el conjunto completo de requerimientos es conocido al
comenzar, el modelo evolutivo asume que los requerimientos no son completamente
conocidos al inicio del proyecto.

13
Modelos que derivan de los anteriores:
Modelo de Prototipado de Requerimientos

El prototipado de requerimientos tiene el propósito explícito de aprender sobre los

requerimientos del sistema, para ello se crea una implementación parcial del sistema.

Por lo general consiste en la entrega de prototipos de interfaz de usuario, construido

de una manera tan rápida como sea posible. Esto es dado a los usuarios, clientes o
representantes de ellos, quienes serán los que proveen la retroalimentación sobre lo
que a ellos les gustó y no les gustó acerca del prototipo proporcionado.

En los 90 fue usado frecuentemente, porque la especificación de requerimientos para

sistemas complejos tiende a ser relativamente dificultoso de cursar.

A diferencia del modelo evolutivo donde los requerimientos mejor entendidos están
incorporados, un prototipo generalmente se construye con los requerimientos
entendidos más pobremente.

Modelo Entrega por Etapas:

Es utilizado cuando la arquitectura es conocida.

Las ventajas son:

 Permite correcciones en el transcurso del proyecto
 Permite colocar en producción las funcionalidades de mayor peso
 Obtiene un producto en forma rápida
Las desventajas son:
 Se debe trabajar con una planificación cuidadosa

Permite independizar la administración del proyecto de la parte técnica, brindándole al

usuario las funcionalidades más significativas. Se debe tener mucho cuidado porque
para implementar una fase puede requerir de la finalización de otra.

La Naturaleza Iterativa de los Desarrollos:

Modelo Iterativo:

Este modelo tiene como objetivo obtener un protocolo de desarrollo común para
cualquier tipo de aplicación de software, minimizando los procesos que tardan mucho
tiempo, para entregar avances o compilados por módulos acompañados de su
documentación facilitando la transferencia de conocimientos entre los integrantes
del proyecto y del cliente.
Se asemeja al modelo de desarrollo por prototipos, la diferencia es que en el modelo
iterativo los prototipos son entregables y tienen versión.

14
Modelo de Espiral:

Cada proyecto es organizado y explotado en miniproyectos, es conveniente para

modelos del ciclo meta-vida, o sea que transcurren en el tiempo.
Es un modelo incremental con versiones, en cada una se respetan las etapas, se
documenta y va incluyendo a los productos anteriores.

Normalmente es utilizado en:

 Sistemas de gran envergadura.
 Proyectos con un numeroso grupo de integrantes.
 Problemas de Performance.
 Existencia de requerimientos pobres, poco entendibles.
 Arquitectura pobremente detallada.

Una vez entendido el problema, continua como un proyecto en cascada.

Algunas de las ventajas son:

 Altos costos significan pocos riesgos.
 Para desarrollos rápidos.
 Provee más controles que los sistemas tradicionales.
 Se pueden “Mostrar” avances del proyecto.
 Netamente confiable.

Las desventajas que se han manifestado son:

 La administración de los riesgos.
 Ante un proyecto complejo, requiere una administración rigurosa
(concientizada). Se deben definir hitos de control de pase de una etapa a otra.
 Difícil de ser construidos con tiempos predeterminados.

15
Modelo Iterativo e Incremental:

Se toman las características de ambos modelos, del iterativo y del incremental para
lograr un modelo con mejores aplicaciones.

Las ventajas, si bien son muchas y variadas, dependen del contexto en que se
implemente el proceso.

Algunas de ellas son:

 Se divide en fases, workflows centrales e iteraciones.

 Resolución de problemas de alto riesgo en menores tiempos del proyecto.
 Visión de avance en el desarrollo desde las primeras etapas del desarrollo.
 Obtención del feedback del usuario lo antes posible, lo que permite orientar el
desarrollo al cumplimiento de sus necesidades y realizar las adaptaciones
identificadas y necesarias para cumplir con los objetivos planteados.
 Menor porcentaje de fallo del proyecto, mayor productividad del equipo y
menor cantidad de defectos.
 La complejidad del proyecto se maneja por partes.
 El aprendizaje y experiencia del equipo se da iteración tras iteración, mejora
exponencialmente el trabajo, aumenta la productividad y permite optimizar el
proceso a corto plazo.
 El trabajo iterativo deja una experiencia en el equipo que permite ir ajustando y
mejorando las planificaciones, logrando menores desvíos en la duración total
del proyecto.
 Adoptar este modelo no presenta grandes inversiones.

16
Si bien no se han detectado desventajas en el tiempo que lleva implementándose, es
importante tener en cuenta algunos aspectos:

 Su uso no garantiza por sí solo el éxito del proyecto ni de su uso.

 Existen costos ocultos en su implementación, por la necesidad de la
planificación y la necesidad de medir el impacto para no fracasar en el intento.

El modelo iterativo e incremental es utilizado por metodologías modernas y es

adoptado por UML (Lenguaje de modelado unificado).

Su gráfica es la siguiente (fuente: Book Racional Modeler)

El gráfico del modelo iterativo e incremental presenta una tabla de dos entradas, las
columnas representan las “Fases” y las filas representan los “Flujos de trabajo”.

Las fases son cuatro:

 Inicio
 Elaboración
 Construcción
 Transición

Los flujos de trabajo representan las actividades y son 7: Requerimientos, Análisis y

Diseño, Implementación, Prueba, Administración de configuración, Administración
del proyecto y Entorno.

Las tres últimas etapas se toman como acompañamiento de todo el proceso de

desarrollo.

17
Resumen:

Los temas tratados en este módulo tienen que ver directamente con la Ingeniería de
Software y su relación con la Ingeniería de Sistemas y la Ciencia de la Computación.

Dentro de los temas de la Ingeniería de Software identificamos los conceptos de

software, producto, proceso de desarrollo de software, su ciclo de vida y los distintos
modelos de desarrollo de software y su ciclo de vida.

Tenga en cuenta los puntos clave que remarcamos a continuación:

(Sommerville, Ian, capítulo 1 y 3):

 La Ingeniería en Software es una Ingeniería que abarca todos los aspectos de la

producción de software.
 Los productos de Software consisten en el desarrollo de programas y toda la
documentación asociada a ellos. Los atributos esenciales son la mantenibilidad,
confiabilidad, eficiencia y usabilidad.
 El proceso de software consiste en actividades las cuales involucran el
desarrollo de productos de software. Las actividades básicas son especificación,
desarrollo, validación y evolución.
 Los métodos son formas organizadas de producir software. Ellos incluyen
sugerencias para el cumplimento del métodos, la notación a ser usada, las
reglas de validación de modelos y guías de diseño.
 Las herramientas CASE son sistemas de software los cuales son diseñados para
auxiliar en actividades de rutina en el proceso de desarrollo de software. Tales
como edición de diagramas, verificar la consistencia de diagramas y mantener
un registro de los testeos efectuados.
 Los ingenieros en Software tienen responsabilidades para con su profesión y
para con la sociedad. No están simplemente involucrados en aspectos técnicos.

En cuanto a los Sistemas y las Ingenierías puede destacar los siguientes puntos clave:
(Sommerville, Ian, capítulo 2):

Los sistemas socio-técnicos incluyen hardware, software, personas y procesos, se

encuentran dentro de las organizaciones y ayudan a cumplir un objetivo.

 Las propiedades emergentes de un sistema son las características que actúan

como un todo no por partes o componentes del sistema. Incluyen propiedades
como el rendimiento, fiabilidad, usabilidad, seguridad y protección. El éxito o
fracaso de un sistema socio-técnico dependen de las propiedades en la mayoría
de los casos.
 Factores humanos y organizacionales influyen en el funcionamiento de los
sistemas socio-técnicos.
 Dentro de una organización pueden existir más de un tipo de sistemas, los
heredados, los propios y los adquiridos. Es posible que se planteen conflictos

18
 entre el proceso de adquisición, el proceso de desarrollo y los procesos
operativos internos.
 Los sistemas heredados son sistemas socio-técnicos.

En cuanto al proceso de software puede destacar lo siguiente:

 Proceso de Software
o Un conjunto coherente de actividades para especificar, diseñar, implementar y
testear un sistema de software.

 Modelos de Ciclo de Vida

o Cascada demasiado inflexible.
 Orientado a documentos.
o Modelos evolutivos y prototipos.
 Dependen de las decisiones tomadas antes del entendimiento del
problema.

Una buena solución es integrar prototipado rápido y cascada.

Puntos clave a tener en cuenta:

Sommerville, Ian, (capítulo 4 – temas 4.1 y 4.2):

 Los procesos de software incluyen las actividades relacionadas con la

producción de un sistema de software. Los modelos del proceso del software
son representaciones abstractas de estos procesos.
 Todos los procesos del software incluyen las etapas de especificación, diseño,
implementación, validación y evolución del software.
 Los modelos genéricos del proceso describen la organización de los procesos
del software, como son el modelo en cascada, los evolutivos y la Ingeniería
basada en componentes.
 Los modelos de iteración presentan el proceso de software como un ciclo de
actividades. El modelo en espiral, es uno de los más utilizados.
 El modelo iterativo e incremental incluye las mejores prácticas del modelo
iterativo y del modelo incremental.

19
Ingeniería de Requerimientos

Los requerimientos para un sistema son las descripciones de los servicios o funciones
proporcionados por el sistema y sus restricciones operativas.

Reflejan las necesidades o deseos de los clientes de modo que ayuden a resolver
problemas operativos o que brinden información para la toma de decisiones.

El proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones

se denomina “Ingeniería de requerimientos”.

Requerimiento:

Condición o capacidad de un usuario para resolver un problema o alcanzar un

objetivo.

El requerimiento constituye una sentencia completa acerca de que hará el sistema, sin
referirse a como lo hará.

Para plantear correctamente los Requerimientos debemos:

 Incluir a todos los involucrados en el proyecto.

 Definir los requisitos en forma independiente de la solución.
 Definir los requisitos en forma cuantitativa.

Categorías de requerimientos:

 Orientados al mercado.
 Orientados al cliente y/o usuario.

Modelos: Representaciones simplificadas de cosas reales.

20
Tipos de requerimientos:

 Requerimientos funcionales, son las declaraciones de los servicios que debe

proporcionar el sistema, la forma en que este debe reaccionar a la entrada
particular de datos, los procesos que debe hacer con sus controles y de cómo
debe comportarse en situaciones particulares.
 Requerimientos no funcionales, son consideraciones sobre los servicios del
sistema o sus funcionalidades. Por lo general están relacionadas con tiempo de
respuesta, performance, criterios de las interfaces de usuario, sobre el proceso de
desarrollo y sus estándares.
 Requerimientos del dominio, provienen del dominio de la aplicación, reflejan las
características y restricciones de su dominio. Estos requerimientos pueden ser
funcionales y no funcionales.

La Ingeniería de Requerimientos es el proceso sistemático de desarrollar

requerimientos a través de un proceso cooperativo e iterativo de analizar el problema,
documentar las observaciones resultantes en una variedad de formatos de
representación y chequear la precisión de la comprensión obtenida.

El proceso de “Elicitación” es el proceso de adquirir todo el conocimiento relevante

necesario para producir el modelo de los requerimientos del dominio del problema.

Algunos puntos claves a tener en cuenta:

 El proceso de Ingeniería de requerimientos incluye el estudio de viabilidad, de

obtención, análisis, especificación, validación y gestión de los requerimientos.
 La obtención y análisis de requerimientos es un proceso iterativo, que contempla
cambios en los requerimientos, los cuales hay que administrar correctamente.
 Se acompaña el proceso con el documento de especificación de requerimientos.
 Es conveniente detectar los errores tempranamente a través de la validación de
los requerimientos en cada etapa.

21
Workflows de Análisis, Diseño e Implementación

Se define Workflow al flujo de trabajo a seguir para la consecución de una tarea o

trabajo predeterminado. Su definición y control puede ser manual, informatizado o
mixto. Organiza y controla tareas, recursos y reglas necesarias para completar el
proceso de negocio.

La importancia del Workflow consiste en buscar la máxima automatización de los

procesos de trabajo y el control total de las diferentes etapas, durante las cuales los
documentos, la información o las tareas pasan de un participante a otro, o sea de un
rol a otro, según unas normas o procedimientos previamente definidos.

La principal limitación asociada a los Sistemas de Información (S.I.) tradicionales es

que, no contemplan los procedimientos, organización y métodos de trabajo del
sistema real.

Objetivos de un sistema de Workflow:

 Reflejar, automatizar y mecanizar los métodos y su organización en el sistema

de información.
 Establecer los mecanismos de control y de seguimiento de los Procedimientos
Organizativos.
 Independizar el método y flujo de trabajo de las personas que lo ejecutan.
 Soportar procesos de reingeniería de negocio.

Dentro del Workflow se pueden distinguir tres tipos de actividades:

 Actividades colaborativas: Un conjunto de usuarios trabajan sobre un mismo

repositorio de datos para obtener un resultado común.
 Actividades cooperativas: Un conjunto de usuarios trabajan sobre su propio
conjunto particular, estableciendo los mecanismos de cooperación entre ellos.
El trabajo individuales visto desde el punto de vista global del resultado final.
 Actividades de coordinación: se establece cómo será el trabajo cooperativo
entre los individuos.

22
Elementos S.I. Workflow:

 Procesos, conjunto de actividades organizadas.

 Rutas, secuencia de las actividades.
 Reglas, tanto de negocio como de los procedimientos o las que se establezcan
como necesarias.
 Roles, no como cargos funcionales sino como actor de una actividad.
 Políticas, que pueden ser de seguridad o del tipo de empresa o institución.

Todos los procesos de software incluyen las etapas fundamentales: especificación,

implementación, prueba y evolución.

La Validación y Verificación de los requerimientos es necesaria para que el producto

de software a entregar cumpla con las expectativas del cliente.

Proceso Unificado Racional RUP

El RUP es un modelo en fases que identifica cuatro fases diferentes en el proceso de

software relacionadas con asuntos de negocio: es iterativo e incremental.

Es recomendable crear al menos dos casos de prueba por cada requerimiento.

 Inicio: definición y permite identificar con que partes externas interactúa.

 Elaboración: arquitecturas
 Construcción: pruebas
 Transición

Mejores prácticas en RUP:

 Gestión de requerimientos.
 Desarrollo de software iterativo.
 Desarrollo basado en componentes.
 Modelado visual (usando UML).
 Verificación continua de la calidad.
 Gestión de los cambios de configuraciones.

23
Proceso de Desarrollo Unificado:

 Dirigido por casos de uso.

 Centrado en la arquitectura.
 Iterativo e incremental.

Las 4 “P” en el proceso de desarrollo de software:

 Persona
 Proyecto
 Producto
 Proceso

Modelos de Calidad de Software

Calidad: "Propiedad o conjunto de propiedades inherentes a algo, que

permiten juzgar su valor".

Los productos software son realizados por personas para personas.

Las personas desarrolladoras deben tener en cuenta claramente que son otras
personas las que utilizarán sus productos, los que pueden estar sujetos a fallos
constantes.

Incorporado el concepto de calidad se puede asegurar que los resultados de un

proyecto de software se miden según las siguientes variables:

 Alcance - (Funcionalidad)
 Tiempo - (Calendario)
 Esfuerzo - (Presupuesto - Costo)
 Calidad - (Criterios de Aceptación)

La Garantía de la calidad o Aseguramiento de la calidades el proceso que define cómo

lograr la calidad del software y cómo la organización de desarrollo conoce el nivel de
calidad requerido en el software.

24
Se pueden definir dos estándares como parte del proceso de garantía de calidad:

 Estándares de producto, se aplican sobre el producto software que se

comienza a desarrollar, incluyen estándares de documentación y estándares de
codificación.
 Estándares de proceso, definen los procesos que deben seguirse durante el
desarrollo del software y de la documentación que debe acompañarlo.

ISO 9001:2000:
 Es un instrumento de adhesión voluntaria.
 Es un texto aplicable a cualquier tipo de organización independientemente de
cuál sea su tamaño y su grado de implantación en el mundo.
 Es un texto que exige compromisos.
 CMM: El Modelo de Capacidad y Madurez o CMM (Capability Maturity Model),
es un modelo de evaluación de los procesos y del nivel de maduración de una
organización.
 La visión general de los modelos basados en la madurez de las capacidades:
Modelo de Capacidad y Madurez.
 El modelo de calidad específico para desarrollo de software: SW-CMM.

Conceptos fundamentales que plantea CMM:

 Capacidad del proceso, describe el rango de resultados esperados que se

pueden alcanzar aplicando un proceso de desarrollo de software.
 Desempeño del proceso, resultados reales alcanzados siguiendo el proceso de
desarrollo de software.
 Madurez del proceso, alcance para el que un proceso especifico es efec vo y
está definido, gerenciado, medido y controlado.
 Institucionalización, requiere de una infraestructura y una cultura corporativa
que soporte los métodos, practicas y procedimientos del negocio que sobreviva
al alejamiento de los que lo definieron en un principio, o sea, las personas
pueden irse pero los procesos quedan definidos y se transmiten dentro de la
organización por los que quedan.

25
CMM como modelo:

Es Descriptivo, Normativo y No prescriptivo.

Estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que

una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel
y sus inferiores, se considera que ha alcanzado ese nivel de madurez:

 Inicial. Las organizaciones en este nivel no disponen de un ambiente estable

para el desarrollo y mantenimiento de software. Aunque se utilicen técnicas
correctas de ingeniería, los esfuerzos se ven minados por falta de planificación.
El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo
personal, aunque a menudo se producen fracasos y casi siempre retrasos y
sobrecostes. El resultado de los proyectos es impredecible.
 Repetible. En este nivel las organizaciones disponen de unas prácticas
institucionalizadas de gestión de proyectos, existen unas métricas básicas y un
razonable seguimiento de la calidad. La relación con subcontratistas y clientes
está gestionada sistemáticamente.
 Definido. Además de una buena gestión de proyectos, a este nivel las
organizaciones disponen de correctos procedimientos de coordinación entre
grupos, formación del personal, técnicas de ingeniería más detalladas y un nivel
más avanzado de métricas en los procesos. Se implementan técnicas de
revisión por pares (peer reviews).
 Gestionado. Se caracteriza porque las organizaciones disponen de un
conjunto de métricas significativas de calidad y productividad, que se usan de
modo sistemático para la toma de decisiones y la gestión de riesgos. El
software resultante es de alta calidad.
 Optimizado. La organización completa está volcada en la mejora continua de
los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de
innovación.

26
Certificación:

La certificación es la forma de Validación que una entidad externa realiza a la

organización para aprobar o desaprobar estándares de calidad utilizados en los
procesos.

Métricas:
La medición del software, por lo tanto, se refiere a derivar un valor numérico desde
algún atributo del software o del proceso. Sirven para hacer predicciones generales
acerca del sistema y para identificar componentes anómalos. Una métrica de software
es cualquier tipo de medida relacionada con un sistema, proceso o documentación de
software.

 Medidas Directas. En el proceso de ingeniería se encuentran los valores que

identifican el costo, y el esfuerzo aplicado, las líneas de código producidas,
velocidad de ejecución, el tamaño de memoria y los defectos observados en un
determinado periodo de tiempo.
 Medidas Indirectas. Se encuentra la funcionalidad, calidad, complejidad, eficiencia,
fiabilidad, facilidad de mantenimiento, entre otras.

No existen métricas de software estandarizadas ni de uso universal.

27
Auditoría de Sistemas

Auditoría y Consultoría

La auditoría es un proceso sistemático de revisión y evaluación objetiva, realizada

sobre las actividades de una organización con el objetivo de verificar su cumplimento a
las normas y condiciones preestablecidas.

 Debe ser efectuada por un auditor calificado e independiente, el cual recolecta

evidencias y emite una opinión profesional para determinar el grado de
fiabilidad del objeto analizado.
 El contenido de una auditoria será una opinión comunicada en un informe y
elevada a las personas interesadas.
 La condición de una auditoría es que sea de carácter profesional, es decir,
realizada por una persona que posea los conocimientos y las habilidades
técnicas necesarias para la actividad.
 La justificación de una auditoría está sustentada en procedimientos para su
correcta elaboración, además cuenta con herramientas tecnológicas de
soporte.
 El objetivo de una auditoría es comunicar la información obtenida por los
procedimientos realizados.
 La finalidad de una auditoría es informar el grado de adecuación a la realidad y
a las expectativas del objeto en estudio.

Cuando hablamos de objetividad, nos referimos que el auditor interno debe tener una
actitud imparcial y neutral, y debe evitar los conflictos de intereses.

La auditoría puede ser interna o externa. La auditoría interna es una

actividad independiente y objetiva de aseguramiento y consulta
concebida para agregar valor y mejorar las operaciones de una
organización.

28
Tipos de Auditoría:

 Financiera
 De Seguridad
 De Calidad
 Política
 Informática
 De Gestión

Proceso de Auditoría
La consultoría es un servicio al cual los propietarios, directores de empresas y
funcionarios públicos pueden recurrir si sienten la necesidad de ayuda o asesoría en la
solución de problemas. Es proporcionar recomendaciones viables e implantar medidas
apropiadas para aumentar la productividad y la competitividad de las empresas. Es la
contratación de un especialista en una materia particular para obtener un
asesoramiento o consejo profesional.

La consultoría, brinda informe de las acciones que deben efectuarse en la empresa

para mejorar su rendimiento. En cambio, la auditoría sólo comunica a los interesados
(generalmente a los directores) las observaciones registradas de las actividades y de
los procesos

Auditoría Informática:

Es el proceso de recoger, agrupar y evaluar evidencias para determinar si un sistema

informatizado:

 Salvaguarda los activos.

 Mantiene la integridad de los datos.
 Lleva a cabo eficazmente los fines de la organización.
 Utiliza eficientemente los recursos.

29
En forma más particular, la auditoría informática verifica que los activos informáticos
se usen adecuadamente para lograr el objetivo de la organización.

El auditor informático debe examinar: disponibilidad, confidencialidad e integridad.

Estándares Generales:

 El auditor debe contar con la capacitación técnica y la competencia adecuada

para realizar la auditoría.
 El auditor debe mantener la independencia en la actitud mental en todos los
aspectos relacionados con la auditoría.
 El auditor debe ejercer la debida profesionalidad en el desempeño de la
auditoría y en la preparación del informe.

Etapas del Proceso de Auditoría:

 Planificación
 Ejecución o Trabajo de Campo
 Conclusión

Métodos para Mitigar el Riesgo:

 Muestreo Estadístico:
o Aleatorio
o Sistemático

 Muestreo No Estadístico:
o Al Azar
o Por Juicio Personal o Experiencia

30
Metodología de Control Interno
El control interno se encarga de monitorear diariamente las actividades de los sistemas
de información, su función es verificar que se cumplan los procedimientos, las normas
y los estándares definidos por la organización.

Las metodologías indican un conjunto de pasos exactos a seguir, así como las fases y
los momentos oportunos para ejecutarlos. El propósito de las metodologías es llegar a
un resultado a través de una secuencia de pasos lógicos y ordenados.

Contramedidas: las medidas y acciones existentes para proteger la integridad de la

información de la organización. La organización se encarga de definir y llevar a cabo
contramedidas para mitigar el impacto y evitar la ocurrencia de los mismos, y la
auditoría informática verifica la calidad y eficacia de estas contramedidas,
identificando sus puntos débiles y dando sugerencias de cómo mejorarlas.

Pirámide:

 Normas
 Organización
 Metodologías
 Objetivos de Control
 Procedimientos de Control
 Tecnologías de Seguridad
 Herramientas de Control

Tipos de Metodologías:

 Cuantitativa: Riesgos potenciales de ocurrencia, modelo matemático.

 Cualitativa: Fundada en el criterio humano para seleccionar la forma de trabajo

en base a la experiencia acumulada.

31
Podemos clasificar a las Metodologías para la Evaluación de los Sistemas de
Información en dos grandes categorías:

 Análisis de Riesgo: facilita la evaluación de los riesgos.

 Auditoría Informática: identifica en nivel de exposición por falta de controles.

Este plan es un esquema metodológico de gran importancia debido a que describe los
procedimientos, las técnicas y las herramientas a ser utilizadas en la metodología de
auditoría definida para la organización.

El control interno puede ayudar a una entidad a alcanzar sus metas de rendimiento y
de rentabilidad, y prevenir la pérdida de sus recursos.

El IT Governance es un framework cuyo fin es garantizar que las decisiones

tecnológicas se realizan apoyando los objetivos y las metas de negocio de la
organización. Los principales objetivos del IT Governance son el aseguramiento que las
inversiones en TI generen valor de negocio y la mitigación de los riesgos asociados con
la TI. Es la manera en que los principales directores y ejecutivos de las empresas
planean las inversiones en los sistemas de información.

Todas las organizaciones necesitan alinear el uso de estándares y prácticas, cómo las
vistas en COBIT, ITIL, ISO y COSO, para que se ajusten a sus requerimientos
particulares. Las cuatro nombras juegan un papel de mucha utilidad - COSO, COBIT e
ISO 17799 ayudan a definir qué es lo que debe hacerse, mientras que ITIL provee el
cómo implementar los aspectos de administración de servicios. Los puntos principales
son mantener la confidencialidad, integridad y disponibilidad de la información.

32
Marco Jurídico de la Auditoría Informática:

Derecho:

Conjunto de principios y normas, expresivos de una idea de justicia y de orden, que

regulan las relaciones humanas en toda sociedad y cuya observancia puede ser
impuesta de manera coactiva. El Derecho Informático se encarga de regular a la
comunidad informática, evitando que esta quede sin control alguno.

El Hábeas Data es un derecho que poseen las personas efectuar un amparo para
conocer los datos referidos a ellos, almacenados en bancos de datos públicos o
privados. Este derecho también permite exigir la supresión, rectificación, actualización
y confidencialidad de los mismos si fueran falsos o discriminatorios.

Delito informático:

Toda acción consciente y voluntaria que provoca un perjuicio a una persona natural o
jurídica sin que necesariamente conlleve a un beneficio material para su autor, o que,
por el contrario, produce un beneficio ilícito para su autor aun cuando no perjudique
de forma directa o inmediata a la víctima, y en cuya comisión intervienen,
indispensablemente, de forma activa, dispositivos normalmente utilizados en las
actividades informáticas.

Principales Áreas de la Auditoría Informática:

(Auditoría Física y Auditoría Ofimática)

Auditoría Física:

Mantiene las mismas técnicas, métodos y procedimientos que esta última solo
diferenciándose en su alcance más restrictivo. La Auditoría Física puede realizarse
tanto interna o externamente.

El enfoque que toma la Auditoría Física dentro de la Auditoría Informática se centra en

el ámbito tangible en el que se lleva a cabo la labor profesional de la TI en la
organización, verificando y evaluando los medios físicos, su funcionalidad, racionalidad

33
y seguridad, siendo este último (la seguridad) el foco preponderante del auditor. El
objetivo de la seguridad física es el garantizar la integridad de los activos físicos de la
TI.

Auditoría de la Ofimática:

Automatización, mediante sistemas electrónicos, de las comunicaciones y procesos

administrativos en las oficinas. En otras palabras, la ofimática es un sistema
informatizado que genera, procesa, almacena, recupera, comunica y presenta datos
relacionados con el funcionamiento de la oficina.

Durante la exposición de los controles, nos hemos referido con frecuencia a

documentos, procedimientos y políticas de actuación definidas e implantadas en la
organización; sin embargo, es un hecho habitual que algunos de ellos no hayan sido
definidos. Es labor del auditor, además de constatar tales deficiencias en su informe,
participar en la elaboración de los mismos. Es decir, el auditor debe ocuparse de
detectar las deficiencias presentes en el funcionamiento de la organización, pero,
además, debe contribuir con su experiencia y conocimiento en la elaboración de los
procedimientos y recomendaciones que permitan subsanarlas.

Áreas de Aplicación de la Auditoría Informática:

Auditoría de Bases de Datos:

La importancia de las bases de datos radica en que son ellas las que gestionan el activo
más importante que tienen las organizaciones, la información. El propósito de la
auditoría de las bases de datos es verificar el cumplimiento a los procedimientos de
seguridad para la información almacenada.

Sistema de Gestión de Base de Datos:

 Seguridad
 Integridad
 Ingreso de datos y actualización interactiva
 Independencia

34
Auditoría de las Aplicaciones:

La importancia de esta auditoría radica en el hecho del avance tecnológico constante

que exige un esfuerzo de capacitación por parte de los auditores, a fin de poder ayudar
a que las organizaciones controlen un entorno cada vez más amenazado por nuevos
riesgos, implicados en las mismas tecnologías.

Auditoría de la Seguridad:

La seguridad (física y lógica) en el área de los sistemas de información tiene los

siguientes objetivos:

 La protección de la integridad, la exactitud y la confidencialidad de la

información.
 La protección de los activos ante amenazas de vandalismo.
 La protección de los activos ante desastres naturales.
 Contar con planes y políticas de contingencia para la recuperación de los
sistemas.

Auditoría de Redes:

Modelo OSI:

 Aplicación
 Presentación
 Sesión
 Transporte
 Red
 Enlace
 Físico

Protocolos de alto nivel: SNA, OSI, Ipx/SPX, NetBIOS, TCP/IP

La seguridad no es un producto, es un proceso.

35
Administración de Proyectos
Proyecto:

 Es un trabajo singular
 Tiene fechas definidas de inicio y finalización (tiene un calendario propio)
 Tiene una especificación clara del objetivo o alcance de la tarea
 Tiene un presupuesto preestablecido y acotado
 Se constituye una organización temporal que se desmantela cuando termina
el proyecto.
 No es repetitivo, ni rutinario. 


Proyect Management:

Aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del

proyecto, a efectos de satisfacer o exceder las necesidades y expectativas de los
stakeholders del proyecto.

Un stakeholder es cualquier individuo u organización involucrado, afectado o con

intereses en el proyecto.

Triple Restricción:

 Alcance
 Tiempo
 Costo

Errores Clásicos:

 Relacionados con las personas.

 Con el proceso.
 Con el producto.
 Con la tecnología.

36
Organizaciones:

 Funcionales
 Proyectizadas
 Matriciales

No hay estructuras organizacionales buenas o malas, hay organizaciones apropiadas

o inapropiadas para cada proyecto.

El director del proyecto juega el papel más importante en la Ingeniería del Software y
su soporte. La diferencia entre el éxito o el fracaso -entre un proyecto que se
desarrolla en fecha y en presupuesto, o uno retrasado y sin control de costos- es, a
menudo, una función de la eficacia de ese director.

Un proceso define un Flujo de Actividades, las Actividades en sí mismas, los Roles que
realizan dichas actividades y los Artefactos (in,out) que manipulan dichos Roles en la
realización de las actividades para producir un resultado con agregado de valor.

Variables más importantes del proyecto:

 Recursos (costo)
 Características (alcance)
 Tiempo

Gestión del Alcance del Proyecto:

La mayor parte del tiempo que se pierde en los proyectos se pierde por el “síndrome
de inicio difuso”. Nos referimos al tiempo que transcurre en los inicios del proyecto
cuando los objetivos aún no son claros, el equipo no está formalmente consolidado y
es más, en algunos casos no se ha definido quien será el líder del proyecto.

37
Para evitar el “síndrome de inicio difuso” es importante:

 Nombrar un PM formal y tempranamente.

 Generar un Documento de Lanzamiento (Project chárter)
 Realizar la Reunión de Lanzamiento (KO meeting)

Alcance:

Todos los trabajos, y solo los trabajos necesarios para completar el producto del
proyecto.

La Estructura de Descomposición del Trabajo:

Llegados al punto en que el Alcance del Proyecto está definido en términos de sus
entregables, es momento de comenzar a pensar en los trabajos que será necesario
llevar adelante para cumplimentar estos entregables.

Para lograr este objetivo se crea una Estructura de Descomposición del Trabajo

(EDT) también conocida como WBS (por su sigla del inglés Work
Breakdown Structure).

Una EDT es un agrupamiento de elementos del proyecto, orientado a entregables, que

organiza y define el alcance total del proyecto.

Verificación del alcance: Es el proceso de obtener la aceptación formal del alcance

completado del proyecto por los stakeholders.

Gestión del Costo del Proyecto:

Una definición contable podría ser “es un sacrificio o la utilización de recursos para
lograr un objetivo específico”.
Una definición de diccionario “Cantidad rendida a
cambio de algo”.

38
La gestión del valor ganado o Earned Value Management (EVM) se utiliza
habitualmente en gestión de proyectos para medir el desempeño de un proyecto.

Mediciones de Valor Ganado:

Para poder trabajar con Valor Ganado, es necesario contar con:

 La estructura de tareas (WBS): una lista de todas las tareas y paquetes de

trabajo del proyecto, estructurados de forma jerárquica.
 Una serie de reglas para determinar objetivamente el grado de avance de cada
tarea en términos de los productos logrados.
 El cronograma de ejecución: un Diagrama de Gantt con el orden en el que se
desarrollarán las tareas.
 Una línea base del proyecto en términos de costos, o lo que es lo mismo, el
presupuesto acumulado a lo largo del tiempo o Curva S.

Las medidas centrales del Valor ganado son:

 BCWS (Budgeted Cost of Work Scheduled) o PV (Planed Value).

o Avance físico planeado a su valor presupuestado.
o Suma de los costos estimados para las actividades cronogramadas hasta
cierto momento.
 BCWP (Budgeted Cost of Work Performed) o EV (Earned Value).
o Avance físico realizado a su valor presupuestado.
o Suma de los costos estimados para las actividades completadas hasta
cierto momento.
 ACWP (Actual Cost of Work Performed) o AC (Actual Cost).
o Costo real incurrido.
o Suma de los costos reales para las actividades completadas hasta cierto
momento.

39
Índices:

 SPI (Schedule Performance Index)

o BCWP / BCWS  ( EV / PV )
o Indicador de eficiencia sobre cronograma.
o Se usa para determinar en qué medida se ha realizado el trabajo
programado.
 CPI (Cost Performance Index)
o BCWP / ACWP  ( EV / AC )
o Indicador de eficiencia sobre costos.

Proyecciones:

 EAC (Estimate At Completion)

o Presupuesto ajustado.
o Proyección del costo al fin del proyecto basado en la performance real.
o BAC / CPI (Cost Performance Index)
o Donde BAC (Budget At Completion) es:
 Presupuesto original final
 El presupuesto original de costos, al fin del proyecto.
 El último y mayor valor del BCWS (Planed Value).

 TEAC (Time Estimate At Completion)

o Tiempo estimado necesario para completar el proyecto
o SAC / SPI (Schedule Performance Index)
o Donde SAC (Schedule At Completion) es:
 Tiempo estimado originalmente en que se va a concluir el
proyecto, medido en días, meses, años, etc.

Nos permite entre otras cosas, comparar el total de trabajo realizado hasta una fecha
con el total de trabajo planificado para esa fecha.

40
Estos análisis de valor ganado nos permitirán evaluar el estado del proyecto y si es
necesario realizar ajustes.

Es un tema que suele generar bastantes dudas, especialmente entre los aspirantes a
PMP, que en su proceso de preparación para la certificación, suelen tener dificultades
para entender algunos de los conceptos clave del EVM.

Budget at Completion (BAC): El presupuesto original planificado para llevar a cabo

todo el trabajo del proyecto.

Planned Value (PV): El presupuesto planificado para conseguir un objetivo en una

fecha en concreto.

Earned Value (EV): Es el valor ganado, lo que realmente hemos conseguido con el
presupuesto que teníamos planificado.

La fórmula para calcular el EV, sería el % total de trabajo completado hasta la fecha x
el BAC.

Métodos de estimación de proyectos:

 Estimación por Analogía: Una estimación por analogía se realiza comparando

información de este proyecto con la de otro ya ejecutado y que cumpla al menos
con dos condiciones: que sea verdaderamente similar o análogo en cuanto a su
estructura y que se cuente con información de ejecución de ese proyecto. La
estimación por analogía es un método solo aconsejable cuando estamos en fases
tempranas y disponemos de poca información ya que no se espera con este
método alta precisión.
 Estimación de Ingeniería: este método se aplica cuando se cuenta con información
detallada del proyecto y es de mucha precisión si es bien aplicado. La estimación
de ingeniería requiere una EDT desagregada a bajo nivel y consiste en estimar cada
uno de los paquetes de trabajo para luego por suma ascendente lograr la
estimación de costos de los entregables finales. El principio que sustenta la
efectividad del método es la descomposición a bajo nivel.

41
 Estimación Paramétrica: una estimación paramétrica puede hacerse cuando, como
su nombre lo indica, contamos con parámetros y con algunos ratios y relaciones
que permiten modelar el tipo de actividad o producto de la actividad que se está
estimando. Ejemplo de ello es la estimación por puntos de función en el desarrollo
de software.

Cualquiera sea el método aplicado, se espera tener una estimación del costo de cada
una de las actividades del proyecto.

Gestión de Recursos Humanos del Proyecto:

Para obtener los recursos humanos necesarios para el proyecto será necesario:

 Definir las necesidades

 Obtener el equipo del proyecto.

"El director del proyecto juega el papel más importante en la Ingeniería del Software
y su soporte. La diferencia entre el éxito o el fracaso -entre un proyecto que se
desarrolla en fecha y en presupuesto, o uno retrasado y sin control de costos- es, a
menudo, una función de la eficacia de ese director".

Funciones Principales del Director del Proyecto:

 Alcanzar los objetivos definidos mediante la planificación del trabajo a realizar.

 Definir y organizar al equipo de trabajo que realizará el proyecto.
 Asignar trabajo al personal del equipo de proyecto.
 Controlar el progreso.
 Liderar el equipo de personas.

42
El liderazgo involucra:

 Motivar y recompensar.
 Mantener la perspectiva.
 Animar al grupo a tomar decisiones.
 Supervisar y mantener el comportamiento del grupo.
 Asegurar que todos ganan.

Estilo de directores de proyecto: director, facilitador, entrenador, democrático,

autocrático, burocrático.

El equipo normalmente pasa por cinco etapas en su desarrollo y camino al alto

rendimiento que son:

 Formación
 Tormenta
 Normalización
 Rendimiento
 Despedida

Pirámide de Maslow:

 Necesidades fisiológicas.
 Necesidades de seguridad.
 Necesidades sociales, amor.
 Necesidades de ego, estima.
 Auto-Realización, del ser.

43
Teoría de la Motivación e Higiene de Herzberg:

 Factores de higiene
o Seguridad
o Sueldo
o Relación con el supervisor
o Beneficios y servicios sociales.

 Factores de motivación
o El trabajo en sí mismo
o El reconocimiento
o La responsabilidad
o Progresión profesional

Gestión de las Comunicaciones del Proyecto:

La mitad del trabajo de hacer que una comunicación sea efectiva es “escuchar”.

“El escuchar debe ser un proceso ACTIVO, que aumenta la comprensión y reduce el
conflicto“

Gestión de Riesgos del Proyecto:

Un Riego es un evento discreto que tiene posibilidad (no certeza) de ocurrir y tiene
algún impacto sobre algún objetivo del proyecto.

Otro aspecto importante a resaltar es la diferencia entre Riesgo y Contingencia.

• El riesgo es un problema potencial (no ha ocurrido aún)

• La contingencia es un problema real (ya ha ocurrido).

44
El Gerenciamiento de Riesgos es el arte y ciencia de identificar, evaluar, y responder a
los riesgos de un proyecto a lo largo de la vida de mismo. Los riesgos son inherentes al
proyecto, por ende, inevitables. Debemos aprender a convivir con ellos si queremos
gestionarlos.

Un Plan de Gestión de Riesgos describe como se llevará adelante todos los procesos
vinculados al gerenciamiento de los riesgos desde la identificación hasta la confección
del Plan de Respuesta y el monitoreo y control de los riesgos.

Impacto: Puede medirse de diferentes modos:

• En función del tiempo que se perderá / ganará por su efecto.

• En función del costo, en una escala cualitativa del tipo: alto, medio, bajo, entre
otras posibilidades.

Probabilidad: Puede medirse la probabilidad en una escala numérica de porcentaje

o bien en una escala cualitativa del tipo: alta, media, baja, entre otras posibilidades.

Gestión de Abastecimiento del Proyecto:

Un contrato es un acuerdo vinculante para las partes en virtud del cual una de ellas se
compromete a proveer productos, servicios o resultados especificados, mientras la
otra parte asume el compromiso de retribuir con dinero u otra contraprestación válida
y acordada.

Contrato:

• Obliga legalmente a las partes.

• Describe derechos y obligaciones.
• Documenta un acuerdo.

Un contrato se compondrá de un conjunto de Términos y Condiciones.

El contrato puede ser a precio fijo, de costos reembolsables, con incentivos, tiempo y
materiales.

45