15

CAPÍTULO II

MARCO TEÓRICO 1. ANTECEDENTES DE LA INVESTIGACIÓN En estasección habrán de estudiarse proyectos de investigación de

diferentes autores. Estas investigaciones ya fueron sometidas con

anterioridad a los respectivos procesos de evaluación metodológicos y

académicos, lo cual asegura su validez para ser utilizados como

antecedentes, ya que sus contenidos inciden de una u otra forma con las

variables de estudio.

En primera instancia, se presenta a Pérez, C. (2008), quien planteó un

proyecto de investigación titulado “Modelo gerencial para proyectos de

servicio y mantenimiento en empresas del sector petrolero en la región

zuliana”. Esta investigación tuvo como propósito el diseño de un modelo

gerencial para proyectos de mantenimiento en empresas de servicios del

sector petrolero en la región zuliana. La problemática planteada surge de la

importancia de precisar un modelo que proporcione pautas generales sobre

la secuencia de pasos a seguir para la toma de decisiones en la fase de

planificación, organización, dirección y control para llevar a cabo procesos

eficientes y eficaces durante la realización del proyecto de mantenimiento .

16

Tomando en consideración teorías referidas a la planificación estratégica,

matriz FODA, herramientas de confiabilidad operacional, parámetros

operacionales de mantenimiento. Se procedió a operacionalizar la variable

objeto de estudio, en función de diseñar una encuesta como técnica de

recolección de datos.

Continuado con su descripción, la investigación según su finalidad fue de tipo

descriptiva, de campo, documental y proyecto factible. En esta investigación

se recomendó el empleo de un modelo gerencial con el fin de mejorar la

ejecución de los procesos, no solo de planificación y control, si no también de

organización, dirección e integración, ya que fue diseñada tomando en

cuenta las características fundamentales de los proyectos de servicio y

mantenimiento.

En lo concerniente a sus semejanzas con la presente investigación, Pérez

(2008) igualmente propone un modelo gerencial dentro de las empresas del

sector petrolero occidental para proyectos con sus respectivas fases de

planificación, organización, dirección y control, sin embargo, se diferencia en

el tipo de proyecto al estar dirigido a proyectos de servicios y mantenimientos

a equipos mecánicos de procesamiento de crudo.

Esta investigación sirvió como complemento y guía para la estructuración

de una parte del marco teórico del proyecto que se plantea, específicamente

en lo que respecta al estudio de la variable modelo gerencial, la cual forma

parte indispensable del sistema de variables y su estudio es fundamental

para el cumplimiento de los objetivos planteados.

17

Otra investigación que sirvió de soporte, fue la de Ferré Grau, J. (2008)

denominado “Marco de Integración de la Usabilidad en Proyectos de

Ingeniería de Software”. Tuvo como objetivo ayudar a los ingenieros de

software a seleccionar las técnicas y actividades IPO (Integración Persona-

Computador) más apropiadas para integrar en su proceso de desarrollo de

proyectos de ingeniería de software, de modo que se trate adecuadamente la

usabilidad del producto software. El marco propuesto permite al ingeniero en

computación o fabricante de software acceder a una selección de las 35

técnicas Interacción Persona-Ordenador mejor dotadas para su integración

en el proceso de una organización con escasa o nula experiencia previa en

el tratamiento de la usabilidad.

Ahora bien, este trabajo de investigación se relaciona con la presente ya

que en este se desarrolló un marco de integración para proyectos de

ingeniería de software, contribuyendo así en el apartado de las bases

teóricas referente al ciclo de vida de los proyectos de ingeniería de software.

Por otro lado, se diferencian en que este se propone un marco para

complementar un proceso en particular, mientras que la presente es un

modelo gerencial el cual abarca en su totalidad los procesos necesarios para

fabricar un software.

También se seleccionó a Carrillo , F. (2009), quien planteó un proyecto de

investigación titulado “Marco de Trabajo para Proyectos de Ingeniería de

Software para Web Ubicuas y con Voz”,cuyo objetivo principal fue proponer

un Framework, entendido como un marco de trabajo genérico, que sirva

18

como guía para el desarrollo de proyectos de ingeniería de software en

plataforma web de uso cotidianocon acceso a sus resultados desde múltiples

dispositivos, evitando el desarrollo de un portal por cada uno, reutilizando

código fuente, y teniendo en cuenta las grandes variaciones pueden existir

en sus capacidades.

Continuado con su descripción, la investigación según su finalidad fue de

tipo descriptiva y proyectiva. El desarrollo del Sistema se sustentó en la

metodología establecida por Anderson, C. (2000), cumplidas en cinco fases.

Para el desarrollo físico del sistema se seleccionó la herramienta de

programación PHP 4.6, para el manejo de Bases de Datos MySQL 4.0.16,

para el diseño de las pantallas Dreamweaver MX y como servidor web

Apache Foundation 1.3.3.1.

Al igual que la presente investigación, Carrillo (2009) aborda la variable de

estudio proyectos de ingeniería de software, proponiendo un marco de

trabajo a ser implantado en los proyectos especializados en sistemas de

comunicación web en tiempo real, diferenciándose en la herramienta a

diseñar así como el contexto, siendo en esté un marco de trabajo

generalizado en vez de un modelo gerencial para empresas petroleras.

Esta investigación sirvió como complemento y guía para la estructuración

de una parte del esquema teórico de la investigación que se plantea,

específicamente en lo que respecta al estudio de la variable proyectos de

ingeniería de software, estableciéndose como parte indispensable del

19

sistema de variables y su estudio es vital para el cumplimiento de los

objetivos a alcanzar.

Por otro lado, se presenta a González, D. (2008), cuya investigación tuvo

como título “Modelo gerencial por valores para equipos de trabajo de

proyectos en empresas de ingeniería del Estado Zulia”.El propósito de esta

investigación fue proponer un modelo gerencial por valores para equipos de

trabajo de proyectos en empresas de ingeniería del Estado Zulia. Fue de tipo

descriptiva, proyecto factible con un diseño de campo, no experimental,

transeccional descriptiva.

La población estuvo conformada por un censo poblacional de treinta y tres

(33) individuos de los equipos de trabajo de las empresas de ingeniería

dedicadas a proyectos. Para la recolección de datos se diseño un

instrumento tipo encuesta, conformado por ochenta (80) ítems dicotómicos y

validado por cinco (5) expertos. Los resultados determinaron la necesidad de

un modelo gerencial para la ejecución de proyectos de inversión pública en

las empresas consultoras del estado Zulia.

Como puede observarse, la investigación también trata un modelo

gerencial como un objeto de estudio, diferenciándose en los tipos de

proyectos y su contexto al ser los dos generalizados, y es así como a través

de la fase de definición expuesta por González, D. (2008), se logró

complementar el esquema que forma las bases teóricas del proyecto

presente, específicamente lo relacionado con los indicadores para

diagnosticar la situación actual de un proyecto .

20

Continuando con la variable de estudio, se presenta a Álvarez, A. (2009),

cuya investigación tuvo como título “Desarrollo de Proyectos de Ingeniería de

Software para Sistemas de Tiempo Real Basado en UML: Un Enfoque

Formal Basado en Metamodelado”.

El propósito de esta investigación fue proponer una metodología de

desarrollo de sistemas de tiempo real dentro de los proyectos de ingeniería

de software que hace un énfasis especial en la consideración de los

requisitos no funcionales característicos de este tipo de sistema como los

requisitos temporales, la concurrencia, la asignación de prioridades o la

interacción con dispositivos físicos. La metodología toma elementos de otras

ya existentes, como SOMT y OCTOPUS,proponiendo mecanismos propios

para solventar parcialmente problemas como el paso del modelo de objetos

al modelo de proceso y la asignación de prioridades.

Como puede observarse, también trata el desarrollo de proyectos de

ingeniería de software dentro de su sistema de variables, sin embargo, difiere

de la presente ya que se enfoca en fase de control del proyecto más que en

ver a la foto completa abordando todos los aspectos gerenciales del

proyecto.Mediante la fase de definición expuesta por Álvarez, A. (2009), se

complementa el sistema de variables de la presente investigación en el

apartado de las características de un proyecto de ingeniería de software.

Otro estudio que sirvió como antecedente, fue el de Villalobos, N.(2009)

denominado “Modelo gerencial para la ejecución de proyectos de inversión

pública en las empresas consultoras del Estado Zulia”, tuvo como objetivo el

21

diseño de un modelo gerencial o de gestión para la ejecución de proyectos

de inversión pública en las empresas consultoras del estado Zulia. De la

situación problema planteado surge la importancia de crear un modelo que

brinde pautas en la gestión de proyectos involucrando actividades como

definición de alcance, programa de proyecto, administración de costos,

supervisión, control y aseguramiento de la calidad engranada a la

planificación, organización, dirección y control.

La investigación se tipificó de carácter descriptiva, de campo y documental,

modalidad proyecto factible partiendo de un diseño no experimental

transeccional. Se utilizó como técnica de instrumentos para la recolección de

datos en primer lugar la encuesta con la aplicación del cuestionario

direccionado hacia ambos estratos.

Este trabajo de investigación se relaciona con la presente ya que en este

se desarrollómodelo gerencial para proyectos en las empresas del estado

Zulia. Por otro lado, se diferencian en que este modelo esta enfocado hacia

proyectos de inversión publica en el área de construcción civil, mientras que

el de la presente investigación es netamente para proyectos de ingeniería de

software.

Para concluir, se presenta a Martínez, E.(2010), presentando su trabajo de

grado titulado “Modelo gerencial para la fase de ejecución de proyectos de

telecomunicaciones en el Occidente de Venezuela”. Esta investigación tuvo

como propósito proponer un modelo gerencial para la fase de ejecución de

22

proyectos de telecomunicaciones, fundamentándose en las teorías de

Chamoun (2002), Cleland (2001), Cartay (1998) y Koontz (2004), entre otros.

En relación al tipo de investigación, fue proyectiva con un diseño de

campo y transeccional. Para recolectar la información necesaria fue aplicado

un censo poblacional conformado por veintidós (22) gerentes generales,

operacionales y departamentales de empresas de telecomunicaciones

ubicadas en el Estado Zulia, a quienes se les aplico una encuesta

estructurada con ochenta y dos (82) ítems validados por cinco (5) expertos.

El resultado de la investigación indico que existe un bajo nivel de desarrollo

de actividades en las etapas de proyectos de telecomunicaciones.

Se utiliza como referencia para el presente estudio, al tener un objetivo

similar donde se pretendió diseñar un modelo gerencial; siendo en este caso

es para proyectos de telecomunicaciones, mientras en la presente

investigación son proyectos de ingeniería de software, sin embargo, vale

destacar que ambas son proyectos industriales de tecnología .

2. BASES TEÓRICAS Las bases teóricas son el conjunto de teorías o demás fundamentos

conceptuales que sustentan la investigación. Para esta investigación se

tomará como base teórica los puntos claves que permitan un óptimo diseño

de un modelo gerencial para proyectos de ingeniería de software, pues en la

misma estará plasmada desde el concepto básico de un modelo

23

gerencialhasta los principales indicadores que presentan los proyectos de

softwarepara llevar a cabo su planificación y control.

2.1. MODELO GERENCIAL Según lo planteado por Olivé (2007) se entiende por modelo la construcción

simplificada de la realidad o un aspecto de ella, bien sea de la existente o de

la que se aspira alcanzar. Esta construcción se efectúa identificando los

diferentes componentes de aquella realidad y sus relaciones reciprocas. Solo

se identificaran componentes considerados prioritarios o particularmente

útiles o pertinentes a los fines que se empleara el modelo.

La clasificación de los modelos la expresa Olivé (2007) en dos tipos:

Modelos Cuantitativos: son aquellos que expresan en detalle las variables,

con la ayuda de formulas y ecuaciones matemáticas.

Modelos Cualitativos: son aquellos que pretenden explicar con mayor o

menor grado de especificidad las relaciones reciprocas entre distintos

componentes o conceptos.

El empleo de los modelos es solo un medio, es uno de los tantos

instrumentos utilizados para la investigación y el análisis de una realidad o

fenómeno, es decir, es un instrumento de apoyo para cualquier metodología

entendiendo por tal, la forma lógica de entender o de explorar una realidad,

fenómeno o todo tipo de manifestación.

Los modelos pueden ayudar a cumplir los siguientes propósitos:

24

(a) Describir la realidad o un aspecto de ella en función de sus componentes

y relaciones que sean prioritarios o fundamentales.

(b) Diagnosticar o evaluar la realidad en términos de sus componentes y

relaciones igualmente considerando como prioritario.

(c) Predecir el comportamiento de la realidad que se analiza proyectándolo

hacia el futuro.

(d) Normar o predecir la realidad para tomar acciones adecuadas según la

situación presentada.

Ampliando la teoría sobre modelos, Crosby (2000) lo define como una

conceptualización de un evento, un proyecto, una hipótesis, el estado de un

objeto, el cual se representa como un esquema con símbolos descriptivos de

características y relaciones mas importantes con un solo fin, ser sometido a

modelización como un diseño flexible, emergiendo y desarrollándose durante

el inicio de la investigación como una evaluación de su relevancia. Por su

parte, David (2002) señala que el modelo constituye un conjunto de objetos y

sus relaciones, el cual describe la realidad, en particular, si permite hacer

pronósticos o predicciones y, la emulación, representación en miniatura.

De lo planteado tanto por Olivé (2007), Crosby (2000) y David (2002), se

observan diferentes similitudes, la mas resaltante siendo en que los modelos

parten desde una realidad o fenómeno físico el cual trata de ser descrito para

prever su comportamiento a un futuro. Como síntesis, se puede definir un

modelo con la deconstrucción de un aspecto de la realidad con el objetivo de

plasmar en un conjunto de objetos la forma en como se relacionan para

25

alcanzar determinada meta, brindando de esa manera medios para realizar

pronósticos y llevar a cabo simulaciones.

Por otro lado, la gerencia para Drudis(2002), es el proceso de diseñar y

mantener un medio ambiente en el cual los individuos que trabajan en grupos

logren eficientemente los objetivos seleccionados, este medio ambiente debe

servir para lograr metas de grupo en el menor tiempo posible, con menos

dinero, materiales e insatisfacción personal, o donde puedan alcanzar lo mas

posible de una meta con los recursos disponibles.

De manera muy similar, Anzola (2002) define la gerencia como el conjunto

de actividades que se emprenden para coordinar el esfuerzo de un grupo, es

decir, la manera en la cual se trata de alcanzar las metas u objetivos con la

ayuda de las personas y otros recursos mediante la planeación, la

organización, la dirección y el control.

Comparando lo expuestos por los autores, para Drudis (2002) el proceso

de la gerencia se enfoca más la creación de un ambiente en donde los

distintos componentes de una organización alcancen sus objetivos de forma

individual, y por consiguiente, eventualmente el de la organización. Mientras

que para Anzola (2002), los esfuerzos de la gerencia deben estar dirigidos a

ejecutar el conjunto de actividades necesarias para alcanzar los objetivos del

proyecto como tal.

Se puede entender por gerencia entonces, el proceso que busca crear un

ambiente propicio para la ejecución de las actividades y gestión de los

recursos necesarios para alcanzar los objetivos de una organización o

26

proyecto, administrándolos siempre de la forma más eficiente mediante los

subprocesos de planificación, organización, dirección y control.

De los conceptos expuestos anteriormente, se puede concluir que un

modelo gerencial es un esquema el cual permite dirigir, administrar y

representar unproyecto u organización para alcanzar sus objetivos. Muchas

han sido las técnicas gerenciales desarrolladas en los últimos años con el

deseo de dar respuesta y solución a los diferentes problemas enfrentados

por las organizaciones en el dividir de sus actividades y una de las

principales dificultades presentadas por los estudios de las ciencias

gerenciales es el alcance limitado de sus modelos y enfoques ante las

variadas situaciones presentes en el mundo real.

La tarea actual de los gerenteses según Cartay(1998) interpretar los

objetivos propuestos para el proyecto u organización y transformarlos en

acción organizacional a través de la planificación, la organización, la

dirección y el control de todos los esfuerzos realizados en todas las áreas y

niveles de la organización con el fin de alcanzar tales objetivos de la manera

mas adecuada a la situación. A manera de detalle se describe cada uno de

estos procesos.

Para la planificación, Jiménez(2000) lo define como el proceso

administrativo de escoger y realizar los mejores métodos para satisfacer las

determinadas políticas y lograr los objetivos, dicho en otros términos es

entender el objetivo, evaluar las situaciones y considerar diferentes acciones

para concluir lo anteriormente mencionado de forma exitosa.

27

Ahora bien, para Anzola (2002) la planificación para una organización se

realiza mediante un conjunto de procesos, coherentes y relacionados como

lo son: Establecer una o varias metas; Definir la situación actual; Identificar

las ayudas y los obstáculos de las metas; Desarrollar un plan o los medios de

acción para alcanzar las metas; Establecer el plan como una serie de

actividades secuenciales; Indicar el sistema que evaluara y controlara el

logro de los objetivos y resultados concretos.

En lo referente a la organización, Anzola (2002) se refiere a esta como el

proceso en que se dispone el trabajo y se asigna entre el personal de la

empresa para alcanzar eficientemente los objetivos de la misma. De igual

manera Daft(2004)la define como el proceso de ordenar los esfuerzos y crear

una estructura adecuada de acuerdo a los objetivos de la organización.

Tanto para Anzola (2002) como para Daft (2004), los pasos que conllevan a

la organización se pueden enumerar como: Detalle del trabajo; División del

trabajo; Combinación de tareas; Coordinación del trabajo; Seguimiento y

reorganización.

En el apartado de la dirección, Daft(2004) al respecto comenta que se

aplica cuando se estructura una empresa con el fin de constituir el conjunto

de unidades, estableciendo los distintos niveles de autoridad,

responsabilidad, así como determinando las atribuciones y obligaciones del

conjunto de unidades, se produce una división del trabajo que obliga a una

asignación de este en forma separada a cada una de las unidades creadas.

En consecuencia, es necesario un proceso integrado, armonizando las

28

partes para formar un todo orgánico, asu vez dinámico, mediante el ajuste de

las diferentes partes y acciones que forman la organización.

Según lo establecido anteriormente, la dirección es uno de los procesos

más importantes dentro de la organización: no se concibe la ejecución de un

plan sin coordinación, no es posible la utilización racional de los medios y la

obtención de fines y objetivos sin la aplicación de este proceso.

Para finalizar, tenemos el aspecto del control el cual es uno de los más

difíciles de ejecutar. Son el control y la valoración aspectos determinantes si

las cosas se están haciendo tal como se planifico y si se esta cumpliendo

con lo previsto. Es por esto que Daft(2004) expone que consiste en verificar

si todo se realiza conforme al programa adoptado, las ordenes impartidas y a

los principios administrativos, tiene la finalidad de señalar las faltas y los

errores, a fin de poder separarlos y evitar su repetición.

De esta manera, explica Anzola (2002) la necesidad de que el gerente

reconozca el control como un proceso el cual selleva a cabo de manera

precisa y adecuada, es así como los pasos del mismo dan forma a un

proceso lógico: Establecer estándares o patrones; Aplicación de los

estándares o patrones; Comparación del estándar y lo real.

A manera de contraste, queda demostrado que tanto Cartay (1998),

Jiménez (2000), Daft (2004) y Anzola (2002) coinciden en las fases

esenciales las cuales debe contemplar el proceso de la gerencia son la

planificación, organización, dirección y control, además de

29

coincidirampliamente en la descripción y la forma en como se debe llevar a

cabo la implementación de cada una de estas.

En relación a lo anterior, las anteriores fases de la gerencia descritas por

diferentes autores constituyen una base fundamental para la presente

investigación, tal es el caso que son utilizadas para la operacionalización de

la variable de estudio.

2.2. PROYECTOS DE INGENIERÍA DE SOFTWARE Para Pressman (2005) un proyecto de ingeniería de software es una

planificación que consiste en un conjunto de actividades secuenciales,

interrelacionadas y coordinadas siendo su objetivo o resultado final

unproducto de software; la razón de un proyecto es alcanzar estos objetivos

específicos dentro de los límites impuestos por un presupuesto, calidades

establecidas previamente y un lapso de tiempo previamente definidos.

De manera comparativa para Senn (2003) un proyecto de ingeniería de

software es un emprendimiento teniendo lugar durante un tiempo limitado, y

que apunta a lograr un resultado único. Surge como respuesta a una

necesidad, acorde con la visión de la organización, aunque ésta puede

desviarse en función del interés. El proyecto finaliza cuando se obtiene el

resultado deseado, desaparece la necesidad inicial, o se agotan los recursos

disponibles durante su ejecución.

Se puede observar que los autores coinciden ampliamente en la definición

de proyectos de ingeniería de software, enfocándose en la definición general

30

de proyecto donde una serie de actividades se realizan para alcanzar un

objetivo, sin embargo, Pressman (2005) hace énfasis en la diferencia de los

proyectos de ingeniería de software con el resto, es decir, su producto o

resultado de connotación lógica no palpable de forma física constituye una

gran diferencia con los proyectos industriales de infraestructura, vale

destacar que lo anterior no quiere decir que las inversiones en proyectos de

ingeniería de software no sean menores.

En base a lo anteriormente, se puede concluir que un proyecto de ingeniería

de software es un conjunto de actividades y recursos organizados mediante

un marco de trabajo especializado para el desarrollo de aplicaciones

teniendo como objetivo producir un sistema o componente de software para

dar solución a una necesidad de una comunidad u organización desde el

punto de vista tecnológico.

2.3. SITUACIÓN ACTUAL DE LOS PROYECTOS DEINGENIERÍA DE SOFTWARE En el siguiente apartado se expone información asociada al proceso de

ejecución y gestión de proyectos, proporcionando una marco de referencia a

este estudio investigativo, así como de apoyo sobre la identificación de los

procesos a emplear para la definición del alcance, costos, tiempo y calidad,

considerados elementos importantes a tomar en cuanta durante la ejecución

de cualquier proyecto, sirviendo para analizar la situación actual de la

gerencia asociada a los proyectos de ingeniería de software.

31

2.3.1. ALCANCE El Project Management Body of Knowledge (PMBOK) del Project

Management Institute (PMI) (2008) describe los procesos requeridos para

asegurar que el proyecto incluya todo el trabajo requerido, y solo el trabajo

requerido, a fin de completarlo exitosamente, consiste en la iniciación,

planificación del alcance, definición del alcance, verificación del alcance y

control de cambios en el alcance.

Continuando en el mismo orden de ideas, en lo referente a la planificación

del alcance, este recomienda desarrollar una declaración escrita del alcance

como base para futuras decisiones del proyecto. La planificación del alcance

del proyecto comienza con las entradas iniciales de la descripción del

producto, el permiso legal del proyecto y la definición inicial de las

restricciones y supuestos.

Ahora bien, para Cleland e Ireland (2001) en primera instancia se debe

comenzar con la definición del alcance en donde la tarea es subdividir las

principales prestaciones del proyecto en componentes más pequeños y

manejables, con el objeto de: mejorar la precisión en las estimaciones de

costo, duración y recursos, definir una base para la medición y control del

rendimiento / desempeño, facilitar las asignaciones de responsabilidades.

Seguidamente, este mismo autor recomienda la verificación del alcance para

formalizar la aceptación del alcance del proyecto, en este proceso se obtiene

la aceptación formal del esfuerzo a ejecutar por parte de los accionistas. Otro

32

punto a tener en cuenta son los controles de cambio del alcance, esto con el

fin de controlar los cambios en el alcance del proyecto, viéndose relacionado

con: influenciar los factores que crean cambios de alcance, asegurar

acuerdos de los cambios, determinar que se ha producido el cambio del

alcance, y manejar los cambios reales cuando ocurren.

Figura 1. Diagrama de Flujo para Definir Alcance del Proyecto. Fuente: PMBOK (2008) Se evidencia, de acuerdo al PMI (2008), que los procesos descritos

anteriormente interactúan entre si (ver figura 1) y con otros procesos en otras

áreas de conocimiento. Cada proceso puede implicar el esfuerzo de una o

mas personas, dependiendo de las necesidades del proyecto. De igual

forma, cada proceso se ejecuta por lo menos una vez en cada proyecto y en

una o mas fases del proyecto, en caso de que este se encuentre dividido por

33

etapas. En la practica estos procesos se superponen entre si mientras

interactúan unos con otros.

Según el Cartay (1998) el director del proyecto y los principales

participantes deben indicar el alcance del mismo con el mayor detalle

posible. Una técnica útil para fijar el alcance es reunir a las principales partes

interesadas en un ejercicio de tormenta de ideas buscando específicamente

describir que debe caer dentro del alcance del proyecto, es decir, el autor

hace énfasis en las actividades descritas dentro del alcance las cuales deben

ser solo las necesarias para cumplir con los objetivos del proyecto.

Se pueden contrastar lo expuesto por el Project Management Institute

(PMI) (2008) y Cartay (1998) en el sentido de que este ultimo recomienda

hacer una tormenta de ideas entre todas las partes involucradas dentro del

proyecto, mientras que el PMBOK establece un lineamiento mas

sistematizado en el proceso de definición del alcance mediante una serie de

pasos bien especificados.

Resumiendo, lo anterior se puedesintetizar en que la definición correcta del

alcance debe ser el primer paso firme dentro de cualquier proyecto. Mediante

una adecuada definición del alcance se ahorra en costos innecesarios al

evitar la ejecución de actividades inútiles y se asegura la satisfacción del

cliente al haber recabado adecuadamente sus necesidades y

requerimientos,todo esto aumentado considerablemente las probabilidades

de éxito del proyecto.

34

2.3.2 COSTO Para Cartay (1998), un presupuesto es la traducción de planes a gastos

medibles y rendimientos esperados en un determinado periodo. En este

sentido es el borrador financiero o el plano de acción, por cuanto se habla de

costos, el primer documento a revisar para verificar la salud financiera del

proyecto debe ser el presupuesto.

El Project Management Institute (2008) describe los procesos requeridos

para asegurar la ejecución total del proyecto dentro del presupuesto

aprobado. Donde se debe planificar los recursos, estimar los costos, preparar

presupuestos de costos y controlar estos mismos.

En primera instancia se describe la planificación de recursos en donde la

meta es determinar que recursos (personas, equipos, materiales) y en que

cantidades de cada uno se deben utilizar para desarrollar las actividades del

proyecto. Para lograr tal cometido es necesario que los distintos roles del

proyecto realicen una reunión multidisciplinaria para canalizar una tormenta

de ideas sobre este aspecto.

Continuando con lo estipulado por el PMI (2008) el siguiente paso es la

estimación de costos, donde el objetivo es desarrollar una aproximación de

los costos de los recursos necesarios para completar las actividades del

proyecto. Cuando se ejecuta un proyecto por medio de un contrato, se debe

tener cuidado al momento de distinguir entre estimación de costos y

apreciación. También se desarrolla una evaluación del resultado cuantitativo

35

probable - ¿Cuánto le costara ala organización ejecutante proveer el

producto o servicio involucrado? La apreciación es una decisión de negocios

- ¿Cuánto cobrara la organización ejecutante por el producto o servicio?

En tal sentido, para Cartay (1998) la secuencia lógica en el proceso de la

gerencia de los costos es el acto de presupuestar los mismos, en donde el

analista debe asignar la estimación de costos global a las actividades

individuales de trabajo, para realizar tal cometido, el analista de costos se

debe apoyar con el ingeniero elaborador de las especificaciones técnicas y

con los distintos proveedores que le facilitaran las listas de costos

actualizados. Este paso es critico y de el depende la asignación correcta de

los precios en las partidas las cuales pasaran a conformar el contrato de

servicios, documento el cual rige la ejecución física del proyecto.

En relación a lo anterior, se continúa con el control de costo donde el objetivo

es controlar los cambios al presupuesto del proyecto. El control del costo

incluye: monitorear el rendimiento de los costos para detectar y entender las

variaciones con respecto al plan, asegurar el registro de todos los cambios

correspondientes en forma exacta en la base de costos, evitar la inclusión en

la base de costos aquellos cambios incorrectos, inadecuados y no

autorizados, informar a los respectivos accionistas acerca de los cambios

autorizados, actuar para llevar los costos esperados dentro de limites

aceptables, tomar decisiones oportunas para asegurar el cumplimiento de los

planificado versus los real.De todos estos aspectos depende en gran medida

el éxito del proyecto .

36

Figura 2. Diagrama de Flujo para Estimación de Costos. Fuente: PMBOK (2008) Se evidencia, de acuerdo al PMI (2008), que los procesos descritos

anteriormente interactúan entre si (ver figura 2) y con otros procesos en otras

áreas de conocimiento. Cada proceso puede implicar el esfuerzo de una o

mas personas, dependiendo de las necesidades del proyecto. De igual

forma, cada proceso se ejecuta por lo menos una vez en cada proyecto y en

una o mas fases del proyecto, en caso de una división por etapas. En la

practica estos procesos se superponen entre si mientras interactúan y

complementan unos con otros.

Tanto para Cartay (1998) como el Project Management Institute (2000) el

presupuesto constituye la base mediante la cual se fundamentaran los costos

de un proyecto. La diferencia esta en que el primero establece que los

gastos deben ser los esperado según lo plasmado en el documento, mientras

37

que el PMBOK espera ligeras desviaciones en los costos y estable

mecanismos para justificarlos.

Según lo indicado por la teoría de los anteriores autores, la herramienta

habitualmente utilizada para controlar los costos, es la comparación

presupuestaria parcial (mes, trimestre, entre otros) y acumulada desde el

inicio del proyecto.

En este sentido, se puede suponer que fue suficientemente previsor como

para estructurar el plan de cuenta contables (para cuentas de costo), en base

al quiebre del proyecto difundido por ingeniería (al igual que el presupuesto

inicial), las comparaciones línea a línea deberían ser coherentes, excepto por

los desfases normales en el registro, ya sea del compromiso.

2.3.3. TIEMPO Según el PMI (2008) a través de los cronogramas de ejecución se describen

las actividades requeridas para asegurar el término a tiempo del proyecto.

Para formular un cronograma de ejecución debe haber una definición de

actividades, secuencia de las actividades, desarrollo del programa y control

del programa.

En base a lo anterior, se comienza por la definición de las actividades, donde

se persigue identificar las actividades específicas que se deben desarrollar a

fin de producir las distintas prestaciones del proyecto. La definición de las

actividades implica la identificación y documentación de las mismas que se

38

deberán ejecutar con el objeto de producir las prestaciones y

subprestaciones identificadas en la Estructura de División del Trabajo (EDT).

Para Cleland e Ireland (2001) también se debe tomar en cuenta la secuencia

de las actividades con el fin de identificar y documentar interactivamente las

relaciones de dependencia. Se deben secuenciar de manera exacta, a fin de

respaldar el posterior desarrollo de un programa realista y alcanzable.

En relación a lo anterior, se continúa hacia la estimación de la duración de

las actividades para estimar el número de periodos de trabajo que serán

necesarios para completar las actividades individuales. Las estimaciones son

elaboradas por la persona o grupo que este mas familiarizado con la

naturaleza de la actividad a llevar a cabo, o al menos aprobar la estimación.

También se hace el desarrollo del programa, esto para analizar las

secuencias de actividades, duraciones y requerimientos de recursos a fin de

crear el programa del proyecto.

Para Cartay (1998), se debe controlar los cambios al programa del proyecto.

El control del programa se relaciona con: cualquier cambio a influir en los

factores accionantes de eventos en el programa, de forma tal de asegurar

tales cambios sean convenidos, determinar el hecho de modificacióndel

programa, gestionar los cambios reales cuando y a medida que estos se

produzcan.

En el mismo orden de ideas, los diagramas Gantt proporcionan una útil

visualización de la situación del proyecto en cuanto tiempo se refiere, la

duración estimada del proyecto, las tareas y sus secuencias pero no reflejan

39

las dependencias subyacentes o el camino critico. Por su arte los gráficos

Pert y los diagramas de redes sirven para el mismo propósito de los

diagramas Gantt, pero si indican el camino critico y todas las dependencias

importantes de las tareas.

Figura 3. Diagrama de Flujo para Control del Tiempo. Fuente: PMBOK (2008) Se evidencia, de acuerdo al PMI (2008), que los procesos descritos

anteriormente interactúan entre si (ver figura3) y con otros procesos en otras

áreas de conocimiento. Cada proceso puede implicar el esfuerzo de una o

mas personas, dependiendo de las necesidades del establecidas

inicialmente. De igual forma, cada proceso se ejecuta por lo menos una vez y

40

en una o mas fases del proyecto, en caso de que este se encuentre dividido

por etapas. En la practica estos procesos se superponen entre si mientras

interactúan unos con otros.

Ahora bien, tanto Cartay (1998) como el Project Management Institute

(2008) establecen al cronograma como una herramienta fundamental para

controlar el tiempo dentro del proyecto, pero vale destacar en el este ultimo

se inclina hacia los diagramas Gantt, mientras que el primero indica que las

graficas Pert y los diagramas de red son los mas adecuados para la

representación de la actividades en una escala de tiempo.

En base a lo anterior se llega a la siguiente conclusión: el tiempo es una

excelente unidad de medida de la calidad de ejecucióndemostrando que

hubo previamente una fase de planificación precisa, siendo por esto uno de

los objetivos de las técnicas de planificación del tiempo, como la del camino

crítico,el aprovechamiento del mismo. Dichas técnicas proporcionan a la vez,

las herramientas de control necesarias, dirigiendo la atención sobre las

actividades criticas, quedando sometidas a control aquellas fases donde la

perdida de tiempo impactará negativamente la marcha de un proyecto.

2.3.4. CALIDAD Para Palacios (2004), la calidad es el proceso de monitoreo de las

variaciones en los parámetros de concretados en las especificaciones del

proyecto. La calidad conlleva a un control ejecutado en cuatro fases:

Prevención, que evita la aparición de errores; Inspección, para identificar las

41

variaciones no deseadas; Muestreo, para generar la información y detectar

anomalías que han excedido los niveles de tolerancia; y por ultimo

Corrección que implica trabajar en las causas de variaciones y elaborar

planes contra eso.

Adicionalmente, para el Project Management Institute (2008) en el PMBOK

se describen los procesos requeridos para asegurarse de que el proyecto

satisfará las necesidades para las cuales fue ejecutado, lo anterior se

desglosara en los siguientes apartados.

En primera instancia se debe considerar la planificación de la calidad en

donde el objetivo es identificar cuales son las normas de calidad relevantes

para el proyecto y determinar las formas de satisfacerlas, para alcanzar los

anterior se recomienda contar con la asesoría de expertos en el negocio, así

como expertos en las disciplinas y tecnologías que se utilizan para implantar

la solución o servicio puesto en marcha por el proyecto.

Posteriormente se debe considerar el aseguramiento de la calidad con el fin

de evaluar el rendimiento / desempeño global del proyecto en forma regular a

fin de tener la confianza de que el mismo satisfará las normas de calidad

relevantes. Este proceso debe desarrollarse durante todo el proyecto de

manera organizada y sistemática. Antes del desarrollo de las series ISO

9000, las actividades descritas en planificación de la calidad eran

ampliamente incluidas como parte del aseguramiento de la calidad.

Por otro lado, para Cartay (1998), recomienda llevar un control de calidad

para monitorear resultados específicos del proyecto con el objeto de

42

determinar si estos cumplen con las normas de calidad relevantes e

identificar las formas para eliminar las causas de rendimiento / desempeño

insatisfactorio. El equipo de gestión del proyecto debe contar con un

conocimiento practico del control estadístico de la calidad, especialmente en

muestreo y probabilidad, de modo tal de facilitar la evaluación de los

resultados, así como la toma de decisiones.

En el mismo orden de ideas, el aseguramiento de la calidad consiste en tener

y seguir un conjunto de acciones planificadas y sistemáticas, implantadas

dentro del Sistema de Calidad de la organización el cual es potenciado por

su propio departamento. Estas acciones deben ser demostrables para

proporcionar la confianza adecuada de que se cumplen los requisitos del

Sistema de la Calidad, se recomienda incluso que empiece a formar parte de

la cultura organizacional a fin de inculcar los lineamientos y los costos de la

calidad sean menores.

Por lo tanto, tiene que ver con la organización interna que ejerce la

determinación de los procesos productivos y de las características y

cualidades de los productos, y si bien implantar un adecuado sistema de

calidad puede resultar una de las tareas mas costosas dentro de un

proyecto, esta demostrado que en mediano o largo plazo la inversión se

recupera con creces, y queda como una valiosa experiencia para la

organización y sus integrantes.

43

Figura 4. Diagrama de Flujo para Aseguramiento de la Calidad. Fuente: PMBOK (2008) Se evidencia, de acuerdo al PMI (2008), que los procesos descritos

anteriormente interactúan entre si (ver figura 4) y con otros procesos en otras

áreas de conocimiento. Cada proceso puede implicar el esfuerzo de una o

mas personas, dependiendo de las necesidades del proyecto. De igual

forma, cada proceso se ejecuta por lo menos una vez en cada proyecto y en

una o mas fases del proyecto, en caso de que este se encuentre dividido por

etapas. En la practica estos procesos se superponen entre si mientras

interactúan unos con otros.

44

Realizando un contraste entre los dos puntos de vista anteriormente

expuestos, el PMBOK (2008) establece que un sistema de calidad se puede

implantar al momento de darse la iniciativa del proyecto, haciendo énfasis en

la naturaleza dinámica de los procesos, por otro lado, Cartay (1998)

recomienda tener un sistema de calidad ya implantado en la organización a

modo de hacer menos traumático el proceso total del aseguramiento de la

calidad para el personal del proyecto.

Utilizando como soporte la teoría sobre calidad ya expuesta, se puede

concluir que es de vital importancia que desde un principio hasta la

culminación del proyecto se implemente un adecuado sistema de calidad,

preferiblemente automatizado, en donde se identifiquen y se evalúen de

manera constante los productos de los diferentes procesos envueltos en la

ejecución del proyecto de ingeniería de software.

2.4. CARACTERÍSTICAS DE LOS PROYECTOS DE INGENIERÍA DE SOFTWARE A continuación se exponen la información asociada a las características

que pueden presentar los proyectos de ingeniería de software en el marco de

su ciclo de vida como esfuerzo y la plataforma tecnológica utilizada para

pasar a producción. Este apartado es de gran valor por brindar el

conocimiento necesario para identificar que hace los proyectos de ingeniería

de software tan particulares dentro de las empresas del sector petrolero

occidental.

45

2.4.1. TIPO DE LICENCIA Una de las características principales de todo proyecto de ingeniería de

software la constituye el tipo de licencia que será utilizada. Para Overly

(2004), una licencia de software es un contrato entre el licenciante o

autor/titular de los derechos de explotación/distribuidor y el licenciatario del

programa informático o usuario consumidor de la organización o negocio,

para utilizar el software cumpliendo una serie de términos y condiciones

establecidas dentro de sus cláusulas.

Por otra parte, Gordon (2008) expone que las licencias de software pueden

establecer entre otras cosas: la cesión de determinados derechos del

propietario al usuario final sobre una o varias copias del programa

informático, los límites en la responsabilidad por fallos, el plazo de cesión de

los derechos, el ámbito geográfico de validez del contrato e incluso pueden

establecer determinados compromisos del usuario final hacia el propietario,

tales como la no cesión del programa a terceros o la no reinstalación del

programa en equipos distintos al que se instaló originalmente.

Overly (2004) plantea que las licencias de software reciben una clasificación

según los derechos reservados por cada autor hacia su obra, siendo estas

clasificaciones las licencias de código cerrado o propietario, las licencias de

código abierto o software libre, y la licencia de dominio publico. El software

libre (en inglés free software, aunque esta denominación también se

confunde a veces con gratis por la ambigüedad del término en el idioma

46

inglés) es la denominación del software el cual respeta la libertad de los

usuarios sobre su producto adquirido y, por tanto, una vez obtenido puede

ser usado, copiado, estudiado, modificado y redistribuido libremente.

Por otro lado, el termino libre se refiere a la libertad de los usuarios para

ejecutar, copiar, distribuir, estudiar, modificar el software y distribuirlo

modificado. Existen diversas licencias de código abierto (ver cuadro 1), unas

menos restrictivas que otras.

Cuadro 1. Licencias de Código Abierto o Software Libre

Nombre Autor Versión Fecha de Publicación

Apache License Apache Software Foundation 2.0 2004

Common Public License IBM 1.0 Mayo de 2001

Creative Commons Licenses

Creative Commons 3.0

16 de Diciembre de 2002

GNU General Public License

Free Software Foundation 3.0 Junio de 2007

Mozilla Public License Mozilla

Foundation 1.1 2003

MIT license / X11 license MIT 1.0 1988

Python Software Foundation License

Python Software Foundation

2.0 1998

Fuente: Gordon (2008) El mismo autor indaga en los otras clasificaciones, planteando que la

licencia de código cerrado aplica a cualquier programa informático en el cual

el usuario tiene limitaciones para usarlo, modificarlo o redistribuirlo (esto

último con o sin modificaciones). Este concepto se aplica a cualquier

software no libre o parcialmente libre (semilibre), sea porque su uso,

47

redistribución o modificación está prohibida, o requiere permiso expreso del

titular del software.

Continuando con la idea, la persona física o jurídica (compañía,

corporación, fundación, etc.) al poseer los derechos de autor sobre un

software tiene la posibilidad de controlar y restringir los derechos del usuario

sobre su programa, en el software privativo implica por lo general una

condición donde el usuario sólo tendrá derecho a ejecutar el software bajo

ciertas condiciones, comúnmente fijadas por el proveedor, significando la

restricción de una o varias de las cuatro libertades: usar el programa para

cualquier propósito, capacidad para estudiar el programa, capacidad para

modificar el programa, así como libertad para distribuirlo.

Para dar por terminada la clasificación según los derechos reservados por

el autor para la obra, planteada por Overly (2004), tenemos la licencia de

dominio publico la cual permite el uso, copia, modificación o redistribución

con o sin fines de lucro. El autor resalta que son poco los desarrollos de

software serios dentro de esta clasificación, y aplica mayormente a software

abandonado, cuya empresa desarrolladora ya no se encuentra constituida

desde el punto de vista legal.

Por otro lado, según Gordon (2008) las licencias de software también

pueden recibir una clasificación dependiendo de su usuario destinatario, es

decir, por la forma en como será distribuido el programa en el mercado. El

autor clasifica las licencias entonces en licencia de usuario final y licencia de

48

distribuidor. Con respecto a la licencia de usuario final, es una licencia por la

cual el uso de un producto sólo está permitido para un único usuario.

En relación a lo anterior, en este tipo de contrato el dueño de los derechos

de un producto insta al usuario final de éste a tener conocimiento de las

restricciones de uso, de los derechos del autor y acepte de conformidad.Este

tipo de acuerdo expresa los usos posibles a dar y cuáles no al producto, ya

que quien lo compra no es, legalmente, en ninguna forma dueño del

producto, sino sólo de una licencia para su uso, considerándose esto último

por algunas personas como una limitación a los derechos del usuario.

En el mismo orden de ideas, se presentan también las licencias de

distribuidores, en la cual se le asigna derechos restringidos a un comerciante

de tipo comisionario para vender el software dando una remesa o comisión al

fabricante. La misma puede ser por primera venta o licencia de renovación

de contrato. No se trata de una licencia de uso en términos jurídicos, sino

mas bien en un acuerdo comercial en la que no tiene porque ser cedido el

derecho de distribución necesariamente. Puede darse el caso de simple

actividad comercial en donde el distribuidor ni siquiera tenga contacto con el

software, y la licencia de uso en si sea directamente suscrita y puesta a

disposición por parte del fabricante, encargándose el distribuidor del

correspondiente cobro al usuario y pago al fabricante menos su margen.

Contrastando la teoría sobre licencias expuestas por Overly (2004) y Gordon

(2008), queda evidenciado que ambos coinciden en el concepto fundamental

de en lo que consiste una licencia de software. Sin embargo, ambos difieren

49

en las clasificaciones que se les da al software dependiendo de la licencia,

siendo en el caso de Overly (2004) como principal punto para la clasificación

el acceso que pueda tener el usuario final al código fuente del programa para

modificarlo bajo ciertas condiciones o simplemente adherirse a unos términos

de uso privativos sin posibilidad de acceso al código del programa. Por otro

lado, Gordon (2008) recomienda realizar además una clasificación a partir de

la distribución al mercado que elegirá para el producto de software, pudiendo

ser esta del usuario directamente con el fabricante o del usuario con un

distribuidor intermedio.

Ahora bien, en base a todo lo anteriormente expuesto, se puede definir una

licencia de software como la serie de condiciones que establecen las

directrices mediante las cuales el usuario podrá utilizar dicho software, así

como las libertades que tiene de hacer con el. Dentro del contexto de la

investigación, la licencia constituye un punto muy importante, ya que fue en

base al decreto presidencial 3.390, el cual insta a las empresas del sector

petrolero a migrar sus sistemas a licencias de código abierto, que surgió la

necesidad de desarrollar un modelo gerencial para esta clase de proyecto.

2.4.2. CICLO DE VIDA Para Senn (2003) el ciclo de vida de un proyecto de software define los

pasos técnicos para el comienzo, sus procesos intermedios y el final exitoso

del mismo(ver figura 5). La elección del ciclo de vida de un proyecto de

software en base a los requerimientos, objetivos y características del

50

producto final constituye la primera decisión a tomar en lo concerniente a

este aspecto.

En relación a lo anterior, la definición del ciclo de vida determinara

también que acciones de transición se incluirán al final del proyecto y cuales

no. De esta manera, la determinación del ciclo de vida del proyecto puede

ser usada para enlazar el proyecto a operaciones sucesivas de la

organización ejecutora.

Figura 5. Diagrama de Flujo para Ciclo de Vida. Fuente: PMBOK (2008) Para Cleland e Ireland (2001) primero se debe considerar una fase de

Ingeniería Conceptual la cual comprende identificar lo que se requiere del

proyecto, evaluación preliminar de ideas considerando factores técnicos,

económicos y ambientales, descripción de las características de un producto,

descripción de las condiciones de localización del proyecto y un estudio de

pre-factibilidad. Definen las siguientes actividades para esta fase:

(a) Valoración inicial de los recursos requeridos.

(b) El desarrollo de una opinión preliminar del valor operativo o estratégico

para completar los propósitos existentes en la empresa.

51

(c) Determinar si son necesarios los resultados que se esperaran.

(d) Establecimiento de los objetivos y las metas preliminares del proyecto.

(f) Organización de un equipo para administrar el proyecto.

(g) Vender a la organización la idea del enfoque del proyecto.

(h) Preparación de un plan preliminar que incluya una propuesta, en caso de

que la requiera el usuario final.

(i) Determinación de las necesidades existentes o de las deficiencias

posibles de los productos, servicios o procesos organizacionales existentes.

(j) Determinación de la factibilidad inicial técnica, ambiental y económica de

la viabilidad del resultado esperado.

(k) Selección y preparación de un diseño inicial.

(l) Determinación inicial de las interfaces esperadas por los beneficiarios.

(m) Determinación preliminar de cómo se integran los resultados del proyecto

en las estrategias vigentes de la empresa.

Ahora bien, la fase de ingeniería conceptual dentro del contexto de los

proyectos de ingeniería de software, para Pressman (2005) esta fase ayuda

a los ingenieros de software a entender mejor el problema en cuya solución

trabajaran. Incluye el conjunto de tareas que conducen a comprender cual

será el impacto del software sobre el negocio, que es lo que el cliente quiere

y como interactúan los usuarios finales con el software. El diseño y

construcción de un elegante programa de computadora que resuelva el

problema incorrecto no satisface las necesidades de nadie.

52

Continuando con el mismo orden de ideas, para Cleland e Ireland (2001) la

siguiente fase es Ingeniería Básica en donde se detalla que se requiere del

proyecto, preparación de documentación base para soportar el proyecto

como: diseño de proceso, análisis de capacidad, diagramas de flujo con

condiciones de operación y diseño, estudios de simulación, entre otros.

A su vez, involucra la preparación de diagramas de ingeniería y servicios,

especificaciones de materiales, establecimiento de criterios básicos de

instalación, cálculos, preparación de plan de ejecución de ingeniería de

detalle, procura, construcción, arranque y puesta en marcha, estimaciones

de costos, análisis de factibilidad, elaboración de especificaciones para

estudios de impacto ambiental, suelos, topografía, entre otros, diseño

conceptual del sistema de control e instrumentación, y memoria descriptiva

para la elaboración de la ingeniería de detalle. Cleland e Ireland (2001)

definen las siguientes actividades para esta fase:

(a) La valoración completa de los resultados antes de comprometer mayores

recursos, para continuar su desarrollo.

(b) Identificar la necesidad de estudio y tareas adicionales.

(c) Confirmar la decisión de continuar el desarrollo, de crear un prototipo y de

valorar el impacto completo del proyecto en la producción o las instalaciones.

(d) Identificación de los recursos humanos y materiales que se requerirán

para el desarrollo y el despliegue continúo de los resultados.

(e) Preparación de los requerimientos de desempeño del sistema final.

(f) Preparación de planes para apoyar los resultados del proyecto.

53

(g) Identificación de áreas del proyecto donde un riesgo o una incertidumbre

elevados requieren una mayor valoración.

(h) Definición de las interfaces entre los sistemas y dentro de los sistemas.

(i) El desarrollo de un plan preliminar de apoyo logístico, de documentación

técnica y de esfuerzo de las ventas.

(j) El desarrollo de protocolos sobre como se vigilara, evaluara y controlara el

proyecto.

Continuando con el estudio de la fase de Ingeniería de Básica, para

Pressman (2005) durante esta fase se utilizan una combinación de formatos

y diagramas para representar los requisitos de los datos, las funciones y el

comportamiento de una manera que es relativamente fácil de entender y, aun

más importante, conduce a una revisión para lograr la corrección, la

integridad y la consistencia. Lo anterior se examinando los requisitos del

software desde algunos puntos de vista diferentes.

Por otro lado, Cartay (1998) se refiere una Ingeniería de Detalle para

especificar como se requiere el proyecto, hay un análisis y adecuación de la

información básica, apoyo a la procura, elaboración de documentos para la

licitación bien sea especificaciones generales y particulares, lista de

materiales y cómputos de obras.Para esta fase se incluye una preparación

para la requisición de materiales, elaboración de documentación aprobada

para construir, elaboración del libro del proyecto de ingeniería de detalle,

estimados de costos de construcción, elaboración de especificaciones para

planificación y control, y por ultimo, análisis de licitaciones y ofertas.

54

Seguidamente, Cartay (1998) también estipula una fase de procura la cual

comprende parte de los recursos para hacer un proyecto, incluye la definición

de elementos logísticos, así como ejecución de actividades como:

preparación de paquetes de licitaciones, documentos comerciales,

documentos técnicos, solicitudes de cotizaciones, comparación de ofertas,

elaboración de ordenes de compra, manejo de almacenes, contabilidad de

equipos y materiales, preparación de solicitudes de pagos a proveedores,

nacionalización de materiales y equipos, al igual que contratación de

transporte.

Igualmente durante la Ingeniería de Detalle, Pressman (2005)

establecedurante esta fase la creación de una representación o modelo del

software, proporcionando detalles acerca de la estructura de datos, las

arquitecturas, las interfaces y los componentes del software que son

necesarios para implementar el sistema. Vale destacar la importancia de esta

fase para la definición de la calidad del producto final.

La ultima fase según Cleland e Ireland (2001) es la construcción en donde se

comienza con la ejecución en campo, estudio de aplicación de

documentación técnica, definición de métodos y procedimientos

constructivos, definición de métodos y procedimientos de inspección,

planificación detallada de la construcción, control de materiales, pruebas de

arranque, puesta en marcha, actualización de documentos, actas de

aceptación provisional y definitiva de la obra, así como cierres de

contrato.Las actividades para esta fase comprenden:

55

(a) Identificación e integración de los recursos requeridos.

(b) Verificación de las especificaciones de producción del sistema.

(c) Producción, construcción e instalaciones reales.

(d) Desarrollo y la aprobación final de apoyo logístico para reforzar las

ventas.

(e) Aplicación de pruebas finales con el fin de determinar la idoneidad de los

resultados.

(f) Elaboración de manuales técnicos y documentos complementarios que

describan como se pretende que operen los resultados del proyecto.

(g) Planear estrategias para el proceso de producción que incluya

especificaciones del equipo y apoyo para los recursos, así como enseñanza

y capacitación para la fuerza de trabajo.

(h) Procesar los cambios necesarios en la ingeniería.

Extendiendo el estudio de la misma fase de construcción, pero

enfocándonos en las particularidades de los proyectos de ingeniería de

software, Pressman (2005) expone que durante esta fase se codifica el

software en un lenguaje de programación apropiado de acuerdo a la

plataforma tecnológica en donde vaya a ser desplegada la aplicación.

Durante dicha fase también se realizan las pruebas del software con el

objetivo de validar el adecuado funcionamiento del software y que en efecto

cumpla con los requerimientos iniciales en la Ingeniería Conceptual.

También, es de suma importancia la elaboración de la documentación

56

técnica y de usuario para el software, estas incluyen diccionario de datos,

manual del sistema, manual de usuario y errores comunes.

Para concluir el apartado y manera de contraste, Cartay (1998) y Cleland

e Ireland (2001) coinciden en la división establecida para el ciclo de vida de

cualquier proyecto, sin embargo, la diferente entre sus opiniones reside en

los procedimientos y actividades recomendadas para ejecutar cada fase.

Mientras que Cartay (1998) establece pasos pequeños y específicos para

alcanzar los objetivos de cada fase del ciclo de vida, Cleland e Ireland (2001)

se centra más en los resultados, haciendo hincapié en los productos y brinda

flexibilidad en la forma de obtenerlos.

En el mismo orden de ideas, si bien Pressman (2005) coincide con lo

expuesto por Cartay (1998) en el sentido de las fases del ciclo de vida vistas

de modo general, sin embargo cuando nos vamos al detalle las diferencias

son amplias. Pressman (2005) se enfoca en actividades propias de un ciclo

de vida para el desarrollo de software de excelente calidad, mientras que las

actividades expuestas por Cartay (1998) son generales y puedan aplicar a

cualquier esfuerzo denominado como proyecto.

Sobre la base de todo lo anterior, conocer el ciclo de vida de un proyecto

considerando todas las etapas como ingeniería conceptual, básica, detalle,

procura y construcción, sirve de soporte a la presente investigación porque

permite identificar dentro del alcance de esta propuesta, las actividades que

realizan las organizaciones en las empresas del sector petrolero occidental

para la ejecución de proyectos de ingeniería de software.

57

2.4.3. PLATAFORMA TECNOLÓGICA La teoría de Senn (2003) plantea que la plataforma tecnológica depende dela

adecuada selección de la plataforma de hardware y software para el

despliegue del sistema hacia los usuarios. El autor señala que en la

actualidad en lo referente a la plataforma de hardware se utilizan por lo

regular dos formas para lograr dicho cometido: la plataforma de escritorio o la

plataforma de servidor.

En relación a lo anterior, para el mismo autorla plataforma de escritorio

consiste en un software instalado de forma local en la computadora la cual lo

ejecuta (ver figura 6), es recomendada cuando la cantidad de usuarios es

pequeña (menor a 10) y no se requiere compartir los datos entre ellos, entre

sus ventajas tenemos su rapidez de procesamiento, que no posee

dependencia de ningún ente externo para su funcionamiento , además de

tener acceso a partes del sistema operativo donde las aplicaciones web

cliente servidor están restringidas por ser criticas del sistema local.

No obstante, Pressman (2005) advierte sobre ciertas desventajas, entre

las cuales señala su dificultad para extraer los datos, altos riesgos de

seguridad por una vulnerabilidad local en los datos, además de requerir de

ciertos conocimientos técnicosdel sistema operativo por parte del usuario

final, debido a que dicho software debe ser instalado personalmente en la

computadora por personal especializado, elevando ampliamente los costos

asociados al mantenimiento de la plataforma.

58

Figura 6. Plataforma de Escritorio. Fuente: Senn (2003) Por otro lado, Senn (2003) también exponesobre la plataforma de servidor

(ver figura 7), la cual constituye la mas común hoy en día gracias a su

facilidad para desplegarse hacia una gran cantidad de usuarios en cualquier

parte del mundo y su fácil esquema de mantenimiento centralizado, la define

como un modelo de aplicación distribuida donde las tareas se reparten entre

los proveedores de recursos o servicios, llamados servidores, y los

demandantes, llamados clientes.

Un cliente realiza peticiones a otro programa, el servidor de aplicaciones, el

cual da respuesta de forma asíncrona . Esta idea también se puede aplicar a

programas que se ejecutan sobre una sola computadora, aunque es más

ventajosa en un sistema operativo multiusuario distribuido a través de una

red de computadoras.

59

Figura 7. Plataforma de Servidor. Fuente: Senn (2003) Continuando con el mismo orden de ideas, entre sus ventajas se

mencionan la centralización del control al ser todos los accesos, recursos y

datosson manejados por el servidor de forma que un programa cliente

defectuoso o no autorizado no pueda dañar el sistema, la escalabilidad ya

que se puede aumentar la capacidad de clientes y servidores por separado,

su seguridad por contar con un administrador del sistema el cual es el único

con acceso total de manipulación de los datos y fácil mantenimiento al estar

60

distribuidas las funciones y responsabilidades entre varios ordenadores

independientes.

Sin embargo, además de mencionar ventajas similares, Pressman (2005)

menciona sus desventajas como: la velocidad de procesamiento puede verse

negativamente impactado por un ancho de banda de red sobresaturado

producto de una gran cantidad de clientes enviando peticiones simultaneas al

mismo servidor, son vulnerables a un único nodo de falla representado por el

servidor de aplicaciones al cual se conectan todos los clientes poniendo en

grave riesgo las operaciones de la empresa en caso de que dicho servidor se

encuentre físicamente en la extranet y no se disponga de esta, de igual

forma, una plataforma de servidores es por lo regular mucho mas costosa

que una de escritorio debido a la robustez y capacidad de procesamiento

necesaria adquirir dichos equipos e implementarlos.

Ahora bien, mientras que Senn (2003) recomienda implementar un

enfoque más clásico para el desarrollo de proyectos de ingeniería de

software haciendo énfasis en la construcción de los sistemas en ambientes

de escritorio, Pressman (2005) recomienda ampliamente el modelo cliente

servidor debido a la ventaja que este ofrece desde el punto de vista de

escalabilidad y fácil distribución hacia los usuarios finales del sistema.

A modo de resumen, se puede definir entonces la plataforma tecnológica

de un proyecto de ingeniería de software como una característica critica ya

que la definición de esta durante la fase de planeación del proyecto

dictarálas facilidades o por menores que se encontrará el equipo del proyecto

61

al construir e implementar el sistema. En tal sentido,durante la fase de

planeación del proyecto se debe estudiar en gran detalle los requerimientos

del usuario con el fin de elegir la plataforma óptima para la tarea en mano.

2.5. REQUERIMIENTOS PARA GESTIONAR PROYECTOS DE INGENIERÍA DE SOFTWARE Los requerimientos cumplen un papel primordial en el proceso de

producción de los modelos al enfocarse en un área fundamental: la definición

de lo que se desea producir. Su principal tarea consiste en la generación de

especificaciones correctas,describiendo con claridad, sin ambigüedades, en

forma consistente y compacta, el comportamiento del modelo; pretendiendo

así minimizar los problemas relacionados al desarrollo del mismo.

2.5.1. TÉCNICOS Para el PMI (2008), los requerimientos técnicos del proyecto se encuentran

formado por las especificaciones de ingeniería, el tiempo de realización de

las actividades, aunado al alcance del mismo dentro de la organización y de

la comunidad adyacente.

Según Cartay (1998), una vez tomada la decisión sobre la ejecución del

proyecto, el propietario requiere el apoyo de ingenieros (propios o externos

mediante contratos), para que preparen los documentos contractuales, los

cuales consisten en un conjunto de planos, especificaciones y propuestas de

ofertas. Mientras los planos están siendo preparados, el responsable de la

62

ingeniería mantiene un estrecho contacto con el propietario y los

proveedores de equipos y materiales a objeto de hacer las estimaciones de

costo preliminares.

Continuando con lo anterior, estas estimaciones permiten al propietario

confirmar la factibilidad económica del proyecto y los planos pueden ser

modificados para ajustarlo a los fondos disponibles. El ente contratante es

responsable de la preparación de las especificaciones técnicas que servirán

de fundamento para la elaboración del presupuesto base.

En lo referente a este apartado, Pressman (2005) establece que los

puntos técnicos del proyecto de ingeniería de software se deben abordar con

un Front-End Loading (FEL) el cual es un conjunto de procesos teniendo en

consideración todos los factores clave para permitir traducir la estrategia de

una organización en un al proyecto viable. Esta es una metodología basada

en el concepto de portones de aprobación, donde en cada portón se

aprueba, o no, el pasaje a la siguiente etapa. Cada etapa implica un

desarrollo cada vez mayor de los estudios involucrados, disminuyendo la

incertidumbre, pero requiriendo mayor presupuesto y tiempo para su

ejecución comparado con su etapa anterior.

En relación a lo anterior, la metodología Front-End Loading (ver figura 8)

es especialmente útil en proyectos industriales con montos de inversión

millonarios, y lleva varios años siendo utilizada en las diferentes industrias de

procesos como la petrolera, de gas, petroquímica, así como la

63

tecnológica,como un estándar para proyecto técnicos cuya complejidad

inicial es alta.

Figura 8. Fases Front-End Loading . Fuente: GGPIC (2000) A manera de contraste, tanto Pressman (2005) como Cartay (1998)

establecen que lo recomendable es adaptar un metodología de ejecución

por fases para ir definiendo los requerimientos técnicos proyecto a medida

que avanza en aprobaciones y desembolsos con el fin de ir mitigando

cualquier riego y resguardar el capital invertido. Sin embargo, Pressman

(2005) adicionalmente hace hincapié en la importancia de definir iteraciones

rápidas de estas fases en los proyectos de ingeniería de software con el

objetivo de ir puliendo los prototipos del sistema.

ParaSenn (2005), los requerimientos técnicos de un proyecto de ingeniería

de software vienen dictados directamente por los requisitos del usuario así

como por los globales del sistema, vale destacar que los requerimientos no

64

están solo relacionados con las funciones del sistema especificadas en los

casos de uso elaborados por los analistas, si no también con las

restricciones y condiciones las cuales se puedan presentar por la reglas del

negocioposiblemente ligadas a autorizaciones, auditorias o la plataforma

planificándose a implementar para el sistema.

Continuando con Senn (2005), muchas veces dentro de los proyectos de

ingeniería de software los requerimientos técnicos no están del todo claro al

principio, encontrándose realmente subyacente a las necesidades de los

usuarios, es por eso que los analistas de sistema tiene la tarea de analizar a

fondo los requisitos con el fin de identificar realmente las condiciones

técnicas mediante las cuales se debe implantar el software.

Todo lo anterior es crucialmente cierto en proyectos de ingeniería de

software, ya que solo la correcta definición de las especificaciones técnicas

del sistema en base a los requerimientos de los usuarios y condiciones de la

plataforma, aseguran la satisfacción de los usuarios hacia el producto, por lo

que nunca se debe comenzar la construcción de un software sin una etapa

previa de planificación, así como una definición completa y fácil de entender

por el cliente sobre los requerimientos.

2.5.2. ECONÓMICOS De acuerdo a lo expuesto por Cartay (1998), los requerimiento

económicos del proyecto a ejecutar se encuentra formado por el presupuesto

base o estimaciones de costo y los anticipos. El presupuesto base es

65

definido directamente por la estimación de costo la cual a su vez es realizada

guiándose por las especificaciones técnicas para la ejecución de la obra en

donde se encuentran a nivel de detalle los recursos necesarios a adquirir y

los servicios indispensables a contratar, todo lo anterior estipulado en una

anterior fase de planificación.

La administración de costos de un proyecto para Cleland e Ireland (2001)

requiere una estricta técnica para calcular, presupuestar, así como controlar

los gastos mediante los indicadores económicos. El presupuesto es el

documento que enumera todas las categorías de gastos planeados y las

cantidades para cada una, debido a esto, las variaciones entre el

presupuesto y el costo real afectan el costo total. Los cambios de ámbito o

en la duración del proyecto también tienen implicaciones que normalmente

aumentan los costos. Asimismo, la falta de eficiencia en la productividad, la

materialización de los riegos no mitigados y el nuevo trabajo descubierto

afecta negativamente lo presupuestado.

En el mismo orden de ideas de Cleland e Ireland (2001), el control de los

costos se consigue con un seguimiento detallado y fidedigno de los gastos al

ir comparándolos con el presupuesto durante todas sus fases (ver figura9). El

seguimiento debe ser una técnica proactiva para recopilar los gastos en

tiempo real con el fin de registrarlos en una base de datos histórica para sus

posterioresanálisis.

En el mismo orden de ideas, el resultado del análisis forma un informe de

estado económico para la revisión periódica en reuniones del proyecto las

66

cuales pueden ser de índole semanal, mensual, trimestrales, anuales o como

así lo requiera la magnitud del proyecto. Es importante definir medidas

correctivas durante dichas reuniones para mitigar riesgos de incurrir en

mayores desviaciones presupuestarias.

Figura 9. Costos del Proyecto en Distintas Fases. Fuente: PMBOK (2008) Tanto Cartay (1998) como Cleland e Ireland (2001) coinciden en el

análisis inicial de la factibilidad económica del proyecto y sobre el monitoreo

periódicos de este aspecto mediante indicadores económicos, utilizando

principalmente como insumo para la generación de estos indicadores los

documentos relacionados con el presupuesto del proyecto.

Para Kendall (2005), los costos asociados a los proyectos de ingeniería

de software deben ser calculados en base a las horas hombres estimadas

para cada una de las funcionalidades y características del software a

67

construir, una técnica popular es asignarle la responsabilidad al personal

técnico del proyecto de otorgarle un puntaje a cada funcionalidad y

característica del proyecto en base al esfuerzo requerido, posteriormente a

cada punto se le asigna un valor por hora (ver cuadro 2), resultando en una

estimación certera del esfuerzo necesario para construir el software.

Cuadro 2. Conversión entre Puntaje de Esfuerzo y Horas Hombre

Puntos Horas Cantidad de Programadores

1 à 4 1

2 à 8 1

3 à 16 1

4 à 40 1

5 à 32 2

6 à 80 2

7 à 120 3 Fuente: Kendall (2005) En el caso de Pressman (2005), este incluso recomiendadada la

culminación decada proyecto se documente bien los tiempos reales

requeridos para el desarrollo de cada componente de software, con el fin de

utilizar dicha información en futuras estimaciones. A medida que progresa el

proyecto es de vital importancia ir comparando el tiempo estimado versus el

tiempo real, ya que constituye un indicador clave para diagnosticar el estado

actual económico del proyecto y si esta resultando rentable.

Interpretando la teoría, es recomendableestimar los proyectos de ingeniería

de software utilizando técnicas especializadas para este tipo de labor, como

68

coinciden Kendall (2005) y Pressman (2005). En lo concerniente al monitoreo

de los indicadores económicos en los proyectos de ingeniería de softwarelo

anterior se vuelve aun mas críticos, ya que solo a través de indicadores

económicos evaluados sobre el tiempo de ejecución del proyecto se puede

evaluar la rentabilidad del mismo, es decir, el desarrollo debe ser eficiente y

eficaz para maximizar la ganancia.

2.5.3. HUMANOS Los requerimientos humanos del proyecto , para Cartay (1998), se

encuentran formado por el personal involucrado en el mismo y la información

permitiendo la toma de decisiones operativas oportunas, por lo que se debe

procurar establecer una planificación organizacional.

En este mismo aspecto, el PMI (2008) establece para la planificación

organizacional identificar, documentar y designar los roles, responsabilidades

y relaciones de mando necesarios para la ejecución del proyecto, para

posteriormente pasar a la adquisición del personal en donde la tarea es

obtener el recurso humano que se asemeje mas a estos perfiles

profesionales, ya que en la mayoría de los casos no se puede cumplir en la

totalidad con los perfiles planificados.

El siguiente paso, según Cleland e Ireland (2001), es desarrollar las

competencias individuales y grupales para mejorar el desempeño /

rendimiento del proyecto. El desarrollo individual (gerencial y técnico) es la

base necesaria para fortalecer al equipo de trabajo. La evolución del equipo

69

para adaptarse a la dinámica del ambiente del proyecto y sus riesgos es

crítico para la capacidad de cumplir con los objetivos.

En relación a lo anterior, una vez seleccionado el recurso se procede a la

asignación del trabajo, valorando las habilidades de las personas y

emparejándolas lo mejor posible a la lista de actividades a desarrollar.

Determinar las asignaciones en grupo permite conocer cuales son las

habilidades poseídas por los demás y garantizar no solo que la persona

adecuada reciba la tarea que mejor pueda desempeñar, sino también que los

miembros del equipo toman conciencia de los recursos finitos de los cuales

se disponen.

Según Cartay (1998), para las empresas u organizaciones, la capacitación

del recurso humano debe ser de vital importancia porque contribuye al

desarrollo personal y profesional de los individuos a la vez que redunda en

beneficios para la empresa. En tal sentido, las organizaciones deben motivar

al personal a siempre superarse y continuar con sus estudios. Dependiendo

de los roles asignados a cada persona, se pueden tener diferentes tipos de

organización (ver figura 10).

Para Pressman (2005), dentro de un proyecto el personal y su

capacitación técnica es la pieza más importante para asegurar la calidad del

producto y incidiendo en el cumplimiento de los objetivos del proyecto y la

satisfacción del cliente, siendo esto aun más evidente cuando el producto del

esfuerzo es de carácter lógico o intangible. Lo recomendable en el caso de

proyectos de ingeniería de software es adoptar un capacitación en base a los

70

roles que desempeñen lo miembros del proyecto, los cuales podrían ser

líderdel proyecto, analista de requerimientos, arquitecto de software,

programador o probador de software.

Figura 10. Matriz de Tipos de Organización. Fuente: PMBOK (2008) Sin embargo, Senn (2003) también recomienda que dicho plan de

capacitación se realice analizando tanto el cargo actual como el desarrollo de

plan de carrera del prospecto , se debe tomar en consideración la función que

podría desempeñar en un futuro proyecto u de la organización. Por ejemplo,

se puede dar el caso en donde la persona que hoy es analista de software,

en el siguiente proyecto deba desempeñar funciones de líder debido al retiro

de uno estosúltimos.

Contrastando la teoría de los distintos autores, se puede observar que

todos coinciden en el punto del adiestramiento del personal, en donde se

recomienda establecer un programa de capacitación del personal junto con la

71

planificación organizacional del proyecto, fortaleciendo de esta manera el

aspecto de sostenibilidad en el tiempo para la organización al contar con

profesionales altamente calificados.Lo anterior es especialmente cierto en los

proyectos de ingeniería de software, en donde la naturaleza lógica del

producto final depende en su totalidad de la capacidad técnica del personal

técnico encargado de diseñar y programar los distintos módulos del software.

2.6. FASES DEL MODELO GERENCIAL PARA PROYECTOS DE INGENIERÍA DE SOFTWARE A continuación se exponen las fases clásicas a contener por un modelo

gerencial que asegure como resultado un producto de calidad en los plazos y

costos previstos. Asimismo se indagara en transmitir los conceptos, prácticas

y herramientas que permitan una adecuada planificación, organización,

dirección y control de los proyectos enfocados a las tecnologías de

información o informática.

2.6.1. PLANIFICACIÓN Para Cartay (1998), planificación es la fase a través de la cual se

pretende sistematizar lo que se requiere hacer, es la metodología para

seleccionar el curso de acción, cuya tarea es minimizar los riesgos para

obtener mejores ventajas de las oportunidades. Por otra parte Robbins

(2002) define la planificación como la definición de metas, establecer

72

estrategias y elaborar planes para coordinar actividades. La planificación es

un componente esencial del manejo de un proyecto para:

(a) Organizar el trabajo.

(b) Decidir quien, que, cuando, como y por que se realizara cada trabajo.

(c) Determinar requerimientos.

(d) Asignación de tiempos.

(f) Asignación de responsabilidades, integrar trabajos de todas las partes

involucradas.

(g) Establecer sistemas de comunicación.

(h) Coordinar las actividades y el personal.

Según Cleland e Ireland (2001) en esta fase de planeación se debe

identificar que se propone hacer y porque. Para ellos se deben determinar

los objetivos, metas y estrategias del proyecto, elaborar una estructura de

división del trabajo, crear diagramas de prioridades para establecer una

relación lógica y los puntos importantes, elaborar programas basados en

tiempo para el proyecto con base en un diagrama de prioridades y por ultimo

planear el apoyo de los recursos del proyecto.

En el mismo orden de ideas, para Gido (2003) la planeación es la disposición

sistemática de tareas para el logro de un objetivo. El plan establece lo que se

necesita lograr y como ha de hacerse. Lo primero a contener por el plan es

el objetivo del proyecto el cual define el resultado esperado o producto final.

Este se debe fijar con claridad y es necesario el acuerdo entre el cliente y la

73

organización ejecutora. También debe ser alcanzable, especifico,

cuantificable y claro.

Figura 11. Ejemplo de EDT para Proyectos de Ingeniería de Software.

Fuente: PMBOK (2008)

En relación a lo anterior, se continúa con la estructura de división del trabajo

la cualdetermina los elementos o actividades del proyecto necesarios para

cumplir con el objetivo. La EDT (ver figura 11) divide el proyecto en piezas o

partidas manejables para ayudar a asegurar la identificación de todos los

elementos que se necesiten para completar el alcance del trabajo del

proyecto. Tampoco se puede obviar la matriz de responsabilidades el cual

constituye unmétodo utilizado para mostrar en un formato tabular las

74

personas poseedoras de la responsabilidad de realizar las partidas de trabajo

de una EDT.

Continuando con Gido (2003), el siguiente paso es la definición de

actividadesmediante una tormenta de ideas el equipo de trabajo puede

elaborar una relación de actividadesespecíficas, detalladas, necesarias para

realizar el proyecto global. Una vez definida todas las actividades para los

paquetes de trabajo se procede a elaborar un diagrama de red que indique el

orden apropiado y las interrelaciones. Seguidamente de una programación

para realizar asignación de duraciones, fechas inicio, fecha de culminación a

cada actividad, y recursos necesarios. Siempre se debe tener en cuenta el

control del proyecto el cual incluye recopilar cada determinado tiempo

información sobre su desempeño, comparando el real con el planeado y

levando a cabo acciones correctivas si el desempeño real esta retrasado con

relación a lo planeado.

Para Cleland e Ireland (2001) la responsabilidad principal de llevar a cabo

la planificación recae en el líder del proyecto, este prepara el plan,

incluyendo el uso del equipo del proyecto y los demás recursos disponibles

para presentarlo a la jefatura administrativa . Los integrantes del equipo son

responsables de contribuir al desarrollo del plan y asegurar que el trabajo

descrito pueda realizarse con los recursos contemplados.

Fundamentándose en lo anterior, se puede concluir que la buena

planeación minimizara las perdidas para el proyecto y definirá claramente los

papeles de todos los participantes, propietarios, contratistas, departamentos

75

corporativos asociados y extraños. La buena planeación también

proporcionara una adecuada consideración de todos los elementos del

proyecto, y asegura un esfuerzo propio para satisfacer la fecha de

terminación.

2.6.2. ORGANIZACIÓN En el apartado de la fase organizacional, el PMI (2008) LQFOX\ H�ORV�

SURFHVRV�TXH�RUJDQL] DQ�\ � GLULJHQ�HO�HTXLSR�GHO�SUR\ HFWR ( O�HTXLSR�GHO�

SUR\ HFWR�HVWi � FRP SXHVWR�SRU�ODV�SHUVRQDV�D�TXLHQHV�VH�OHV�KDQ�DVLJQDGR�

roles y responsabilidades durante la ejecución del mismo. Si bien es común

hablar de asignación de roles, los miembros del equipo deben participar en

gran parte de la planificación y toma de decisiones del proyecto.

La participación temprana de los miembros del equipo aporta experiencia

durante el proceso de planificación, fortaleciendo el compromiso con el

proyecto. El tipo de personal, así como la cantidad de miembros del equipo

del proyecto a menudo pueden cambiar, mientras se avanza con el proyecto,

adaptándose en lo posible a la dinámica del mismo, con el fin de maximizar

la utilización de los recursos y minimizar riesgos.

En el mismo orden de ideas, el PMI (2008) explica que el equipo de

dirección del proyecto es un subgrupo del equipo del proyecto y es

responsable de las actividades de dirección de proyectos, tales como la

planificación, el control y el cierre. Este grupo puede denominarse equipo

central, equipo ejecutivo o equipo de liderazgo, y debe estar conformado por

76

los profesionales con mayor cantidad de experiencia en el equipo, ya que

estos tomarán las decisiones mas criticas e influyentes.

Para proyectos máspequeños, las responsabilidades de la dirección de

proyectos pueden ser compartidas por todo el equipo o administradas

únicamente por el gerente del proyecto. El patrocinador o cliente del proyecto

trabaja con el equipo de dirección del proyecto, ayudando generalmente con

cuestiones como la financiación del proyecto, aclarando preguntas sobre el

alcance y ejerciendo influencia sobre otros a fin de beneficiar al proyecto y

sentirse satisfecho con sus resultados.En el Figura 12 proporciona un

panorama general de los procesos de aplicables a la fase de organización de

un proyecto según el PMI (2008), a manera de resumen:

(a) Desarrollar el Plan Organizativo, es el proceso por el cual se identifican y

documentan los roles dentro de un proyecto, las responsabilidades, las

habilidades requeridas y las relaciones de comunicación, y se crea el plan

para la dirección de personal.

(b) Adquirir el Equipo del Proyecto, es el proceso por el cual se confirman los

recursos humanos disponibles y se forma el equipo necesario para completar

las asignaciones del proyecto.

(c) Desarrollar el Equipo del Proyecto, es el proceso que consiste en mejorar

las competencias, la interacción de los miembros del equipo y el ambiente

general del equipo para lograr un mejor desempeño del proyecto.

(d) Dirigir el Equipo del Proyecto, es el proceso que consiste en dar

seguimiento al desempeño de los miembros del equipo, proporcionar

77

retroalimentación, resolver problemas y gestionar cambios a fin de optimizar

el desempeño del proyecto.

Figura12. Procesos en la Fase de Organización. Fuente: PMBOK (2008) Por otro lado, en lo referente a la fase de organización para proyectos de

especialización informática o de ingeniería de software, Senn (2003) expone

que el equipo del proyecto puede utilizar sin problemas un modelo

organizativo diferente al de la empresa medular siendolo importante elenlace

78

de las organizaciones a modo de evitar conflictos entre ellas y se

incrementen las probabilidades de un proyecto exitoso.

El modelo a elegir depende de los requerimientos del proyecto, los tres tipos

principales de estructura organizacional: estructura funcional, la estructura

departamental y la estructura matricial. Cada una con sus fortalezas y

debilidades.En la estructura funcional, según el PMI (2008), los empleados

están organizados en departamentos (ver figura 13) sobre la base de lo que

están haciendo es decir, tenemos departamento de ingeniería, departamento

de mantenimiento, departamento de finanzas, departamento de

investigación, departamento de compras, departamentos de aseguramiento

de la calidad (QA), entre otros.

Figura13. Estructura Funcional. Fuente: PMBOK (2008) Esta estructura favorece la experiencia de cada función, por ejemplo, los

ingenieros de mantenimiento están trabajando en el mismo departamento y

por lo tanto van a intercambiar conocimientos y apoyarse mutuamente. Esta

estructura nos permite ahorrar dinero debido a las economías de escala. Sin

79

embargo, hace que la coordinación entre los diferentes departamentos sea

menos simple, pues los trabajadores pertenecen a distintas secciones y

pueden surgir problemas al momentos de coordinar equipos de trabajo

compuesto por distintas especialidades.

Continuando con la teoría de Senn (2003), en la estructura departamental,

los empleados están organizados de acuerdo a la relación productos-cliente-

ubicación geográfica. Por ejemplo, cada división es responsable de

determinado producto y tiene sus propios recursos, tales como finanzas,

marketing, etc. Por consiguiente, esta estructura es una estructura

descentralizada y por lo tanto permite una mayor flexibilidad y respuesta

rápida a los cambios ambientales. También mejora las estrategias de

innovación y diferenciación. Pero por otra parte, esta estructura genera

duplicación de recursos, ya que, por ej., tenemos que tener bodegas para

cada división. Obviamente, esta organización no favorece el intercambio de

información entre personas que comparten una misma labor, pero que

pertenecen a secciones distintas.

Por último, la estructura matricial combina ambas estructuras. Por ejemplo,

podemos tener una estructura funcional y luego asignar un gerente para

cada producto. Algunos empleados tendrán dos gerentes: gerente funcional y

el gerente de producto. Este tipo de estructura trata de obtener los

beneficios de la estructura funcional y también de la estructura

departamental, sin embargo, no es fácil de implementar debido a la doble

autoridad. Esta estructura es muy utilizada por empresas multinacionales.

80

Confrontando la teoría del PMI (2008) y Senn (2003), ambos establecen

que la estructura o modelo organizativo del proyecto debe seleccionarse en

base a los requerimientos, es decir, dependiendo de los objetivos a cumplir

así como de los recursos disponibles. Por otro lado, para los proyectos de

ingeniería de software, Senn (2003) recomienda adoptar una postura mas

flexible y, de ser necesario, optar por modelos organizativos no propios de la

casa matriz organizacional, siempre y cuando un análisis previo concluya en

un aumento en las probabilidades del éxito del proyecto.

2.6.2. DIRECCIÓN Según lo expuesto por Cartay (1998), consiste en dirigir las operaciones

mediante la cooperación del esfuerzo de los subordinados, para obtener

altos niveles de productividad mediante la motivación y supervisión. En el

marco del modelo gerencial, la dirección se orienta al cumplimiento de la

misión, visión y políticas institucionales, trazándose objetivos estratégicos en

el área de contratación con la finalidad de maximizar el beneficio económico

y social de la organización. La dirección juega un papel importante en un

proyecto ya que permite poner en marcha todos los lineamientos

establecidos durante la planeación y la organización.

A través de ella se establecen formas de conducta más deseables en los

miembros de la estructura organizacional.La dirección eficiente es

determinante en la moral de los empleados y consecuentemente, en el

aspecto de productividad.Su calidad se refleja en el logro de los objetivos,

81

implementación de métodos de organización, y en la eficiencia de los

sistemas de control.

Según Cleland e Ireland (2001) en esta fase de dirección es donde se

establece quien dice que y cuando, se establecen limites de autoridad para la

toma de decisiones relacionadas con la asignación de recursos, crear un

estilo de liderazgo, mejorar las aptitudes interpersonales, preparar un plan

para aumentar las técnicas de administración participativa en el manejo del

equipo del proyecto, y se elaboran técnicas de consenso para la toma de

decisiones por parte del equipo.

Para Cartay (1998) el factor clave durante la fases de todo proyecto es la

dirección del mismo, durante esta fase recae en los hombros del gerente del

proyecto y sus distintos lideres tomar decisiones en tiempo real y de forma

dinámica para mitigar cualquier riesgo inesperado que surja por factores

externos al proyecto. Es debido a lo anterior que una exitosa dirección del

proyecto depende en gran parte de una buena fase de planificación y

organización del mismo.

Esta fase implica la fluidez de comunicación (ver figura 14) entre las

diferentes áreas o departamentos involucrados en el proceso, permitiendo el

desarrollo eficiente al momento de tomar decisiones. De allí, la coordinación

de la ejecución se plantea en un enfoque de asimilar la mejor decisión de

cómo asignar los recursos a distintas áreas y de integrar estas orientándolas

a la consecución de objetivos comunes.

82

Figura 14. Diagrama de Flujo de Comunicación en un Proyecto. Fuente: PMBOK (2008) A modo de contraste, todos los autores coinciden en que esta fase es de

suma importancia por la toma de decisioneslas cuales eventualmente

desembocarían en el éxito o fracaso del proyecto, siendo entonces la fase en

la que los conocimientos teóricos y experiencia del gerente del proyecto

salen a relucir. Por otro lado, se puede contrastar la teoría de Cleland e

Ireland (2001) y Cartay (1998) en el sentido donde los primeros prefieren que

se establezcanprocedimientos rigurosos para la toma de decisiones, mientras

83

el ultimo recomienda ser dinámico de acuerdo a la situación y riesgos

presentes.

2.6.3. CONTROL De lo estipulado por Cartay (1998), se puede decir que el control implica la

medición de la realización de los acontecimientos o eventos contra lo

especificado en planes, para detectar de desviaciones y tomar acciones

pertinentes al caso. Un sistema de control eficiente debe:

(a) Ser comparativo, para poder apreciar si la actuación o rendimiento de una

actividad ha sido bueno o malo.

(b) Tener costo compatibles, el costo de la acción debe ser bajo.

(c) Ser oportuno, pues el control debe proporcionar información cuando se

necesite, de manera que permita diagnosticar lo que va a ocurrir.

(d) Ser frecuente, para que pueda manejarse como control total en un mismo

tiempo sobre todas las variables, y control selectivo donde se toma una

muestra representativa del total.

(e) Ser independiente, no debe existir dependencia ni relación directa de

autoridad entre quien ejecuta la actividad y quien la controla.

Según Cleland e Ireland (2001) en esta fase de control se define quien juzga

a quien y en cuales normas se basa, se establecen las normas para los

costos, programas y rendimiento técnico del proyecto, preparar planes para

los medios con que se evaluara el avance, establece un sistema de

84

información para la administración del proyecto, se preparar una estrategia

de revisión y se evalúa el avance.

De la misma forma, dichos autores exponen que el control es supervisar

el uso de los recursos del proyecto para determinar que tan bien se obtienen

sus resultados reales y si cumplen los objetivos planeados de costos,

programa y rendimiento técnico.

Según Cartay (1998), las etapas de todo proceso de control son el

establecimiento de estándares de puntos estratégicos, comprobación e

información sobre la ejecución y la toma de acción correctiva.

Profundizando en lo anterior, el establecimiento de estándares de puntos

estratégicos parte de la planeación, una vez que la planificación ha

establecido sus objetivos, el control puede comenzar con el procesos de

confrontación de los resultados obtenidos de ellos. Los puntos de control

deben ser oportunos para detectar las desviaciones significativas, deben

permitir obtener información y realizar observaciones, deben seleccionarse

para promover la ejecución equilibrada y deben proporcionar algunos

controles amplios que consoliden y resuman grandes bloques de actividades

detalladas, preferiblemente mediante Dashboards o tableros de control.

La comprobación e información sobre la ejecución, consiste en comparar

la ejecución real con los estándares y objetivos previamente establecidos.

Una vez obtenidos los resultados del control a través de informes, es

conveniente realizar visitas a los escenarios de acción para intervenir y hacer

85

que las reuniones de evaluación de un proyecto tengan la productividad que

conduzca a la toma de decisiones oportunas.

La acción correctiva incluye al menos una revisión de los planes y es

necesaria para que cualquier control sea eficiente y eficaz. Es necesario

realizar una valoración continua de los resultados en términos de las

condiciones ambientales externas y el ajuste de los planes correspondientes.

De esta manera las contingencias puedan ser tratadas en forma estratégica

para obtener el mejor resultado.

De todo lo anterior se concluyeque establecer controles dentro de los

proyectos permite medir el desempeño de la ejecución del mismo, dicho

concepto es vital para el desarrollo de la presente investigación porque en

caso contrario no se pueden evaluar los eventos ocurridos, detectar

desviaciones y tomar las acciones pertinentes al caso, todo ello para valorar

el progreso del esfuerzo dentro de los plazos de tiempo previstos y con la

cantidad de recursos existentes.

3. SISTEMA DE VARIABLES La presente investigación está constituida por una variable compuesta :

modelo gerencial para proyectos de ingeniería de software, a continuación se

define las variables a partir de los diferentes elementos que la conforman.

3.1. DEFINICIÓN NOMINAL Necesidad del modelo gerencial para proyectos de ingeniería de software.

86

3.2. DEFINICIÓN CONCEPTUAL Modelo Gerencial: Se define, según David (2002), como la descripción de un

conjunto de objetosrelacionados dentro del sistema de gestión que involucra

las fases de un proyecto: inicio, planificación, ejecución, control y cierre, el

cual se basa en la realidad procurando utilizar de la manera más eficaz

posible los recursos asignados y que debe ser completado para alcanzar

metas y objetivos específicos del proyecto.

Proyecto de Ingeniería de Software: Se define para Pressman(2005)

como un esfuerzo finito en el tiempo y con recursos limitados el cual tiene

como findesarrollar un sistema hombre – máquina para procesar datos con el

fin de registrar los pormenores originados por las transacciones incidentes y

las entidades conformantes de una organización, brindando información que

haga más fácil el desarrollo de actividades y funciones en la misma.

En tal sentido, según David (2002) y Pressman (2005) la variable queda

definida como la descripción de un conjunto de objetos relacionados dentro

del sistema de gestión el cual involucra las fases de un proyecto:

planificación, organización, dirección y control, utilizando de la manera más

eficaz posible los recursos asignados con el fin desarrollar un sistema

hombre – máquina que procese datos teniendo como objetivo el registro de

los pormenores originados por las transacciones incidentes y las entidades

87

conformantes de una organización, brindando información la cual hace más

fácil el desarrollo de actividades y funciones en una organización.

3.3. DEFINICIÓN OPERACIONAL Dentro del contexto de la investigación, se concibe un modelo gerencial para

proyectos de ingeniería de software como el conjunto de directrices

establecidas por la gerencia para alcanzar exitosamente los objetivos de un

proyecto de software a través de un esfuerzo coordinado con un conjunto

limitado de recursos (personas, tiempo, dinero) dentro de las empresas del

sectorpetrolero occidental para solventar un problema que afecte al negocio

de los hidrocarburos de forma directa o indirecta.

En lo concerniente a la operacionalización de la variable, se hace énfasis

en la situación actual de los proyectos de ingeniería de software, así como

sus características y requerimientos, para ello se establecieron los

respectivos indicadores, tal como se muestra en el cuadro de

Operacionalización de la Variable. Las dimensiones ya mencionadas fueron

medidas utilizando un cuestionario como instrumentó en donde a mayor

puntaje menor presencia de la problemática en el indicador, los resultados

fueronanalizadosmediante estadística descriptiva, dejando en evidencia

como son los modelos gerenciales para proyectos de ingeniería de software

dentro de las empresas del sector petrolero occidental.

88

3.4. OPERACIONALIZACIÓN DE LA VARIABLE Objetivo Especifico Variable Dimensión Indicador Diagnosticar la situación actual de la gerencia en los proyectos de ingeniería de software en las empresas del sector petrolero occidental.

Modelo Gerencial para Proyectos de Ingeniería de Software.

Situación actual de la gerencia asociada a los proyectos de ingeniería de software.

- Alcance. - Costo - Tiempo. - Calidad.

Describir las características de los proyectos de ingeniería de software en las empresas del sector petrolero occidental.

Características de los proyectos de ingeniería de software.

- Tipo de Licencia

- Ciclo de Vida. - Plataforma

Tecnológica.

Determinar los requerimientos para lagerenciade proyectos de ingeniería de software en las empresas del sector petrolero occidental.

Requerimientos para la gerencia de proyectos de ingeniería de software.

- Técnicos. - Económicos. - Humanos.

Establecer las fases del modelo gerencial para proyectos de ingeniería de software en las empresas del sector petrolero occidental.

Fases del modelo gerencial para proyectos de ingeniería de software.

- Planificación. - Organización. - Dirección. - Control.

89

Diseñar el modelo gerencial para proyectos de ingeniería de software en las empresas del sector petrolero occidental.

Se alcanza logrando los objetivos anteriores.

Fuente: Borges (2012)