INGENIERÍA DE SOFTWARE

Proceso

Conjunto estructurado de actividades para desarrollar un sistema de software. Estas actividades

varían dependiendo de la organización y el tipo de sistema que debe desarrollarse.

¿Cómo se adapta un proceso de desarrollo a un proyecto real?

Todo proyecto que se genera en el ámbito profesional responde a una situación particular, dada
en un contexto y una realidad. Si el proyecto tiene como objetivo obtener un producto de
software, entonces tiene asociado el proceso de desarrollo de software.

Cada proyecto es único, aunque sea semejante a otro, siempre posee alguna característica o
regla que lo diferencia de otro, no obstante, el proceso de desarrollo ya está definido y puede
aplicarse a cualquier proyecto. Para ello tiene que permitir elegir cualquier metodología
relacionada con los distintos ciclos de vida, por lo cual se basa en las actividades básicas definidas
en el proceso.

Actividades del proceso de desarrollo de software

Las cuatro actividades o etapas básicas del proceso se organizan de forma distinta en diferentes
procesos, estas actividades son:

 Especificación
 Desarrollo
 Validación y
 Evolución.

En el enfoque en cascada se organizan de forma secuencial, mientras que en el desarrollo

evolutivo se entrelazan, esto depende del tipo de software, de las personas y de la estructura
organizacional implicada, expresa Sommerville, (Ingeniería de Software, Pág. 84)

Etapa de especificación del software

Esta etapa, por ser la primera, es muy importante, es el proceso de comprensión del problema
y definición de los servicios que requiere el sistema, como así también la identificación de las
restricciones de funcionamiento y de desarrollo.

En esta etapa no sólo se realiza la captura de los requerimientos, sino que también se realiza el
análisis de los mismos.

Los contenidos de esta etapa se profundizarán en el módulo 3.

Existen 4 fases principales en el proceso de Ingeniería de requerimientos:

1. Estudio de viabilidad, se estima si las necesidades del cliente se pueden satisfacer.

2. Obtención y análisis de requerimientos, se utilizan distintas técnicas de recolección de
datos e información, que luego es analizada.
3. Especificación de requerimientos, se describe la lista de requerimientos en un
documento.
4. Validación del requerimiento, se comprueba si es correcta la lista de requerimientos con
el cliente.
Etapa de diseño e implementación del software

La etapa de implementación del software incluye a los procesos de diseño y construcción del
software, ya que es el proceso de convertir una especificación del sistema en un sistema
ejecutable.

Esta etapa varía según el enfoque de ciclo de vida adoptado, por ejemplo, en un enfoque en
cascada se implementará un ejecutable que contiene el total de las especificaciones diseñadas
y programadas, mientras que en un enfoque evolutivo implicará un refinamiento de las
especificaciones del software.

Desarrollo

La actividad de desarrollo sigue naturalmente a la etapa de diseño. El desarrollo del software es

el proceso de codificación en un lenguaje de computación, de los requerimientos definidos,
analizados y diseñados.

Las herramientas CASE se pueden utilizar para generar un programa esqueleto a partir del
diseño, esto incluye código para definir e implementar las interfaces, necesitando el
programador solo agregar detalles de código.

Etapa de Validación del software

La validación del software es la etapa en la que se realizan comprobaciones. En general se

conoce como V & V, verificación y validación, se utiliza para mostrar que el sistema se ajusta a
su especificación y que cumple las expectativas del cliente.

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.

Los requerimientos reflejan las necesidades o deseos de los clientes, 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”.

Los requerimientos se pueden clasificar de distintas formas, teniendo en cuenta sus

características. En cuanto a las categorías, se pueden plantear dos:

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

Los requerimientos orientados al mercado son mas generales. El cliente es en general no

siempre bien identificado, es mas un sector de mercado.

Los requerimientos específicos para un cliente atienden las necesidades de éste.

Desde una perspectiva del software, los requerimientos no refieren sólo a las personas y los
negocios, sino que podemos verlos en relación a los sistemas.

Podemos definirlos de la siguiente manera:

  Los requerimientos del usuario son declaraciones, normalmente en lenguaje natural y
en diagramas, de los servicios que se espera que el sistema proporcione y de las
restricciones bajo las cuales debe funcionar.
 Los requerimientos del sistema establecen con detalle las funciones, servicios y
restricciones operativas del sistema. El documento de requerimientos del sistema debe
ser preciso, definiendo claramente y exactamente, lo que se va a implementar.

Concepto de 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”.

Desde la perspectiva del software, los errores de los sistemas llevan a costos elevados en la
corrección de los mismos, este es uno de los factores, si no es el mas importante, que da lugar
a la Ingeniería de requerimientos, que es parte de la Ingeniería de Software.

 Los usuarios no saben lo que quieren.

 Los de sistemas quieren que les hagamos su trabajo.

¿Qué constituye un requerimiento?

El conocimiento convencional mas ampliamente compartido dice que “requerimiento

constituye una sentencia completa acerca de qué hará el sistema, sin referirse a cómo lo hará”.

La importancia de los requerimientos se basa en que cuanto más tarde se detecta un error, más
cuesta resolverlo. Son la fase inicial del proceso de desarrollo de software y de ella depende, en
gran parte, el éxito del proyecto.

Identificación de Requerimientos.

Es descubrir los requerimientos para un sistema por parte de los clientes, usuarios, otros
afectados.

Es determinar cual es la necesidad, es un proceso de captura donde todo debe registrarse.

Análisis de Requerimientos

Es una actividad en la que tratamos de estructurar y comprender mejor el resultado de la

identificación de requerimientos. Adquirir un nivel de abstracción que permita ver y entender
de forma global el requerimiento, para luego entrar en los detalles.

Tipos de requerimientos

Funcionales: son las declaraciones de los servicios que debe proporcionar el sistema. Como debe
reaccionar ante una entrada, procesos y controles.

No funcionales: Están relacionados con la performance, el tiempo de respuesta, interfases de

usuario.

Del dominio: Reflejan las características y restricciones de su dominio.

Candidatos: Son los requerimientos funcionales que no se tendrán en cuenta en este momento
y pueden ser incorporados en el futuro.

Elicitación
Es el proceso de adquirir todo el conocimiento relevante necesario para producir el modelo de
los requerimientos del dominio del problema.

El analista debe conocer la naturaleza del problema, entender del tema para poder interactuar
con el cliente.

Técnicas de Elicitación

 Entrevistas
 Torbellinos de ideas
 Análisis de documentación existente
 Observación
 Análisis de los objetivos

Especificación de requerimientos

La especificación de requerimientos funcionales de un sistema debe estar completa y ser

consistente.

Completa significa que todos los servicios solicitados por el usuario deben estar definidos.

Consistencia significa que los requerimientos no deben tener definiciones contradictorias.

Una vez terminado el relevamiento y detectadas las necesidades del cliente, los distintos tipos
de requerimientos, restricciones, reglas de negocio y dominio del problema, es necesario
realizar la especificación y dejarlos en forma explícita en un documento.

Este documento de requerimientos del software, denominado SRS o ERS, es la declaración oficial
de qué deben implementar los desarrolladores del sistema.

Se han definido estándares para el documento de requerimientos, el más conocido y utilizado

es el de IEEE/ANSY 830-1998.

Validación de requerimientos

Trata de mostrar que los requerimientos realmente definen el sistema que el cliente desea.

Es importante validarlos a tiempo, antes de que estén codificados.

Las verificaciones pueden ser:

 Verificaciones de validez: durante el análisis pueden aparecer funciones adicionales o

diferentes.
 Verificación de consistencia: los requerimientos no deben contradecirse o tener
definiciones ambiguas.
 Verificación de completitud: deben definir todas las funcionalidades del sistema.
 Verificaciones de realismo: deben verificarse para asegurarse que se pueden
implementar.

Las validaciones pueden realizarse mediante:

 La revisión sistemática de los requerimientos.

 Construcción de prototipos.
 Generación de casos de prueba.

¿Qué es Workflow?
Se define así al flujo de trabajo a seguir para la consecución de una tarea o trabajo
predeterminado. El flujo de trabajo determina como se estructuran las tareas, como se realizan,
cual es su orden correlativo, como se sincronizan, como fluye la información que soporta.

Su definición y control puede ser manual, informatizado o mixto.

Su importancia consiste en buscar la máxima automatización de los procesos de trabajo y el

control total de las diferentes etapas, donde los documentos, la información o las tareas pasan
de un participante a otro.

La principal limitación asociada a los Sistemas de Información tradicionales es que, no

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

Objetivos:

 Reflejar, automatizar y mecanizar los métodos en el sistema de información.

 Establecer los mecanismos de control y seguimiento.

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.
 Actividades de coordinación: se establece cómo será el trabajo cooperativo entre los
individuos.

Los flujos de trabajo como Workflow representan mejor la realidad de los procesos, dan una
vista horizontal del mismo, con lo que el actor no es sólo responsable de su actividad, sino que
es responsable del proceso, en cuanto que hay otro actor que depende de que su actividad esté
resuelta satisfactoriamente.

Elementos necesarios para implementar S.I. Workflow

 Procesos, conjunto de actividades organizadas

 Rutas, secuencia de actividades
 Reglas, de negocio como de procedimiento
 Roles, actores de una actividad
 Políticas, de seguridad o del tipo empresa

El proceso unificado racional

El RUP es un modelo en fases que identifica cuatro fases diferentes en el proceso de software
relacionadas con asuntos de negocio:

1- Inicio. Su objetivo es establecer un caso de negocio para el sistema, identificando todas

las entidades externas que interactúan con el sistema.
2- Elaboración. Desarrollar un plan del proyecto e identificar los riesgos. Finalizadas esta
fase se debe contar con un plan de proyecto, la especificación de requerimientos y los
casos de uso.
3- Construcción. Comprende el diseño a programación y las pruebas del sistema,
obteniendo un sistema de software operativo y su documentación.
4- Transición. Es la actividad de instalar el sistema en un entorno real para su uso por el
usuario final.
Como no se cuenta con el 100% de los requerimientos, estas fases se presentan de forma
iterativa e incremental.

Las buenas prácticas que presenta RUP

El RUP recomienda seis buenas prácticas de la Ingeniería de software en el desarrollo de

sistemas:

1- Desarrolle el software de forma iterativa, planificando incrementos del sistema basado

en las prioridades del usuario.
2- Gestione los requerimientos documentándolos debidamente.
3- Utilice arquitecturas basadas en componentes, identificando cuales pueden ser
reusables.
4- Modele de forma visual el Software utilizando UML.
5- Verifique la calidad.
6- Controle los cambios.

El proceso unificado presenta 3 aspectos a la hora de implementar su modelo:

 Dirigido por casos de uso

 Centrado en la arquitectura
 Iterativo e Incremental

Concepto de calidad

Calidad se puede definir como “Propiedad o conjunto de propiedades inherentes a algo, que
permiten juzgar su valor”

De esta forma podríamos decir que la calidad de los productos puede medirse como una
comparación de sus características y atributos.

Calidad en los productos de Software

Para el software también existen medidas que pueden hacerlo comparable, tales como puntos
de función, líneas de código y otras.

Para ello se debe tener en cuenta lo siguiente:

 Los productos de software son realizados por personas para personas.

 Los desarrolladores deben tener en cuenta que son otras personas las que utilizarán sus
productos, los que pueden estar sujetos a fallos constantes.

La gestión de calidad se estructura en tres actividades principales:

 Garantía de la calidad, haciendo uso de tecnología eficiente.

 Planificación de la calidad, aplicando técnicas formales.
 Control de la calidad, controlando la documentación.
 Administración de la calidad, con un correcto mantenimiento y servicio post-venta.

La gestión y mejora de la calidad del proceso debe minimizar los defectos en el software
entregado. Esto implica:

 Definir estándares de proceso.

 Supervisar el proceso de desarrollo.
  Confeccionar los informes necesarios del proceso.

Al finalizar el proceso de desarrollo se espera:

 La satisfacción del cliente.

 La comercialización y uso masivo.
 Que responda a los requerimientos.
 Buen rendimiento.
 Fácil de usar.
 Que se acompañe con la documentación necesaria.

Prueba en el proceso unificado

La prueba es el proceso de ejercitar un programa con la intención específica de encontrar errores

previos a la entrega al usuario final.

Las dos actividades fundamentales de pruebas son:

 La prueba de componentes, es probar las partes del sistema, tratando de descubrir

defectos en los componentes.
 La prueba del sistema, probar el sistema integralmente, como un todo, que satisface los
requerimientos funcionales, los no funcionales y que no se comporta de forma
inesperada.

El proceso de pruebas tiene dos objetivos:

1- Demostrar al desarrollador y al cliente que el software satisface sus requerimientos.

2- Descubrir defectos, comportamientos incorrectos o que no cumple su especificación.

Tipos de pruebas

 Deberían probarse todas las funciones del sistema que se accedan a través de menúes.
Prueba funcional.
 Deben probarse todas las combinaciones de funciones, como los ingresos de datos.
 El ingreso de datos debe hacerse con datos correctos e incorrectos.

Pruebas del sistema

Se plantean dos fases de pruebas distintas:

 Pruebas de integración, en la que el equipo de pruebas tiene acceso al código fuente del
sistema. Pruebas de Caja Blanca.
 Pruebas de entrega, se valida que el sistema cumpla con los requerimientos y que el
sistema es confiable, o sea, que funciona correctamente. Pruebas de Caja Negra.

Luego se prueban sus propiedades emergentes:

 Pruebas de rendimiento.

Diseño de casos de prueba

En el proceso unificado de desarrollo de software, los casos de uso guían el proceso, marcando
el seguimiento de los requerimientos, de igual manera existen los casos de prueba que guían
esta etapa y que se diseñan en base a los casos de uso de los requerimientos.

Calidad del proceso

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 calidad es el proceso que define como lograr la

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

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

1- 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.
2- 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
 Es un texto que exige compromisos

Modelo de calidad CMM

CMM, es un esquema que representa un camino de mejoramientos, permite determinar la

madurez y evaluar las capacidades de las organizaciones que desarrollan software,
recomendado para las organizaciones que quieren incrementar la capacidad de su proceso de
desarrollo.

El Modelo de Capacidad y Madurez o CMM, es un modelo de evaluación de los procesos y del

nivel de maduración de una organización.

CMM, es un esquema que representa un camino de mejoramientos, permite determinar la

madurez y evaluar las capacidades de las organizaciones que desarrollan software.

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.

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.

Las características que presentan las organizaciones maduras son:

Comunicación y coordinación entre los diferentes grupos de trabajo de la
organización y
externos.
Todos los trabajos son realizados de acuerdo a un plan.
Posee la habilidad para administrar los procesos de desarrollo y mantenimiento del
software.
Las prácticas son consistentes con los procesos y los procesos son debidamente
comunicados y compartidos por todos.
Los administradores monitorean los procesos, la calidad del producto y la
satisfacción del cliente.
Los procesos son actualizados cuando son necesarios
Los roles y responsabilidades están bien definidos
La planificación y los presupuestos son realistas y basados en la performance
histórica de otros proyectos. Los resultados esperados pueden alcanzarse en costos,
tiempo y calidad del producto.
La gerencia formalmente se compromete.
Se sigue un proceso disciplinado, todos los participantes entienden el valor de
hacerlo y existe la infraestructura necesaria para darle soporte.

Las organizaciones inmaduras presentan características bien definidas, como son:

Proceso improvisado durante el proyecto de desarrollo de software
Procesos aprobados son ignorados a la hora de desarrollar el software
Reactivas, no pro-activas, esperan a que pase algo para implementar el proceso
Presupuestos y planificaciones no realistas
Calidad del producto sacrificada en pos de la entrega, el tiempo siempre es un
determinante que hace que se sacrifique la calidad del producto y que no se cumpla
con el proceso.
No se miden los objetivos de calidad, ya sea porque no se saben o porque no le
dan la importancia que tienen.

Concepto de 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. Estos valores son comparados con los establecidos por los
estándares de la organización.

Las mediciones de software pueden utilizarse fundamentalmente para cubrir dos objetivos:
  Hacer predicciones generales acerca del sistema, midiendo las características de los
componentes del sistema y reuniéndolas, pudiendo derivar en una estimación general
de alguno de los atributos del sistema, como puede el número de fallos detectados.

 Identificar componentes anómalos, implica encontrar componentes que tengan un

comportamiento fuera de lo normal, normalmente se establece como prioridad la
medición de los componentes de mayor complejidad y criticidad, que se supone pueden
tener mayor cantidad de errores en un funcionamiento.

Si bien todos los estándares de calidad definen la necesidad de hacer mediciones, sólo indican
qué se deben realizar, pero no establecen cómo, cuáles ni dónde aplicarlas, esta es una tarea
que se determina en los lineamientos estratégicos de la organización, quien con la ayuda de los
ingenieros y líderes de proyecto tienen en cuenta las metas de la organización y los objetivos de
las áreas para establecerlas.

Una métrica de software es cualquier tipo de medida relacionada con un sistema, proceso o
documentación de software.

Como se ha expresado anteriormente, es necesario medir para lograr una mejora en el proceso
y en el producto.

Las mediciones del mundo físico pueden englobarse en dos categorías: medidas directas y
medidas indirectas.

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 período de tiempo.

Medidas Indirectas. Se encuentra la funcionalidad, calidad, complejidad, eficiencia, fiabilidad,

facilidad de mantenimiento, entre otras.

La gestión de la calidad del software permite señalar si éste tiene escaso número de defectos y
si alcanza los estándares requeridos de mantenibilidad, fiabilidad y portabilidad.

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

La calidad de productos software está dada por los procesos que lo desarrollan y no por el
producto mismo.

Las métricas del software también se pueden clasificar teniendo en cuenta lo que miden y
cómo lo miden, citemos algunas de ellas:

Métricas técnicas: Se centran en las características de software.

Métricas de calidad: indican cómo se ajusta el software a los requisitos implícitos y explícitos
del cliente.

Métricas de productividad. Se centran en el rendimiento del proceso de la ingeniería del

software, es decir, qué tan productivo va a ser el software que se va a diseñar.

Métricas orientadas a las personas. Informan sobre la forma que la gente desarrolla el software
y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos.

Métricas orientas al tamaño. Sirven para determinar el tiempo necesario para terminar el
software y cuantas personas se van a necesitar.
Métricas orientadas a la función. Son medidas indirectas del software y del proceso, se centran
en la funcionalidad o utilidad del programa.

Los puntos de función, miden lo que el software hace y no como lo hace.

AUDITORÍA DE SISTEMAS
Auditoría

La auditoría puede definirse como 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 auditoría 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.

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

Clases de Auditoría

 Auditoría Financiera (contable)

 Auditoría de Seguridad (identificar vulnerabilidades)
 Auditoría de Calidad (cumplimiento del sistema de calidad)
 Auditoría Política
 Auditoría Informática (evalúa los sistemas de información para verificar la integridad de
los datos que administra). Se aplican procedimientos para auditar el uso y el
mantenimiento del software y el hardware de la organización.

La auditora interna es generalmente realizada por personal de la misma organización que

es auditada, mientras que la auditoría externa la efectúa otra organización contratada para
tal fin y generalmente especializada en este tipo de actividades.

La auditoría interna verifica el grado de exactitud en la observancia a las políticas,

procedimientos, métodos, normas y leyes, así como el desempeño de todas las áreas de la
estructura organizativa. Evalúa el trabajo del personal y el funcionamiento de los equipos y
los sistemas.

Técnica de Auditoría

Son los métodos disponibles para obtener el material de evidencia y sus resultados en forma
de opiniones y conclusiones.

Procedimiento de Auditoría

Los procedimientos son el conjunto de las técnicas de auditoría a ser aplicables a los
artefactos revisados en una actividad de auditoría. Se podría decir que las técnicas son las
herramientas de trabajo de un auditor y los procedimientos son la combinación de estas
herramientas aplicadas a una situación en particular. Por lo tanto, si las técnicas no son las
adecuadas, los procedimientos serán incorrectos y se fallará en el resultado final del trabajo
de auditoría.

Proceso de Auditoría
ETAPAS DEL PROCESO DE AUDITORÍA

 Planificación: Visita previa, revisión de documentación, creación plan de auditorías,

redacción de cuestionarios, elaboración del programa de auditorías.
 Ejecución: aplicación de los procedimientos de auditoría, comunicación constante con
la dirección.
 Conclusión: Reporte de auditoría con hallazgos y recomendaciones.

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.

CONTROL INTERNO INFORMÁTICO

Tiene funciones propias (administración de la seguridad lógica, vigilancia del cumplimiento

de normas y controles, control del entorno de desarrollo, etc.).

Funciones de control dual con otros departamentos.

Función normativa y del cumplimiento del marco jurídico.

El control informático es el componente de la “actuación segura” entre los usuarios, la

informática y control interno, todos ellos auditados por auditoría informática.

PLAN DEL AUDITOR INFORMÁTICO

En este documento se debe describir todo sobre esta función y el trabajo que realiza en la
entidad.

Sus partes son:

Funciones: Se describe la organización interna y las funciones de forma precisa.

Procedimientos: de apertura, el de entrega, informe preliminar, cierre, redacción de

informe final.
Tipos de auditorías: Metodologías y cuestionarios de las mismas.
Sistema de Evaluación: Además, los distintos aspectos que evalúa.

Nivel de exposición: Es un número del 1 al 10 que define la fecha de cuando será la próxima
auditoría.

Seguimiento de acciones correctivas: sugerencias de corrección del auditor.

Plan de trabajo: Calendario de actividades y los recursos asignados.

INFORME DE AUDITORÍA

Normas: En 1996 la Unión Europea publicó el Libro Verde de la Auditoría con normas IFAC

Irregularidades: Son los fraudes y errores. La responsabilidad del auditor se centra en

planificar, llevar a cabo y evaluar su trabajo para obtener una expectativa razonable de su
detección.

Documentación: El informe de auditoría debe estar basado en la documentación o papeles

de trabajo. Los papeles de trabajo pueden llegar a tener valor en los Tribunales de Justicia.

Preparación, contenido y estructura general

Es el momento adecuado de separar lo significativo de lo no significativo, debidamente

evaluados por su importancia y vinculación.

No existe un formato vinculante, si esquemas con requisitos mínimos aconsejables.

El informe deberá ser claro, adecuado, suficiente y comprensible. Una utilización apropiada
del lenguaje informático resulta recomendable.

Puntos esenciales del informe de auditoría:

 Identificación del informe.

 Identificación del cliente.
 Identificación de la entidad auditada.
 Objetivos de la auditoría.
 Normativa aplicada y excepciones
 Alcance de la Auditoría.
 Conclusiones.
MARCO JURÍDICO DE LA AUDITORÍA INFORMÁTICA

La ley 25.326 – Ley de protección de datos personales y Habeas Data fue sancionada en
Argentina el 4 de octubre del año 2000. El artículo 1º define el objetivo de la ley:
“La presente ley tiene por objeto la protección integral de los datos personales
asentados en archivos, registros, bancos de datos, u otros medios técnicos de
tratamiento de datos, sean públicos o privados…”

Datos personales: Información de cualquier tipo de personas físicas o de existencia

ideal.
Datos sensibles: origen racial, étnico, opiniones políticas, religiosas, morales, sindicales,
salud o vida sexual.
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.

Como consecuencia de la ley 25.326 es posible declarar que el uso de información de las
personas con un propósito distinto al ingresado al banco de datos, y en especial la falta de
veracidad de la misma, constituye una violación a la protección de datos personales.
Ejemplo de esto son correos electrónicos con propagandas, las promociones telefónicas, o
la difusión de datos entre entidades privadas cuando las direcciones de mail, el número de
teléfono u otros datos extraído de las bases no tuvieron el consentimiento del titular.

Para proteger jurídicamente al hardware se lo incluía en la categoría de “patentabilidad” o

“inventos patentables”, dado que se lo consideraba como un elemento material o un
artefacto. Sin embargo, no es tan sencillo clasificar al software dentro de un marco jurídico
por su carácter de elemento inmaterial, incorporal, intelectual, moral y económico.

El Derecho ha adoptado, de manera generalizada internacionalmente, al régimen de

derecho de autor para incluir a los programas de software.

En nuestro país la Dirección Nacional de Propiedad Industrial rechazó patentar al software

debido a que el artículo 4 de la ley 111 veda la protección jurídica a los inventos
completamente teóricos sin aplicación industrial indicada.

No obstante, el decreto del Poder Ejecutivo 165/94 incluyó al software dentro de la ley
Propiedad Intelectual 11.723, con lo que le brinda protección jurídica y posibilita su registro
en la Dirección Nacional de Derecho de Autor.

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.

La Auditoría Jurídica es una rama de la Auditoría Informática que se encarga de verificar

que la TI y los sistemas de información de una organización se ajusten a las normas y a la
legislación vigente. De esta forma se convierte en una medida preventiva contra sanciones,
demandas y demás reclamos legales que la entidad pueda sufrir a causa de negligencias o
irregularidad en el contenido o uso de los sistemas informáticos.

AUDITORIA FISICA

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 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.
Se puede entender por activos físicos a las personas, los equipamientos y las
comunicaciones

AUDITORÍA OFIMATICA

La ofimática es un sistema informatizado que genera, procesa, almacena, recupera,

comunica y presenta datos relacionados con el funcionamiento de la oficina. (Planillas de
cálculo, procesadores de texto, agendas electrónicas, correo electrónico etc.)

Existe falta de control centralizado en cuanto a la compra e implementación de estas

herramientas en forma homogénea en toda la empresa.

El auditor debe verificar que el inventario ofimático refleje con exactitud los equipos y las
aplicaciones existentes en la organización.

El auditor evalúa el procedimiento de adquisiciones de equipos, programas y aplicaciones.

el auditor debe prestar especial atención a las necesidades que motivaron el pedido de
equipos y la integración de estos con el sistema existente.

Se debe evaluar si los usuarios cuentan con la suficiente formación y la documentación de

apoyo necesaria para el desarrollo de sus tareas de un modo eficaz y eficiente.

Se debe determinar si el procedimiento de respaldo es fiable y si se garantiza la recuperación

de la información en caso de necesidad.

Un punto para analizar es el grado de exposición ante la posibilidad de intrusión de virus

informáticos.

AUDITORÍA DE BASES DE DATOS Y APLICACIONES.

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.

Es necesario implementar las medidas correctas de protección para las bases de datos,
donde se controlará a los usuarios que ingresan al sistema y el nivel de exposición que
puedan tener a los datos dependiendo de los niveles de autorización establecidos.

El propósito de la auditoria de las bases de datos es verificar el cumplimiento a los

procedimientos de seguridad para la información almacenada.

Los puntos claves a verificar que tiene que abarcar una metodología incluyen a la definición
de las estructuras físicas y lógicas de las bases de datos, el control de carga y de desempeño
de las bases, la integridad y la protección de la información, los procedimientos de
programación y mantenimiento para aplicativos de las bases, los mecanismos de respaldo y
recuperación de datos.

El primer paso para efectuar una auditoria de aplicaciones es lograr un conocimiento básico
de las aplicaciones que posee la organización y del entorno informático donde están
instaladas.
AUDITORÍA DE LA SEGURIDAD.
La función de la seguridad es asegurarse que los sistemas de información sean accedidos y
modificados solo por el personal autorizado, quienes solo deben actúan dentro de los límites
de su autorización.

La seguridad 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
Aquí es donde se verifican los mecanismos de cifrado para las comunicaciones, para
comprobar la eficiencia de los sistemas existentes y elevar recomendaciones de mejora si
fuere necesario.

Al mismo tiempo, los usuarios deben tener restricciones de acceso por dominios de red, y
solo pueden instalar los aplicativos señalados para sus puestos.

La auditoría de seguridad de las redes cobra importancia cuando se trabaja con

transferencias electrónicas de dinero, comercio electrónico, pago con tarjetas y similares.

ADMINISTRACIÓN DE PROYECTOS
Se define proyecto como: “designio o pensamiento de ejecutar algo” y como “conjunto de
escritos, cálculos y dibujos que se hacen para dar idea de cómo ha de ser y lo que ha de
costar una obra de arquitectura o de ingeniería”.

“Un proyecto es un trabajo singular con unas fechas definidas de inicio y finalización
(calendario), una especificación clara del objetivo o alcance de la tarea, un presupuesto
preestablecido y, habitualmente, una organización temporal que se desmantela cuando
termina el proyecto” J. Lewis.

Un proyecto se diferencia de otros tipos de trabajos fundamentalmente es su carácter de

“única vez”, es decir, por más que pueda ejecutar muchos proyectos similares, este es único
y diferente en sus condiciones y producto final, no es repetitivo, ni rutinario.
Proyecto
Muere al finalizar
Objetivo particular, ejecutados por única
vez
Tiempo determinado, acotado.
Revolucionarios (cambios importantes)
Equipos variables
Los recursos entran y salen en la medida
que son requeridos
Mucha incertidumbre, más riesgos
Proceso
No muere, no termina
Repetitivos, secuenciales, ordinarios
El tiempo no está acotado, existe para
perdurar en el tiempo.
Evolutivo (mejora continua)
Equipos relativamente estables
Los recursos están disponibles por más
tiempo
Todo está mayormente definido, menos
riesgos

La administración de proyectos es el conjunto de actividades que deberá llevar adelante el

Gerente del Proyecto para conseguir los objetivos planteados.

El director del proyecto es la persona responsable de alcanzar los objetivos del proyecto. La
dirección de un proyecto incluye:

 Identificar los requisitos

 Establecer unos objetivos claros y posibles de realizar
 Equilibrar las demandas concurrentes de calidad, alcance, tiempo y costos

CICLO DE VIDA

El conjunto de estas fases se conoce como ciclo de vida del proyecto:

 Fase Inicial
 Fases Intermedias
 Fase Final
EL PROCESO DE GESTIÓN DE PROYECTOS

La construcción de software requiere de dos aspectos de fundamental importancia, por un

lado, debe seguirse un determinado “proceso”, por otro lado, se lleva adelante un
“proyecto” que pone todos estos procesos en un marco de restricciones de tiempo y costo.

• El Proceso dice “que” y “como”

• El Proyecto dice “quien” y “cuando”

El PMI (Project Management Institute, ong) define nueve Áreas de Conocimiento que un
Project Manager debe dominar para convertirse en un buen Administrador de Proyectos:

 Integración. Son las necesidades de coordinación entre los elementos del proyecto.
 Alcance. Deben ser previstos y considerados todos los trabajos necesarios para
terminar el proyecto.
 Tiempo. Trata de conseguir que el proyecto termine en el plazo establecido.
 Costo. Trata de conseguir que el proyecto se concluya dentro del presupuesto
aprobado.
 Calidad. Aseguramiento y control de la calidad.
 Recursos Humanos. Optimizar la labor de las personas.
  Comunicaciones. Elaboración de informes.
 Riesgos. Identificar los factores de riesgo.
 Adquisiciones. Compras, proveedores y contrataciones.

ALCANCE DEL PROYECTO

ALCANCE: son todos los trabajos, y solo los trabajos necesarios para completar el producto
del proyecto.

Mientras el grado de cumplimiento del Alcance del producto se mide contra las
especificaciones, el grado de cumplimiento de Alcance del Proyecto se mide contra el Plan.

A efectos de Definir el Alcance, será necesario generar la “Declaración del Alcance”, estamos
hablando de un documento que permita declarar con claridad lo que Si está incluido en el
proyecto dejando muy claro lo que No incluye.

Una buena declaración del Alcance (conocida también por su nombre en inglés, (Scope
Statement), se escribe en términos de sus Entregables, es decir los productos o
subproductos que se generan a lo largo del proyecto.

Finalmente suele agregarse otro punto importante a esta declaración: Los supuestos y
restricciones.

Entendemos por restricciones todos los factores que limitan las decisiones del equipo del
proyecto.

Los supuestos son todos los criterios y condiciones que se asumen como ciertos y válidos a
la hora de ejecutar el proyecto.

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)

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.
Control de Cambios del alcance

Es el proceso de asegurar que los cambios ocurren de manera ordenada y beneficiosa.

Prestemos atención a que no se dice que los cambios no ocurran, sino que estén bajo control.

GESTIÓN DEL TIEMPO DEL PROYECTO

Para poder llevar adelante una adecuada gestión de tiempos del proyecto será necesario hacer
un correcto plan de tareas. Para ello deberemos, en primer lugar, hacer una clara y completa
definición de actividades.

Este proceso consiste en identificar y documentar las actividades específicas que deben ser
efectuadas para producir los entregables identificados en la Estructura de Descomposición del
Trabajo (EDT).

Estimación

Lo primero es lograr una predicción de cuál será la cantidad de jornadas laborales que insumirá
cada actividad del proyecto.

Inicialmente se calculará el esfuerzo. El esfuerzo es una medida de la carga de trabajo requerida

para la actividad.

El esfuerzo será medido en horas/hombre o en horas/máquina dependiendo de cuál sea el

recurso más crítico.

GESTIÓN DEL COSTO DEL PROYECTO

La planificación de los recursos implica determinar qué recursos, en qué cantidades y cuándo
van a ser utilizados para ejecutar las actividades del proyecto

Una vez que los recursos han sido claramente determinados es necesario estimar el costo de
utilizar los recursos necesarios para completar las actividades del proyecto.

ESTIMACIÓN DE COSTOS

Por analogía: comparando el proyecto con otro.

Estimación de Ingeniería: Requiere un EDT. Estimar cada uno de los paquetes de trabajo.

Estimación paramétrica: cuando contamos con parámetros.

PRESUPUESTACIÓN

Es distribuir las estimaciones a lo largo del tiempo, lo cual indica que trabajaremos con las
estimaciones y el cronograma.
CONTROL DE COSTOS

La principal técnica para controlar los costos y el avance del proyecto es la Gestión del Valor
Ganado.

El valor Ganado es una técnica de control de proyectos que permite controlar su ejecución y
avance a través del presupuesto y el calendario de ejecución.

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.
 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.

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.

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.

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

GESTIÓN DE LAS COMUNICACIONES

La planificación de las comunicaciones implica determinar las necesidades de información

y comunicaciones de los stakeholders del proyecto. Esto incluye determinar lo que necesita
ser comunicado, a quien, cuando, con que método y cuan frecuentemente.

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 “

Informes
Son el instrumento más común y estandarizado del que se sirve un gestor de proyectos
para mantener una comunicación escrita con todos los interesados y especialmente con el
cliente, o sponsor.

El informe suele apoyarse en documentación gráfica (diagramas, croquis, esquemas, etc.)

que ayudan a una comprensión rápida de la situación.

Gestión de Riesgos
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).

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.

La identificación de riesgos es el proceso sistemático de descubrir anticipadamente las

amenazas sobre los objetivos del proyecto.

Gestión de abastecimiento del

proyecto.
La Gestión del abastecimiento o adquisiciones del proyecto se refiere a los procesos
necesarios para lograr abastecer al proyecto de todos los productos, servicios o resultados
necesarios para llevar adelante el proyecto.
Esto se logra:
• Determinando qué, cómo y cuándo comprar o adquirir.
• Documentando los requerimientos del producto o servicio e identificando los
proveedores potenciales.
• Obteniendo cotizaciones, ofertas y/o propuestas adecuadas.
• Revisando ofertas y seleccionando los proveedores escogidos.
• Manejando el contrato y las relaciones entre los vendedores y los compradores.
• Completando y cerrando los contratos aplicables al proyecto.

Planificación del abastecimiento

El proceso de planificación del abastecimiento del proyecto consistirá en definir:
 Que se compra y que se hace en el proyecto
 Tipos de garantías a requerir
 Identificación de proveedores precalificados

Contratos
Los proyectos requieren generalmente la implementación de numerosas contrataciones
de diversa índole.
El instrumento esencial en estos procesos es el CONTRATO.
 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.
Un 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.

Cierre de contrato
El cierre del contrato debe aplicarse a cada una de las contrataciones pautadas para el
proyecto.
Consistirá en:
• Verificar que todos los trabajos y productos han sido aceptados.
• Asegurar que se tiene todos los registros de las gestiones del contrato
• Generar el correcto archivo de registros y documentos para reclamos futuros.

Triple Restricción: El costo, el tiempo y el

alcance
Otro aspecto de relevante importancia es el hecho de que el Administrador de Proyecto tiene
la importante misión de cuidar y balancear la “triple restricción”.

Llamamos triple restricción a las tres dimensiones básicas en torno de las cuales gira el
proyecto: Alcance, Tiempo y Costo.

Claramente una mejora en una de las tres dimensiones perjudica alguna de las otras, por lo
que será función del Director de Proyecto tomar las decisiones apropiadas en función de las
necesidades del proyecto y las expectativas de los stakeholders.
La triple restricción de un proyecto esta compuesta por:

 La restricción de coste, que se refiere a la cantidad presupuestada necesaria para alcanzar

los objetivos del proyecto.
 La restricción de tiempo, que se refiere a la cantidad de tiempo que disponemos para
completar un proyecto.
 La restricción de alcance, que se refiere a lo que se debe hacer para producir el resultado
final del proyecto.

 ▪ Organizaciones funcionales, en las que el personal está estructurado atendiendo

al principio de la especialización, es decir según sus conocimientos en unidades
funcionales que actúan de forma independiente del resto, con un superior al que
deben responder e informar.
 ▪ Organizaciones proyectizadas, donde la empresa se estructura en grupos
multidisciplinares que tienen plena responsabilidad sobre un proyecto concreto.
Estos grupos son dirigidos por un director de proyecto y su morfología cambia en
función de la cantidad y tipología de proyectos.
  ▪ Organizaciones matriciales. Representan un híbrido entre las dos estructuras
anteriores ya que ambas se superponen para dar lugar a una tercera en la que cada
individuo depende de dos superiores: el director del proyecto en el que participa y
el director del departamento (área funcional) en el que se encuentra. Si la
dependencia del primero es mayor se habla de estructura matricial fuerte y en caso
contrario de estructura matricial débil.

ISO 9000
ISO 9000 es una Norma con un conjunto de estándares internacionales que se pueden
utilizar en
el desarrollo de un sistema de gestión de calidad de todas las industrias, pudiéndose
aplicar tanto
a las organizaciones manufactureras como a las de servicios.
ISO 9001 es el estándar más general y se aplica al proceso de calidad de diseño,
desarrollo y
mantenimiento de productos. Hay documentos que interpretan ISO 9001 y ayudan a
entender
mejor la norma, como lo es ISO 9000-3, para el desarrollo de software.
ISO 9001 no es un estándar específico para el desarrollo de software, pero sus
principios son
generales por lo que pueden aplicarse a este, ya que describe aspectos del proceso
de calidad,
estándares y procedimientos, todo debe documentarse en un manual de calidad
organizacional.
En cuanto a los procesos, incluido el de desarrollo de software, debe incluir una
descripción de la
documentación requerida, entre ellos el documento de Especificación de
Requerimientos de
Software, ERS, donde se demuestra que el proceso definido se ha seguido por cada
requerimiento.
¿Qué es y qué no es ISO 9001:2000?
No es un texto de ley.
No es un texto que imponga los medios aplicables para el cumplimiento de sus
requisitos.
No es un texto que exija la implantación de un sistema documental complejo y
difícil de
gestionar.
Es un instrumento de adhesión voluntaria.
Es un texto aplicable a cualquier tipo de organización independientemente de cual
sea su
tamaño y su grado de implantación en el mundo.
Es un texto que exige compromisos.
Objeto
ESPECIFICAR los requisitos de un Sistema de Gestión de la Calidad, cuando una
organización:
Necesita demostrar su capacidad para proporcionar de forma coherente
productos/servicios que satisfagan los requisitos del CLIENTE y los reglamentarios
aplicables.
Aspira a aumentar la satisfacción del CLIENTE a través de la aplicación eficaz del
sistema.
Requisitos
Sistema de gestión de la calidad.
Posee requisitos generales.
Establece los requisitos de la documentación, que son:

o Generalidades

o Manual de la calidad
o Control de los documentos
o Control de los registros
Otros requisitos importantes a destacar de la norma son: MEDICIÓN, ANÁLISIS Y
MEJORA
No se puede mejorar lo que no se puede medir, por lo que es necesario identificar los
indicadores
del proceso que luego de hacer un análisis de los resultados se puede establecer una
mejora.
Los aspectos claves se pueden representar en la siguiente figura:

Su enfoque basado en procesos presenta cuatro pasos fundamentales:

Identificar los procesos.
Determinar su secuencia e iteración.
Establecer criterios para controlarlos
Realizar seguimiento, medición y análisis

Para lograr la Mejora continua.

Auditor: Es un profesional que hace un informe sobre un estado o situación y da su opinión

pero no una solución.

Consultor: Evalúa una situación y propone una solución. Puede no ser profesional.
Aconsejan como usar las TI.

Perito: Profesional que da una opinión sobre algo en un tema legal.

¿Estás pensando en implementar un SGC ISO 9001? ¿Quieres conocer cómo

es el proceso de implementación? Desde Quara Group proponemos a las
organizaciones los siguientes pasos para implementar y certificar un Sistema de
Gestión de Calidad ISO 9001:

Paso 1 - Diagnóstico y Planificación:

La primera etapa es realizar un diagnóstico para conocer cuál es el grado de

cumplimiento que tiene la organización con los requisitos de la norma ISO
9001:2015, a partir del mismo trazar un plan de trabajo, donde se detallan las
actividades, con sus plazos y responsables, que se llevarán a cabo a lo largo del
proyecto.

Paso 2 - Diseño del SGC:

En esta etapa se definen los elementos clave del Sistema de Gestión de la Calidad
(SGC) y se establece el soporte documental del Sistema.

Paso 3 - Implementación del SGC:

A medida que el SGC se diseña, se van implementando las metodologías y

registros en todos los procesos y áreas funcionales dentro del alcance definido.

Paso 4 - Auditoria interna:

Luego que se haya implementado el SGC en la organización, se llevará a cabo la

realización de la auditoría interna de todo el SGC, con el objetivo de determinar si
el Sistema de Gestión de la Calidad cumple los requisitos de ISO 9001:2015 y se
aplica de manera consistente en todo el proceso involucrado.

Paso 5 - Certificación:

Una vez que se haya verificado que el SGC cumpla con los requisitos de la norma
ISO 9001:2015 y se encuentre en funcionamiento en la organización, ésta se pone
en contacto con algún organismo de certificación para comenzar con el proceso de
certificación.

Después de conseguir la Certificación ISO 9001 es necesario su mantenimiento.

Como hemos apuntado al principio, este certificado se puede utilizar para mostrar
al público y generar publicidad positiva ya que pone en conocimiento la calidad de
sus productos y/o servicios.