REPÚBLICA BOLIVARIANA DE VENEZUELA

UNIVERSIDAD SANTA MARÍA

DECANATO DE POSTGRADO

GERENCIA Y TECNOLOGÍA DE LA INFORMACIÓN

TECNOLOGÍA DE LA INFORMACIÓN

Resumen de los temas estudiados en la asignatura

Alumno: José Chacón

Junio 2015

¿Cómo y por qué nacen las metodologías de gestión de proyectos?

Si definimos proyecto como el conjunto de actividades interrelacionadas que tienen como objetivo final

conseguir un determinado resultado, en un periodo de tiempo previamente definido y con una asignación de

recursos, nos damos cuenta que en su desarrollo intervienen tres elementos: personas, procesos y tecnología

o herramientas. Por lo tanto, lo primero que tenemos que hacer es organizarlos para conseguir alcanzar una

correcta coordinación entre ellos.

Las metodologías de gestión de proyectos comenzaron a gestarse en los años 50, en el ejército

estadounidense, para intentar reducir el volumen de proyectos que se descontrolaban y ayudar a solventar

problemas comunes que se habían identificado relativos a:

Exceso de carga de trabajo planificada o en proceso.

Costes que superan el presupuesto inicial.

Problemas en la calidad, valor o utilidad del resultado final.

La gestión de proyectos puede ser predictiva o ágil. Como en toda disciplina, existen defensores de una y de

otra.

La decisión final de cuál elegir dependerá de varios factores, sin embargo, uno de los más importantes es la

prioridad final para el proyecto. Mientras que la metodología predictiva le otorga más importancia a los

procesos, los métodos ágiles consideran que el valor o utilidad final del resultado que se quiere obtener es lo

más importante.

La Gestión de Proyectos Predictiva

Esta metodología también se conoce con el nombre de clásica, tradicional o formal. Se asienta bajo las

siguientes premisas:

Estabilidad del entorno: Considera que todos los proyectos tienen características y

comportamientos regulares, guiados por un patrón, desarrollados en un entorno estático y predecible.

Carácter predictivo: En el sentido de que se define al detalle el resultado que se quiere

conseguir. Lo importante son los procesos, no el valor final del producto, de

forma que los esfuerzos se orientan a cumplir en términos de tiempo, costes y recursos.

Siendo sus principales valores la planificación y el control.

Su lema es que la forma más eficiente de desarrollar un trabajo es hacerlo bien a la primera. Esto sólo es

posible si se puede conocer al detalle el resultado que se quiere obtener y se trabaja en un entorno estable.

PMBok y Prince2 son ejemplos de este tipo de metodologías.

¿Qué es una Matriz de Evaluación de Software?

ESTA MATRIZ DE EVALUACIÓN DE SOFTWARE SE BASA EN EL MODELO ISO/IEC 9126: El estándar ISO/IEC 9126 ha sido desarrollado en un intento de identificar los atributos clave de calidad para un producto de software (Pressman, 2002). Este estándar es una simplificación del Modelo de McCall (Losavio et al., 2003), e identifica seis características básicas de calidad que pueden estar presentes en cualquier producto de software. El estándar provee una descomposición de las características en subcaracterísticas. CRITERIOS DE EVALUACIÓN DEL SOFTWARE SELECCIONADOS: ISO/IEC 9126 adaptado para arquitecturas de software: La adaptación del modelo ISO/IEC 9126 de calidad de software para efectos de la evaluación de arquitecturas de software. El modelo se basa en los atributos de calidad que se relacionan directamente con la arquitectura: funcionalidad, confiabilidad, eficiencia, mantenibilidad y portabilidad. Los autores plantean que la característica usabilidad propuesta por el modelo ISO/IEC9126 puede ser refinada para obtener atributos que se relacionan con los componentes de la interfaz con el usuario. Dado que estos componentes son independientes de la arquitectura, no son considerados en la adaptación del modelo. ASPECTOS A EVALUAR: 1. FUNCIONALIDAD: Conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades específicas. Las funciones son aquellas que satisfacen lo indicado o implica necesidades. Las sub-características son: Adecuación, Exactitud, Interoperabilidad y Seguridad.

2. FIABILIDAD: Capacidad de un sistema para mantener su nivel de rendimiento. Es un Conjunto de atributos

relacionados con la capacidad del software de mantener su nivel de prestación bajo las condiciones

establecidas durante un período de tiempo establecido.

Las sub-características son: Recuperabilidad y Tolerancia a fallas.

3. EFICIENCIA: Es un conjunto de atributos que se refieren a las relaciones entre el nivel de rendimiento del

software y la cantidad de recursos utilizados bajo unas condiciones predefinidas. Las sub-características son:

Desempeño y utilización de recursos.

4. MANTENIBILIDAD: Es el esfuerzo necesario para realizar modificaciones específicas. Es un conjunto de

atributos relacionado con la facilidad de extender, modificar o corregir errores un sistema software. Las sub-

características de la facilidad de mantenimiento son: Acoplamiento y Modularidad.

5. PORTABILIDAD: Es la capacidad de un sistema para ser transferido de un entorno a otro. Es un conjunto

de atributos relacionados con la capacidad de un sistema software ara ser transferido desde la plataforma a

otra las sub-características de la portabilidad son: Adaptabilidad, instalabilidad, coexistencia y

Reemplazabilidad.

Este estándar no proporciona métricas ni métodos de medición, por lo que no son prácticas las mediciones

directas de las características de calidad.

Para resolver este problema se revisó la ISO 9126 y se incluyó un nuevo modelo de calidad que distingue entre

tres aproximaciones a la calidad de producto en ISO 14598, a saber:

·Calidad Interna: Se mide por las propiedades estáticas del código, utilizando técnicas de inspección

·Calidad externa: Se mide por las propiedades dinámicas del código cuando éste se ejecuta

·Calidad en uso: Se mide por el grado por el cual el software está realizado en función de las necesidades del

usuario en el entorno de trabajo para el que fue construido. Estas se dividen es sub características

productividad, seguridad y satisfacción.

Finalmente tras haber analizado los aspectos que consideramos necesarios para realizar la evaluación de un

software de manera objetiva, la matriz de evaluación a la que se llego es la siguiente:

No obstante lo anterior, para que una empresa apruebe la adquisición de un software, el costo

debe “aprobar” el análisis financiero, dos parámetros muy usados a la hora de calcular la viabilidad de un

proyecto son el VAN (Valor Actual Neto) y el TIR (Tasa Interna de Retorno). Ambos conceptos se basan en lo

mismo, y es la estimación de los flujos de caja que tenga la empresa (simplificando, ingresos menos gastos

netos).

Si tenemos un proyecto que requiere una inversión X y nos generará flujos de caja positivos Y a lo

largo de Z años, habrá un punto en el que recuperemos la inversión X. Pero claro, si en lugar de invertir el

dinero X en un proyecto empresarial lo hubiéramos invertido en un producto financiero, también tendríamos un

retorno de dicha inversión. Por lo tanto a los flujos de caja hay que recortarles una tasa de interés que

podríamos haber obtenido, es decir, actualizar los ingresos futuros a la fecha actual. Si a este valor le

descontamos la inversión inicial, tenemos el Valor Actual Neto del proyecto.

Si por ejemplo hacemos una estimación de los ingresos de nuestra empresa durante cinco años,

para que el proyecto sea rentable el VAN tendrá que ser superior a cero, lo que significará que recuperaremos

la inversión inicial y tendremos más capital que si lo hubiéramos puesto a renta fija.

La fórmula para el cálculo del VAN es la siguiente, donde I es la inversión, Qn es el flujo de caja del

año n, r la tasa de interés con la que estamos comparando y N el número de años de la inversión:

Otra forma de calcular lo mismo es mirar la Tasa Interna de Retorno, que sería el tipo de interés

en el que el VAN se hace cero. Si el TIR es alto, estamos ante un proyecto empresarial rentable, que supone

un retorno de la inversión equiparable a unos tipos de interés altos que posiblemente no se encuentren en el

mercado. Sin embargo, si el TIR es bajo, posiblemente podríamos encontrar otro destino para nuestro dinero.

Por supuesto que en la evaluación de un proyecto empresarial hay muchas otras cosas que

evaluar, como por ejemplo el tiempo que tardas en recuperar la inversión, el riesgo que tiene el proyecto,

análisis costo-beneficios… y tienen algunos problemas como son la verosimilitud de las predicciones de flujo

de caja. Pero el VAN y el TIR no dejan de ser un interesante punto de partida.

Herramientas de Gestión

Enterprise Resource Planning (ERP)

Como Gerentes en formación hemos visto que el acceso a la data, puede mejorar nuestras decisiones.

Actualmente un número cada más creciente de compañías están implementando un sistema de información a

gran escala llamado ERP, este tipo de herramientas recoge, procesa, y provee información sobre toda una

organización, incluyendo ordenes, diseño de productos, producción, compras, inventarios, distribución,

recursos humanos, cobranzas, y pronóstico de la demanda futura. Tal sistema vincula dichas áreas de

actividad, dentro de una red.

Dado el poder masivo de cómputo que se requería para correr un ERP, las primeras aplicaciones de un ERP,

eran solo para las más grandes compañías, con poderosas computadoras, pero actualmente en el mercado

existen ERP’s para PYMES.

Esquema de un ERP