U N I V E R S I D A D A N D I N A
NÉSTOR CÁCERES VELÁSQUEZ
TESIS
E
E
N
N
F
F
O
O
Q
Q
U
U
E
E
D
D
E
E
L
L
P
P
M
M
B
B
O
O
X
X
E
E
N
N
L
L
A
A
D
D
I
I
R
R
E
E
C
C
C
C
I
I
Ó
Ó
N
N
D
D
E
E
P
P
R
R
O
O
Y
Y
E
E
C
C
T
T
O
O
S
S
D
D
E
E
S
S
O
O
F
F
T
T
W
W
A
A
R
R
E
E
E
E
N
N
E
E
L
L
G
G
O
O
B
B
I
I
E
E
R
R
N
N
O
O
D
D
E
E
A
A
Y
Y
A
A
C
C
U
U
C
C
H
H
O
O
,
,
2
2
0
0
1
1
6
6
PRESENTADA POR
EDITH FELICITAS GUEVARA MOROTE
PARA OPTAR EL GRADO ACADÉMICO DE
MAESTRO EN INGENIERÍA DE SISTEMAS
JULIACA – PERÚ
2019
ESCUELA DE POSGRADO
MAESTRÍA EN INGENIERÍA DE SISTEMAS
MENCIÓN: INFORMÁTICA
A Blanca, mi madre, por sus enseñanzas y
ejemplo
A Carlos, mi esposo, por su amor y apoyo
A Arianna, Marcia y Luciana mis hijas, por
ser mi inspiración
A la memoria de Edwin, Noemi, y Yoni, mis
A la Universidad Andina Néstor Cáceres
Velázquez, por darme la oportunidad de
seguir capacitándome y alcanzar un
desarrollo profesional.
Al Gobierno Regional de Ayacucho, por
permitirme contar con información para el
desarrollo de la presente investigación.
A mis amigos y compañeros de trabajo por
brindarme su apoyos.
ÍNDICE
ÍNDICE ... i
RESUMEN ... iii
ABSTRACT... v
INTRODUCCIÓN ... vii
CAPÍTULO I PLANTEAMIENTO DE LA INVESTIGACIÓN 1.1. EXPOSICIÓN DE LA SITUACIÓN PROBLEMÁTICA... 1
1.2. FORMULACIÓN O PLANTEAMIENTO DEL PROBLEMA ... 2
1.2.1. Problema general ... 2
1.2.2. Problemas específicos ... 2
1.3. JUSTIFICACIÓN DE LA INVESTIGACIÓN ... 2
1.4 OBJETIVOS ... 3
1.4.1 Objetivo general ... 3
1.4.2 Objetivos específicos ... 3
CAPÍTULO II MARCO REFERENCIAL 2.1. ANTECEDENTES DE LA INVESTIGACIÓN ... 5
2.1.1. Antecedentes internacionales ... 5
2.1.2. Antecedentes nacionales ... 6
2.1.3. Antecedentes locales ... 7
2.2. MARCO TEÓRICO ... 7
2.2.1 proyecto ... 7
2.3. MARCO CONCEPTUAL ... 41
CAPÍTULO III PROCEDIMIENTO METODOLÓGICO 3.1. DISEÑO DE LA INVESTIGACIÓN ... 85
3.2. MÉTODO DE LA INVESTIGACIÓN ... 86
3.3.1. Población ... 86
3.3.2. Muestra ... 86
3.4. TÉCNICAS, FUENTES E INSTRUMENTOS DE INVESTIGACIÓN ... 87
CAPÍTULO IV
RESULTADOS Y DISCUSIÓN
4.1. DIAGNÓSTICO DE LA SITUACIÓN ACTUAL... 90
4.2 ANÁLISIS E INTERPRETACIÓN DE RESULTADOS ... 91
CONCLUSIONES
SUGERENCIAS
REFERENCIAS BIBLIOGRÁFICAS
RESUMEN
El presente trabajo de investigación consiste en realizar un diagnóstico sobre la
forma en que se desarrolla software en las instituciones u órganos
desconcentrados del Gobierno Regional de Ayacucho más importantes,
mediante este estudio se busca efectuar una comparación de datos
cualitativos y cuantitativos, tomando como base los estándares del Project
Management Institute PMI, relacionadas con las formas de trabajo particulares
que tienen las instituciones públicas del Gobierno Regional de Ayacucho.
Para elaborar la investigación se ha estudiado con sumo detalle la
última versión del PMI-PMBOK quinta edición del 2013, Project Management
Body of Knowledge y las 10 áreas del conocimiento que abarca esta guía, las
cuales son: Integración, Alcance, Tiempo, Recursos Humanos, Costos,
Calidad, Comunicaciones, Riesgos, Aprovisionamiento y Grupos de interés; se
ha enfocado este marco de referencia en la formulación y desarrollo de
proyectos, particularmente los de software que tienen las instituciones públicas,
esto ha sido posible a través de encuestas realizadas basadas en el PMBOK,
entrevistas con los responsables de proyectos software o el personal de las
áreas de Tecnologías de Información.
El trabajo tiene como finalidad realizar un análisis comparativo para
determinar que el enfoque el PMI daría resultados más favorables para las
tradicional en que gestionan la instituciones públicas sus proyectos de
software, estos proyectos serán exitosos en la medida en que sean mejor
controlados, que garanticen cubrir el ámbito definido, respetar los plazos
establecidos, sin exceder el presupuesto planificado, y finalmente entregar un
software que cumpla con las necesidades del usuario y que éste se encuentre
satisfecho con el resultado, además de que el grupo humano haya crecido en
sus conocimientos y sobre todo se encuentre comprometido con el proyecto.
Luego del estudio y demostración se propondrá una nueva forma de
trabajo para la gestión de proyectos software basado en la propuesta del PMI,
se tomará en cuenta las metodologías que actualmente usan las instituciones
públicas con lo cual se propondrá una serie de etapas a seguir y formatos
necesarios basado en el PMBOK, adecuándose a la realidad, necesidad y
dificultad que tienen las instituciones públicas.
Palabras Clave: Project Management Institute, Instituciones Públicas, Project
ABSTRACT
In the present research work a diagnosis is made on how software is developed
in the most important public institutions of the city of Huamanga
with this study, a comparison is made in qualitative and quantitative terms
based on the standards of the Project Management Institute, PMI, against the
particular forms of work that public institutions have.
In order to elaborate the research, the last version of the PMI-PMBOK
fifth edition of 2013, Project Management Body of Knowledge and the 10 areas
of knowledge: Integration, Scope, Time, Human Resources, Costs, Quality,
Communications, Risks , Procurement and Stakeholders; This frame of
reference was focused on the management of software projects that have
public institutions. This has been possible through surveys based on the
PMBOK, interviews with those responsible for software projects or responsible
for the areas of Information Technology.
The purpose of this paper is to perform a comparative analysis to
determine that the PMI approach would give more favorable results for the
institutions as it is formulated in the hypothesis unlike the traditional way in
which public institutions manage their software projects, these projects will be
Successful to the extent that they are better controlled, that guarantee to cover
the defined scope, meet deadlines, or exceed the planned budget, Delivering
quality software, that the user is satisfied with the result and the human group
Delivering quality software, that the user is satisfied with the result and the
human group has grown in their knowledge and above all is committed to the
project.
After the study and demonstration will propose a methodology for the
management of software projects based on the framework of the PMI, will take
into account the methodologies currently used by public institutions, which will
propose a series of steps to follow and necessary formats based In the
PMBOK, adapting to the reality, necessity and difficulty that public institutions
have.
Key Words: Project Managemente Institute, Public Institutions, Project
INTRODUCCIÓN
La aparición y evolución de las Tecnologías de Información están conduciendo
al incremento de proyectos software en las instituciones y se han convertido en
un aliado para lograr ventajas estratégicas; las nuevas tendencias tecnológicas
como son los sistemas de información integrado, los sistemas de
planificación de recursos empresariales más conocidos como ERP, sistemas
de administración de proveedores, de clientes entre otros además del software
que necesitan los diferentes usuarios como son los sistemas operativos,
programas de entretenimiento, sistemas expertos, entre otros; en relación a lo
antes mencionado existen dificultades para gestionar proyectos exitosos de
software o aplicaciones desarrolladas para dar soporte a actividades
específicas en las instituciones, se cuenta con variadas metodologías para el
desarrollo de software empero, es necesario contar con la adecuada gestión de
proyectos software, esta se ha convertido en una disciplina emergente y
necesaria, a fin de que los proyectos sean eficientes.
Nuestro país necesita desarrollar grandes y complejos proyectos de
software para optimizar los procesos de negocio de las instituciones, que
permita a su vez el aumento de su productividad y que finalmente coadyuvara
en el mejor desempeño de sus trabajadores. En este sentido es necesaria la
automatización e integración de todos los procesos en los órganos
denominaremos instituciones públicas, para contar con información precisa en
tiempo real; para llevar a cabo ello, no solo basta con un equipo técnico de
profesionales expertos en desarrollo de software, sino también contar con una
apropiada administración de proyectos que permita definir el alcance
correspondiente, terminando en los plazos establecidos, en el tiempo
propuesto, aumentando la productividad así como cubrir las necesidades de
los usuarios finales.
Según el Instituto de Gestión de Proyectos “La administración de
proyectos provee los conceptos, procesos, técnicas y herramientas para iniciar,
planificar, ejecutar, controlar y cerrar ordenadamente un proyecto” (PMI 2013
pag. 28), asimismo clasifica y adecúa estos conceptos en áreas como:
integración, alcance ó ámbito, tiempo, recursos humanos, costos, calidad,
comunicaciones, riesgos, aprovisionamiento y grupos de interés, proyectos de
cualquier índole pueden ser dirigidos formalmente con las mejores prácticas
que propone esta metodología y con la experticia de los responsables, se
concluye que estas prácticas están agrupadas y ordenadas de modo lógico y
didáctico en los estándares que propone y promueve el Project Management
Institute - PMI.
El presente trabajo de investigación se enfocará básicamente en
comprender la concepción del PMI, para luego desarrollar un análisis
comparativo entre la metodología de dirección de proyectos difundida por PMI y
frente a las metodologías utilizadas por las instituciones públicas de Ayacucho.
El método de recopilación de información de las instituciones públicas
es mediante un cuestionario y las entrevistas necesarias con el fin de hacer las
demostrar las ventajas de trabajar bajo el marco de referencia de PMI y
determinar si los estándares se pueden aplicar a la gestión y dirección de
CAPÍTULO I
PLANTEAMIENTO DE LA INVESTIGACIÓN
1.1. EXPOSICIÓN DE LA SITUACIÓN PROBLEMÁTICA
En la actualidad existen empresas del sector privado dedicados a construir
proyectos de software que se vienen desarrollando a gran escala y con
estándares internacionales, todo ello entre tantos parámetros se debe al trabajo
organizado y a la implantación del uso de enfoques metodológicos como el
enfoque del PMI (Project Management Institute), que, a diferencia de las
instituciones públicas, tienen serias deficiencias en la administración de
proyectos software.
Se eligió la metodología que promueve el PMI, por ser considerada la
organización que más ha contribuido a la adecuada gestión o administración de
proyectos en el mundo, así como la certificación que entrega ha logrado el más
extensivo reconocimiento, la naturaleza del software contribuye que sea
gestionado mediante esta metodología, finalmente se hace una propuesta para
poder gestionar los proyectos de esta naturaleza, usando la guía de los
fundamentos para la dirección de proyectos o guía del PMBOK, por las razones
1.2. FORMULACIÓN O PLANTEAMIENTO DEL PROBLEMA
1.2.1. Problema general
¿Cómo el enfoque del PMBOK influye en la dirección de proyectos de
software en el Gobierno Regional de Ayacucho, 2016?
1.2.2. Problemas específicos
¿Cómo el enfoque del PMBOK contribuye en cumplir el
tiempo adecuado de los proyectos de software en el
Gobierno Regional de Ayacucho, 2016?
¿Cómo el enfoque del PMBOK influye en disminuir los
riesgos asociados a los proyectos de software en el
Gobierno Regional de Ayacucho, 2016?
¿Cómo el enfoque del PMBOK influye en asegurar la
calidad de los proyectos de software en el Gobierno
Regional de Ayacucho, 2016?
1.3. JUSTIFICACIÓN DE LA INVESTIGACIÓN
La propuesta del presente trabajo nace de la motivación de conocer la
forma en que administran los proyectos de software en el Gobierno
Regional. Debido a la información recopilada y también por la sensación
que se percibe de ineficiencia en la gestión de proyectos de software, en
nuestra región se necesita desarrollar grandes y complejos proyectos de
software para optimizar los procesos de negocio de estas instituciones, que
permita a su vez el aumento de su productividad, lo que implicaría
bienestar a la región. En ese sentido seria apropiada la automatización e
esa manera todos los procesos estarían integrados y en línea, teniendo la
información precisa en tiempo real. Para llevar a cabo ello, no solo basta
contar con un equipo técnico de profesionales expertos en desarrollo de
software, sino también contar con una apropiada gestión de proyectos que
permita definir el alcance correspondiente, terminando en los plazos
establecidos, con el tiempo propuesto, aumentando la productividad de las
instituciones del estado en general y la satisfacción de la población.
Se ha elegido la metodología del enfoque del PMBOK que
promueve el “Project Management Institute” por ser considerada la
institución que más ha contribuido a la adecuada gestión o administración
de proyectos en el mundo, y la certificación que entrega es la que ha
logrado el más extensivo reconocimiento.
1.4 OBJETIVOS
1.4.1 Objetivo general
Determinar la influencia del PMBOK en la dirección de proyectos de
software en el Gobierno Regional de Ayacucho, 2016
1.4.2 Objetivos específicos
Demostrar que el enfoque del PMBOK contribuye en
cumplir el tiempo programado de los proyectos de
software en el Gobierno Regional de Ayacucho, 2016
Demostrar que el enfoque del PMBOK influye en disminuir
los riesgos asociados a los proyectos de software en el
Demostrar que el enfoque del PMBOK influye en
garantizar la calidad de los proyectos de software en el
CAPÍTULO II
MARCO REFERENCIAL
2.1. ANTECEDENTES DE LA INVESTIGACIÓN
2.1.1. Antecedentes internacionales
TÍTULO:
“DIRECCIÓN DE PROYECTOS DE SOFTWARE DESDE LA
METODOLOGÍA PMBOK”
AUTOR: Diego Rios Herrera Navarro AÑO: 2016
CONCLUSIONES:
En este trabajo de investigación realizado en la Universidad de
Pereira, Colombia, tiene como objetivo relacionar las
similitudes la metodología PMBOK y la ingeniería de software,
debido a que los proyectos tienen similitudes en cuanto a sus
necesidades y los nuevos productos software pueden ser
considerados como proyectos y que estos puedan ser
atendidos desde las distintas áreas de conocimiento que
plantea el PMBOK, las mismas lo cual significa que coincide
en forma general en que se puede aplicar conocimientos,
en su conjunto pueden incrementar las posibilidades de éxito e
todo tipo de proyectos, dentro los cuales se podría considerar
los proyectos de desarrollo de software, finalmente se concluye
que todo lo planteado por el PMBOK se podría considerar
como un estándar aplicable a nivel mundial en razón de que los
profesionales de esta y otras áreas tienen un modo de vida
diferente, en el cual se incluye su cultura y todo lo acontece en
su entorno.
2.1.2. Antecedentes nacionales
TÍTULO:
“
ENFOQUE DEL PROJECT MANAGEMENT INSTITUTE(PMI) EN LA ADMINISTRACIÓN DE PROYECTOS DE
SOFTWARE EN LOS MUNICIPIOS DE LIMA 2014
AUTOR: Eriber Enciso Navarro AÑO: 2014
CONCLUSIONES:
En este trabajo de tesis se ha podido evidenciar que las
Municipalidades de Lima Metropolitana están a un nivel de
gestión mediano a inferior, pero esta tendencia no es uniforme
en todas las áreas de gestión. Por otro lado no existe una
adecuada integración en el trabajo de los proyectos, es variable
y depende principalmente de la forma de trabajo y de la
incipiente metodología que se maneja, además existen
cumplen con los cronogramas, no se controlan los costos
constantemente, carecen de capacitaciones constantes y
motivación al personal. Y Finalmente de que es posible adaptar
el enfoque del PMI en las Municipalidades
2.1.3. Antecedentes locales
No se han encontrado antecedentes a nivel local
2.2. MARCO TEÓRICO
2.2.1 proyecto
Un Proyecto es el resultado de un esfuerzo temporal, este resultado
puede ser un producto, un servicio , por su naturaleza temporal el
proyecto tiene una fecha de inicio y fecha de final definidos; el
proyecto termina cuando se lograron sus objetivos, cuando estos no
se cumplen o cuando existen dificultades para ser cumplidos, o
cuando ya no se tiene la necesidad que dio origen al proyecto, se da
por finalizado el proyecto cuando el cliente lo decida; la temporalidad
en elaborar el proyecto no se aplica al producto o servicio resultante.
De acuerdo, a las lecturas de las variadas bibliográficas utilizadas
en este trabajo se concluye que los proyectos se dan cuando surgen
nuevas actividades, en el que se incluyen mejoras. Los proyectos
cuentan con cronograma, tienen inicio y fin, cuentan con objetivos
específicos, entregables y sobre todo son únicos.
Relacionado al concepto de los proyectos están los programas,
estos agrupan proyectos que tengan algo en común, y que pueden
Finalmente es en relación el concepto de los portafolios que
vienen a ser agrupan a algunos programas, proyectos y que pueden
tener o no alguna relación. La persona que maneja un portafolio
recibe diferente denominación de acuerda a la institución para la
cual trabaja y en relación al nivel jerárquico.
Es necesario hacer referencia a los conceptos antes mencionados
debido a que en nuestro país se resuelven muchos problemas en
todas las áreas que son responsabilidad del estado peruano
mediante proyectos, y se quiere que estas soluciones se den en
menos tiempo deberían resolverse los problemas relacionados a la
información, que es insumo esencial de los proyectos los cuales
serán encaminados mediante proyectos de software.
2.2.2 Dirección de proyectos
La gestión o dirección de proyectos se define como la
implementación de conocimientos, habilidades, herramientas y
técnicas a las actividades que están relacionadas con el proyecto,
que permita cumplir con los requisitos de este. Se puede lograr de
muchas formas una de ellas es mediante la aplicación e integración
adecuadas de los procesos de la dirección de proyectos, que están
ordenados de manera lógica, estos 47 procesos están categorizados
en cinco grupos. Los grupos son:
• Inicio,
• Planificación,
• Monitoreo y Control, y
• Cierre.
2.2.2. Proyecto software, concepto, características
El desarrollo de software requiere de muchos esfuerzos entre sus
características esta definido en el tiempo desde su concepción hasta
crear un único producto intangible, servicio o resultado.
2.2.2.1 Características
Temporal: Se refiere a que cada proyecto de software tiene
fecha de inicio y termino. Un proyecto termina cuando se
alcanzaron los objetivos del mismo cuando se tiene claro que
no se alcanzarán o la necesidad para el proyecto no existe
más y por ende el proyecto termina.
Único producto, servicio o resultado: Un proyecto de software
crea productos o resultados únicos y entregables.
Elaboración Continua: Es una característica del proyecto que
acompaña los conceptos de temporalidad y unicidad. Se
refiere a desarrollar por pasos y garantizar la continuidad de
forma progresiva.
2.2.2.2 Proceso para el desarrollo de software
Existen muchos modelos o metodologías a seguir para el desarrollo
de software, basados de algún modo en el ciclo de vida, cada uno de
estos modelos describe diferentes enfoques para definir sus
actividades o tareas necesarias que se llevan a cabo durante todo el
proceso. Por otro lado, la mayoría basa su metodología en el ciclo
los procesos necesarios para el desarrollo de software. Entre otros
modelos hay varios procesos de desarrollo de software específicos
que se ajustan a un modelo de ciclo de vida y además que es de tipo
espiral.
Las diferentes necesidades que tienen las organizaciones en
relación a la información hacen que se recurran a diversas
metodologías de desarrollo de software, sin importar el área en el
cual se desempeñan estas. Un estándar internacional que regula el
modo de selección, implementación y seguimiento del ciclo de vida
del software es la norma ISO 12207 (International Standard
Organization-12204) (Calero, 2010).
A pesar de que durante mucho tiempo las organizaciones se han
preocupado en estandarizar el desarrollo de software y encontrar
procesos que se pueden repetir y anticipar con la finalidad de que
mejoren la productividad y la calidad, aún no se ha logrado, sin
embargo algunas de estas soluciones tienen como fin sistematizar o
formalizar la aparente desorganización en el proceso de desarrollar
software, en otros casos se recurren a otras técnicas o
metodologías que permitan la creación del software. Una las razones
de proyectos no exitosos en esta área es que, sin una gestión o
adecuada administración, los proyectos de software corren el riesgo
tomar más tiempo del previsto o consumir más recursos de los que
se ha planeado. Por lo que se concluye que teniendo conocimiento
funcionalidad, costos o cronograma de entrega, es necesario contar
con una gestión de proyectos más efectiva.
Algunas organizaciones consideran conveniente crear un grupo
propio (Software Engineering Process Group, abreviado SEPG) que
sería el grupo de personas responsables de mejorar los procesos
para el desarrollo de software en su empresa.
2.2.2.3 Actividades del desarrollo del software
2.2.2.3.1 Planificación
Es importante llevar a cabo una tarea importante cuando se va
crear un producto software y que es anticiparse a las acciones que
se deberán realizar, estimar los recursos necesarios y conocer
los requisitos que tienen los usuarios, ellos suelen tener una idea
subjetiva del resultado final, pero no pueden hacer una precisión
sobre las funciones que debería tener el software.
Una vez que se ha conversado y recopilado las necesidades del
usuario, mediante entrevistas, encuestas, el equipo responsable del
desarrollo debe realizar un análisis y plasmar todo lo que el usuario
requiere en un documento que se le conoce finalmente como
2.2.2.3.2 Implementación, pruebas y documentación
En la siguiente etapa del proceso, los programadores elaboran el
código para el proyecto. Mediante las pruebas podrán detectar
los errores de software para sus respectivas correcciones lo antes
posible, esta etapa esencial en proceso de desarrollo del software.
Esta es la etapa para elaborar los documentos del diseño interno
del software, con la finalidad de que cuando sea necesario se podrá
facilitar su mejora y mantenimiento, cubre todo el proyecto. Esto
Incluye también la documentación para el área de sistemas y para el
usuario final.
2.2.2.3.3 Despliegue y mantenimiento.
Esta etapa es después de las pruebas necesarias y suficientes en
el entorno de producción.
El entrenamiento es de suma importancia y algo que los
desarrolladores de no deben descuidar. La preocupación de los
usuarios es que puedan ser reemplazados y se oponen al cambio lo
que genera inseguridad, es por esta razón que es fundamental y se
debería orientar y capacitar al usuario de forma adecuada, didáctica
y amigable a los usuarios finales del software.
La etapa de mantenimiento y mejora del software depende de la
forma en que ha sido concebido en algunos situaciones puede
requerir más tiempo que el planificado en la etapa inicial del
software. De repente será necesario corregir código que no se ajusta
del cliente, solucionar un problema o ampliar el requisito de un
cliente, o también se puede recurrir a algunas librerías que
previamente hayan sido elaboradas por los programadores.
2.2.2.4 Paradigmas para el desarrollo del software
2.2.2.4.1 Paradigma Tradicional
También le podemos llamar metodología, y es uno de los
modelos más antiguos, se inventó durante la creación del método
estructurado. Al elegir un proyecto el método aplicado varía en
etapas. Como todo modelo existen sus pros y contras; al usar
este paradigma, algunas de las dificultades es que se tiene pasos
bien definidos y que no se debe realizar alguna modificación
porque puede ser que el software no cumpla con su ciclo de vida.
Tabla 1
Ventajas y Desventajas del uso del Paradigma Tradicional
2.2.2.4.1 Paradigma Orientado a objetos
Este modelo está basado en la metodología de la programación
orientada a objetos, nueva forma de programación; por lo tanto,
se tiene que conocer el concepto de clase, además del análisis de
requisitos y el diseño necesario. Posee dos características:
Permite reutilizar software
Está basado en un lenguaje unificado para el
modelado, que es una notación gráfica y que da
apoyo al desarrollo, además de es simple.
2.2.2.4.1 Paradigma Agil
Es un modelo de desarrollo basado en procesos ágiles o de
menor complejidad. Estos se usan en lugar de las metodologías
tradicionales que avécese resultan muy complejas, enfocándose
en los usuarios y los resultados que ellos esperan del producto.
Esta basado en un enfoque en el valor para desarrollar software
de forma más rápida, es adecuado para proyectos de software de
poca complejidad, de manera que se le hace demostraciones
frecuentes al cliente para poder incorporar cambios cuando sean
necesarios.
2.2.2.5 Modelos para el desarrollo del software
Los modelos de desarrollo de software son de por sí invisibles al
igual que el producto final que se obtiene. Realmente dan las pautas
modificados y adaptados de acuerdo con las necesidades que tiene
el usuario del software y las necesidades que surgen en el proceso
de desarrollo. Existen varios modelos para perfilar el proceso de
desarrollo, cada uno de los cuales cuenta con ventajas y
desventajas, como en todo escenario. Los responsables del proyecto
deberán escoger el más apropiado para sus necesidades y contribuir
además con la experiencia que obtienen a lo largo de su experiencia
profesional. En situaciones especiales seguramente lo más
apropiado será la combinación de varios modelos.
2.2.2.5.1 Modelo en cascada
A esta metodología de desarrollo en cascada, se le denomina así
por la posición que tienen las fases necesarias de este modelo, esta
metodología ordena rigurosamente las etapas del proceso para el
desarrollo de software, se debe finalizar una etapa lo que dará inicio
a la siguiente. Al final de cada etapa se debe llevar a cabo una
revisión final, con lo cual se va a saber si el proyecto está listo para
pasar a la siguiente fase. Este modelo se considera como el primero
y es la base de todos los demás modelos.
La versión inicial que es el origen fue propuesta por Winston W.
Royce en 1970 y posteriormente revisada por Barry Boehm en 1980
e finalmente por Ian Sommerville en 1985. Las etapas de este
modelo son:
a. Análisis de Requisitos: Es la fase inicial y en ella se
desarrollo del software para determinar qué objetivos serán
tomados en cuenta. En esta fase se obtiene un documento
llamado especificación de requisitos, que contiene las
especificaciones de forma completa de lo que debe hacer el
sistema sin necesidad de especifica los detalles internos.
Quienes van a obtener la información de los usuarios lo debe
hacer de forma clara, ya que esta información será tomada
en cuenta en las siguientes fases.
b. Diseño del Sistema: Luego de haber elaborado la
especificación de requisitos se separa el sistema en
elementos que si es necesario puedan elaborarse
independientemente, teniendo en cuenta que tiene muchas
ventajas el desarrollo en equipo. En esta etapa se elabora el
diseño del software desde el punto de vista del programador,
contiene la descripción de la estructura relacional de todo el
sistema y la especificación al detalle de lo que deberá hacer
cada uno de sus componentes que previamente se han
organizado, la manera en que se relacionan unos con otros.
Se recomienda diferenciar el diseño de alto nivel o
arquitectónico y el diseño detallado; el de alto nivel tiene
como objetivo definir la estructura de la solución al problema
identificado, que en la fase anterior se ha entendido el
problema, y se han identificado grandes módulos o grupos de
funciones que van a estar asociadas y las relaciones que
la solución más conveniente, mientras que el diseño
detallado permite definir los algoritmos empleados y como se
debe separar el código para comenzar la etapa de
implementación.
c. Diseño del Programa: En esta etapa se plasman las
soluciones en los algoritmos que sean necesarios para
cumplir con los requerimientos del usuario y también poder
determinar las herramientas que serán más convenientes de
usar en la siguiente etapa de codificación.
d. Codificación: Es la fase en donde se elaboran lo programas
o código, por lo general usando prototipos, realizando
pruebas y ensayos para corregir errores. Los resultados
esperados dependen del lenguaje de programación y la
experticia de los programadores, en algunos casos se crean
las bibliotecas y componentes que pueden volver a ser
utilizados dentro del mismo proyecto para hacer que la
programación sea un proceso mucho más ágil.
e. Pruebas: Los programas elaborados en la etapa anterior, se
unen para formar parte del sistema y se comprueba su
funcionamiento correcto y sobre todo que se cumplan los
requisitos, antes de ser entregados al usuario final.
f. Implantación: Es la fase en que el usuario final ejecuta el
sistema, con datos reales mediante la migración de sistemas
programadores han estado realizando pruebas, para corregir
y que el sistema no falle.
g. Mantenimiento: Esta etapa final a veces es una de las
etapas más críticas, ya que se destina un muchos de los
recursos, ya que ser operado por el usuario final puede ser
que no cumpla con todas las expectativas, y se va a tener
que regresar a etapas anteriores.
Figura 1: Modelo de Cascada. En Ingeniería del Software (p. 30) por
I. Sommerville (2011).
2.2.2.5.2 Modelo en espiral
Se tiene como autor de este modelo a Barry Boehm que propone
este modelo en el año 1988. Consiste en una serie de ciclos o
iteraciones que se repiten en forma de espiral, dando inicio desde el
centro. Dentro de cada ciclo de la espiral se sigue un Modelo
necesariamente debe ser así. El espiral puede verse como un
modelo que va evolucionando de acuerdo con la naturaleza iterativa
que propone Boehm y que se toma en cuenta los aspectos
controlados y sistematizados del Modelo en Cascada que requiere
se finalice una etapa para dar inicio a la siguiente, tomando también
la gestión de riesgos.
2.2.2.5.2.1 Ciclos o iteraciones
Para el modelo en espiral en cada ciclo o iteración hay que tener en
cuenta, lo siguiente:
a. Los objetivos, en el que se describe la necesidad que debe
cubrir el producto software; las alternativas, y diferentes
formas de poder alcanzar los objetivos de forma exitosa en
los que sebe tener en cuenta, lo siguiente:
Características: que incluye la experiencia del personal, y
los requisitos que se van a cumplir, etc.
Maneras de administración del sistema.
Riesgo asociado con cada una de las alternativas.
b. Desarrollar y verificar: Elaborar el código del software, así se
detecta si el resultado no es el deseado o se requiere
implementar algunas mejoras o nuevas funcionalidades:
De ser necesario se planificarán los siguientes pasos y
se comienza nuevamente el ciclo de la espiral. La
espiral forma círculos concéntricos y se dice que
Angular: Esta dimensión de la metodología,
indica cuanto se ha avanzado del proyecto
software dentro de un ciclo.
Radial: Con esta dimensión se determinará si se
produjo incremento del costo del proyecto, ya
que cada nueva iteración requiere más tiempo,
porque va en aumento.
Este modelo de ciclos o iteraciones es muy utilizado cuando los
proyectos de software son grandes y complejos como podría ser la
creación de un sistema operativo o algo similar. Es también
considerado como un modelo de Ciclo de Vida orientado a la gestión
de riesgo se dice que uno la experiencia y competencia del equipo
encargado para detectar y catalogar correctamente los riesgos
garantizara su éxito.
a. Tareas: Para cada ciclo se tendrá que desarrollar cuatro
actividades:
Determinación de objetivos
Análisis de riesgo
Desarrollo y prueba
Figura 2: Modelo en Espiral. En Ingeniería del Software (p. 49) por
I. Sommerville (2011).
b. Determinar o fijar objetivos
Determinar los productos que se van a obtener:
requerimientos, manual de usuario y especificación.
Determinar las restricciones.
Identificar los riesgos del proyecto y las estrategias
alternativas para enfrentarlos o evitarlos.
Realizar por única vez: planificación inicial, desarrollar,
verificar y necesariamente validar.
Fijar las tareas relacionadas con la actividad propia de las
Realizar el análisis de alternativas y la identificación de las
acciones necesarias para actuar en caso de que los
riesgos hayan ocurrido.
Después de la evaluación de los riesgos, se elige el modelo
de preferencia para el desarrollo, este modelo puede ser
cualquiera de los otros existentes, los que hemos referido,
el formal, evolutivo, cascada, o cualquier otro; si se
identifican riesgos en la interfaz de usuario como
dominantes, el modelo apropiado podría ser la construcción
de prototipos evolutivos y luego validados por los usuarios.
Si los riesgos de protección son los más frecuentes,
entonces sería conveniente recurrir a una alternativa más
apropiada a la situación dada.
c. Análisis del riesgo: Se lleva a cabo mediante el estudio de las
causas de las posibles amenazas y probables eventos no
deseados, los daños y consecuencias que estas puedan
producir, la vulnerabilidad de algunos de sus componentes, entre
otros aspectos. Es necesario identificar alternativas y evaluarlas.
Se propone formular un prototipo antes de comenzar a
desarrollar y hacer las pruebas necesarias, se debe considerar
todos los escenarios posibles de riesgo de modo que puedan
prevenirse, detectarse o acciones a realizar en caso hayan
2.2.2.5.3 Modelo del desarrollo iterativo y creciente.
Debido a que el proceso de cascada tradicional presenta algunas
debilidades se creó el modelo de Desarrollo iterativo y creciente (o
incremental). El fundamento básico de este modelo de desarrollo es
que agrupa un conjunto de tareas en pequeñas tareas repetitivas o
iteraciones, además esta relacionado con novedosas estrategias
para el desarrollo de software y esto hace que en los últimos tiempos
sea uno de los más utilizados junto a una programación extrema.
Análogamente a otros modelos consta de diversas etapas de
desarrollo en cada incremento o iteración, teniendo como punto de
partida el análisis y finaliza con la instalación, adecuación y
aprobación del sistema.
Como dato adicional es necesario precisar que este modelo se basa
en dos premisas, que se supone siempre se dan:
La ambigüedad que tienen los usuarios debido a que nunca
saben bien que es lo que requieren para satisfacer sus
necesidades.
Por otro lado, durante el desarrollo la duda justificada en la
primera premisa genera que los procesos tienden a cambiar.
El proceso en sí mismo consiste en las siguientes etapas:
Inicialización
Iteración
a. Consideraciones sobre el momento de aplicación
Es necesario tomar en cuenta algunos aspectos para poder
seleccionar la metodología mediante la cual se dará soporte
al ciclo de vida desarrollo de software, en ese contexto se
debe considerar que para integrar la facilidad de uso cuando
se desarrolla, no es suficiente con asignar técnicas
relacionadas a la usabilidad, debido a que no todas las
técnicas son aplicables en cualquier momento en un
desarrollo iterativo, por este motivo se debe tomar en cuenta
que las técnicas para desarrollar el producto software están
concebidas para su aplicación en las primeras actividades del
desarrollo, cuando se identifican las necesidades, es decir en
las tareas iniciales, además que el esquema general del
sistema se establece, al igual que otros modelos se debe
hacer un trabajo cuidadoso en la etapa de análisis, y cuando
sea necesario es recomendable hacer las modificaciones
necesarias, para obtener un producto más refinado.
Luego de hacer referencia a las consideraciones, se hace una
pequeña explicación que corresponde al modelo de desarrollo
iterativo y creciente.
b. Etapa de inicialización
En esta etapa se desarrolla una versión inicial del producto
software. Esta etapa tiene como objetivo desarrollar un
en usarlo. Como toda etapa inicial debe dar a conocer una
muestra de los aspectos claves del problema y proveer una
solución lo bastante simple para ser usado y que sea
implementada con facilidad. Es necesario crear una lista de
control del proyecto, que contenga un historial de todas las
tareas que necesitan ser implementadas, con lo cual se podrá
guiar el proceso de iteración. Además, se podra incluir nuevas
funcionalidades que requieran ser implementadas, y áreas
que deben ser rediseñadas de la solución que ya existe. Esta
lista de control es necesario que sea frecuentemente revisada
como resultado de la fase de análisis.
c. Etapa de iteración
En esta etapa se hace el análisis de la versión más reciente
del sistema además involucra el rediseño cuando sea
necesario y la implementación de una tarea de la lista de
control de proyecto que previamente se ha elaborado. El
objetivo del rediseño e implementación de cualquier iteración
debe ser simple, directa y modular, para poder dar paso al
rediseño de la etapa o como una tarea añadida a la lista de
control de proyecto. En la mayoría de los casos el código
representa la mayor fuente de documentación del sistema. Es
fundamental la retroalimentación de parte del usuario además
del análisis de las funcionalidades que estén disponibles en el
también el análisis de la estructura, así como la modularidad,
la facilidad de uso, la confiabilidad, así como la eficiencia y
eficacia necesarias. A continuación, reiterativamente la lista
de control del software que se desarrolló en la etapa anterior
será modificada de acuerdo con los resultados del análisis.
Las guías primarias que contienen la implementación y el
análisis se incluyen:
Cuando existen dificultades en el diseño, codificación y
prueba para su modificación se deberá tomar nota de la
necesidad de rediseñar o volver a hacer el código.
Las modificaciones deben orientarse a los módulos fáciles de
encontrar y también a los que están aislados. Si no fuera
posible entonces se requiere un rediseño.
Se debe aplicar el rediseño necesario cuando las
modificaciones a las tablas son complicadas.
Cuando avanzan las iteraciones las modificaciones deben ser
más fáciles de realizar. Si no fuese así, hay un problema
primordial como consecuencia de un diseño débil o en que
existen muchos parches en el sistema.
Los parches deben estar presentes dolo en una o dos
iteraciones.
La implementación existente debe ser analizada
frecuentemente para determinar qué tal se ajusta a las metas
Para ayudar en el análisis de implementaciones parciales se
deben utilizar las facilidades con las que se cuenta para
analizar el programa.
Es importante tomar en cuenta la opinión del usuario para
identificar deficiencias en la implementación con el fin de
corregirlas a tiempo.
2.2.2.5.4 Modelo del desarrollo del prototipo
Existen muchos aspectos que aún no están del todo estandarizadas
relacionadas al desarrollo de software, a este echo y al que las
empresas tienen sus particularidades, se agrega las restricciones en
las instituciones publicas mediante normas u otras disposiciones, es
que existen diferentes modelos y las necesidades que tienen las
empresas y los conocimientos de los responsables determinan el
modelo más adecuado. En este contexto el modelo por prototipos se
convierte en una alternativa para proyectos pequeños y que los
usuarios puedan verificar in situ las funcionalidades que tiene el
software
“Un prototipo es una versión inicial de un sistema de software que
se usa para demostrar conceptos, tratar opciones de diseño y
encontrar más sobre el problema y sus posibles soluciones. El
rápido desarrollo iterativo del prototipo es esencial, de modo que se
por anticipado con el prototipo durante el proceso de software”
(Sommerville 2011 pag. 45).
Mediante un prototipo de software se podrá a anticipar los
cambios que puedan surgir y los usuarios luego de verificar tengan
más claras las ideas de lo que requieran, Por esta razón se puede
concluir que :
En la etapa de determinar los requerimientos, un prototipo ayuda
con la selección y validación de estos de acuerdo con las
demostraciones que se presentan a los usuarios y lo que ellos
desean del sistema.
En la siguiente etapa que es el proceso de diseño de sistemas, un
prototipo va a permitir buscar soluciones específicas de software y
va a contribuir en el diseño de interfaces que sean más amigables
con el usuario.
Figura 3: Modelo de desarrollo de Prototipo. En Ingeniería del Software (p.
45) por I Sommerville (2011).
2.2.2.5.5 Modelo del desarrollo de entrega incremental
Este modelo de desarrollo incremental “es un enfoque al desarrollo
de software donde algunos de los incrementos diseñados se
entregan al cliente y se implementan para usarse en un entorno
operacional, los clientes identifican, en un bosquejo, los servicios
que proporciona el sistema, identifican cuáles servicios son más
importantes y cuáles son menos significativos para ellos”
(Sommerville 2011 pag. 47).
Una vez que los usuarios que las modificaciones necesarias
mediante los llamados incrementos del sistema se explican con
detalle los requerimientos de los servicios que se van a entregar en
el primer incremento, y se implementa ese incremento. En la etapa
de desarrollo, puede haber un mayor análisis de requerimientos para
incrementos posteriores, aun cuando en algunos casos se rechacen
cambios de requerimientos para el incremento actual. Una vez que
se ha completado y entregado el incremento, los clientes lo ponen
en uso. Esto explica que toman la entrega anticipada de la
funcionalidad parcial del sistema. Pueden hacer pruebas directas
con el sistema lo que les ayuda a clarificar sus requerimientos, para
posteriores incrementos del sistema. A medida que se completan
nuevas modificaciones, se integran con los incrementos existentes,
de modo que con cada incremento entregado mejore la
Figura 4: Modelo Entrega Incremental. En Ingeniería del Software (p. 47) por
I. Sommerville (2011).
2.2.2.5.6 Modelo de proceso unificado racional
El Proceso Unificado Racional (RUP, por las siglas de Rational
Unified Process), Krutchen (2003)es un “modelo de proceso
moderno que se derivó del trabajo sobre el UML (Unified Modeling
Language) y el proceso asociado de desarrollo de software unificado
(Rumbaughet 1999 Arlow y Neustadt, 2005)”. Aquí se incluye una
descripción: “Pues es un buen ejemplo de un modelo de proceso
híbrido, junta elementos de los modelos de procesos genéricos,
ilustra la buena práctica en especificación y diseño, apoya creación
de prototipos, entrega incremental” (Sommerville 2011 pag. 50).
Además, que el RUP sabe que los modelos de proceso
convencionales presentan una única visión del proceso, esta
Mediante una perspectiva dinámica, muestra las fases del
modelo a través del tiempo.
Mediante una perspectiva estática, presenta las actividades
del proceso.
Mediante una perspectiva durante el proceso sugiere las
prácticas más adecuadas.
Todos los modelos incluye las diferentes fases desde la
determinación de requerimientos o necesidades que los usuarios
tiene en el área para la cual se va a desarrollar el software, hasta la
entrega y adaptación a la nueva forma de trabajo, en el caso del
RUP se resume en de cuatro fases:
Concepción: En esta fase se identifican todos los involucrados
dentro y fuera de la empresa, la no relevancia puede anular la
elaboración del software.
Elaboración: Se identifica el alcance, se establece el marco
conceptual, se plantea el diseño y se identifican los riesgos
asociados.
Construcción: En esta fase se elabora el diseño, se
desarrollan los programas separadamente, así como las
pruebas necesarias, y se debe finalizar con un software
completo, integrando los programas que se han desarrollado
en uno solo.
Transición: Esta fase es poner el funcionamiento el software
Figura 5: Fases en el Proceso Unificado Racional. En Ingeniería del Software
(p. 51) por I. Sommerville (2011).
2.2.2.5.7 Modelo del desarrollo agil
El desarrollo ágil de software esta constituido por modelos de
ingeniería del software que están basados en el modelo de
desarrollo iterativo e incremental, que arriba hemos descrito, en este
modelo mediante la colaboración de grupos organizados y
multidisciplinarios que incluye a los usuarios finales los requisitos y
soluciones evolucionan.
Existen varios métodos de desarrollo ágil; la mayoría esta
orientada a minimizar riesgos desarrollando software en tiempos
oportunos, el software entregable cuando se desarrolla en un
determinado tiempo se le llama iteración, el cual no debe exceder de
cuatro semanas. En cada iteración del ciclo de vida se debe
considerar las siguientes etapas: fase de planificación, como
siguiente la fase de análisis de requisitos, a continuación, el diseño,
luego la elaboración de programas o codificación, la verificación o
revisión y finalmente la documentación. En la iteración se debe
producto al usuario final, lo que se busaca es obtener una prueba sin
errores como resultado de cada iteración. Es recomendable que al
final de cada iteración el equipo vuelva a evaluar los requisitos
primordiales que tiene el proyecto.
Como su nombre indica los métodos agiles garantizan las
comunicaciones face to face en lugar de manuales o guías. Se
recomienda que mayoría los equipos que utilizan esta metodología
se ubiquen en una oficina con acceso a los usuarios, y esta debe
incluir verificadores, responsables de la documentación y ayudas
necesarias, diseñadores de iteración y responsables de proyecto.
Los métodos ágiles también resaltan que el software funcional es la
primera medida del avance. Con frecuencia se hace criticas a los
métodos ágiles son y con falta de disciplina a la falta de
documentación técnica.
Tabla 2
Los Principios de los Métodos Agiles
A. Métodos Agiles: Algunos métodos ágiles de desarrollo de
software:
Desarrollo de Software Adaptativo (ASD).
Proceso Unificado Agil (AUP).
Claro como el Cristal.
Proceso Unificado Esencial (EssUP).
Desarrollo Impulsado por Características (FDD).
Desarrollo de Software Aprendido (LSD).
Kanban.
Proceso Unificado Abierto (OpenUP).
Programación Extrema (XP)
Método de desarrollo de sistemas dinámico (DSDM)
Scrum.
G300.
2.2.2.6 Que es la administración del proyecto software?
En la administración de un proyecto software es necesario aplicar
conocimientos, contar con habilidades, y hacer uso de herramientas
y técnicas a las actividades inherente del proyecto, con el fin de
determinar los requerimientos del proyecto software, hacer su
análisis, planeamiento, ejecución y control de este. La gestión o
dirección también se define como un proceso dinámico y coherente
que utiliza los recursos que tiene la organización de un modo
organizado y controlado con el fin de lograr objetivos definidos. La
e integración de los procesos conocidos de la administración de
proyectos (inicio, planeación, ejecución, monitoreo, control y cierre).
La responsabilidad en hacer cumplir los objetivos del proyecto recae
en el administrador de proyectos.
Administrar un proyecto incluye:
a. Identificar requerimientos
b. Fijar objetivos claros y el alcance
c. Balancear las demandas de la competencia para los
siguientes factores del proyecto: (calidad, alcance, tiempo y
costo).
d. Adecuar las especificaciones, los planes y alcance a las
diferentes inquietudes y expectativas de los stakeholders
e. Ejecución del plan del proyecto.
f. Ejercer un control continuo en las fases del ciclo de vida del
proyecto.
La experiencia de los administradores de proyecto considera que
existen tres dificultades como son el alcance, el tiempo y el costo
en administrar los requerimientos. La calidad del proyecto es
afectada a través del balance de estos tres factores. La alta
calidad de los proyectos se caracteriza en crear el producto
requerido, servicio o resultado dentro del alcance, tiempo y
presupuesto planificado. Si uno de estos tres factores cambia,
afecta al otro. Los administradores de proyectos también
administran proyectos en respuesta a incertidumbres. El equipo
administra a un mayor nivel de detalle. Muchos procesos de la
administración o gestión de proyectos son iterativos por la
necesidad de elaboración progresiva desde el inicio hasta el
término de un proyecto.
Se dice administración de proyectos cuando se describe un
enfoque organizacional de proyectos y algunas operaciones
progresivas, la organización que recurre a este enfoque, identifica
sus actividades como un proyecto. No necesariamente significa
que todas las actividades pueden o deben ser organizadas
siempre como proyectos. La aceptación de administración a
través de proyectos está relacionada con un proceso cultural de
implantación.
1. Stakeholders: Son las personas u organizaciones que ven
afectadas positiva o negativamente con los resultados del o
aquellas cuyos intereses están vinculados de algún modo a la
ejecución del proyecto.
Dirigir las expectativas de las entidades y personas involucradas
puede ser difícil debido a que suelen tener objetivos muy
diferentes que pueden entrar en conflictos. Las entidades claves
de un proyecto son:
El director del proyecto
El cliente, el usuario (hay varios tipos)
La organización ejecutora (consultora que desarrolla)
Patrocinador (enlace entre el cliente y el va a realizar el
2. Habilidades de un administrador de proyecto
Liderazgo: Es la habilidad que asume quien se encarga de la
dirección del trabajo, desarrolla la visión del futuro y sus
estrategias. Sitúa a los demás comunicando la visión y motiva
e inspira a los miembros de su equipo.
Comunicación: Capacidad de plasmar sus ideas de forma
clara, compleja y sin ambigüedades, de modo que el receptor
lo reciba correctamente. La comunicación puede ser oral,
escrita, interna, externa, formal. Informal, horizontal o vertical.
Negociación: Implica dialogo con otras personas para poder
llegar a acuerdos pueden negociarse directamente o con
ayuda, para llegar a un resultado mediante la negociación se
puede recurrir a un acuerdo común mediante la participación
de un tercero como árbitro.
Resolución de problemas: Esta relacionado a la sinergia
entre la de la definición del problema y la toma de decisiones.
Para lo primero se necesita distinguir entre causas o
síntomas, mientras que la toma de decisiones incluye el
análisis del problema para identificar alternativas orientadas a
solucionar el problema y la elección de las más adecuada en
el momento oportuno.
2.2.2.7 Procesos en administración de proyectos software
Los proyectos están compuestos por diferentes procesos, a una
Las acciones y por ende los procesos van a interactuar a lo largo de
la vida de un proyecto. Los procesos se organizan en grupos de:
Iniciación.
Planeación.
Ejecución.
Seguimiento y control.
Cierre.
1. Procesos de iniciación
1.1 Desarrollo de la constitución del proyecto.
1.2 Desarrollo de la declaración del alcance preliminar del
proyecto.
2. Procesos de planificación
2.1 Desarrollo del plan de administración del proyecto
2.2 Planeación del alcance
2.3 Definición del alcance
2.4 Creación del WBS (Work Breakdown Structure), para el PMI,
“es un documento que descompone el alcance o producto
resultante del proyecto en los paquetes de trabajo individuales
que lo componen y permiten llegar a él, incluyendo aquellos
relativos a la propia gestión del proyecto” (Project
Management Instiute, 2013, p. 66).
2.5 Definición de actividades
2.6 Secuencia de actividades
2.7 Estimación de recursos
2.9 Desarrollo del cronograma
2.10 Estimación de costos
2.11 Presupuesto del costo
2.12 Planeación de la calidad.
2.13 Planeación de los recursos humanos.
2.14 Planeación de comunicaciones.
2.15 Planeación de administración y gestión de riesgos.
2.16 Determinación de riesgos.
2.17 Estudio cualitativo de riesgos.
2.18 Estudio cuantitativo de riesgos.
2.19 Anticipación de respuestas a los riesgos.
2.20 Plan de compras y adquisiciones.
2.21 Plan de contrato.
3. Grupos de procesos de ejecución
3.1 Ejecución de la administración del proyecto.
3.2 Aseguramiento del sistema de calidad.
3.3 Adquisición del equipo de proyecto.
3.4 Desarrollo del equipo del proyecto.
3.5 Distribución de información.
3.6 Selección proveedores.
4. Grupos de procesos de monitoreo y control
4.1 Monitoreo y control del trabajo del proyecto.
4.2 Control integral de cambios.
4.3 Verificación de alcance.
4.5 Control de cronograma
4.6 Control de costo
4.7 Control de calidad
4.8 Administración del equipo del proyecto.
4.9 Reporte del desempeño
4.10 Administración de los stakeholders
4.11 Control y monitoreo de riesgos
4.12 Administración del documento de contrato
5. Grupos de procesos de cierre
5.1 Cierre del proyecto
5.2 Cierre o finalización del contrato
Figura 6. Procesos de Seguimiento y Control. En Ingeniería del Software (p. 651) por
2.3. MARCO CONCEPTUAL
2.3.1. Project management institute – PMI
El Instituto de Gestión o Dirección de Proyectos (PMI, por sus iniciales en
inglés) asocia a profesionales relacionados con la gestión o administración de
Proyectos y es una organización internacional sin fines de lucro. Sus inicios
fueron el 2011, es la más importante del mundo en su sector, sus miembros
superan más de 700.000 miembros y están en cerca de más de 170 países.
Newtown Square, en el estado de Filadelfia, Estados Unidos es la sede de su
oficina central. Tiene como objetivo fundamental, “Formular estándares
profesionales en Gestión de Proyectos, generar conocimiento a través de
la investigación y promover la Gestión de Proyectos” (Project Management
Institute, 2013, p.41).
Además, tiene como otro objetivo contribuir al perfil profesional través de sus
programas de certificación.
2.3.2. Guía de los fundamentos para la dirección de proyectos pmbok-pmi.
La Guía del PMBOK, desarrollada por el Instituto de Gestión de Proyectos, es
un libro cuyo contenido es una descripción general de los principios de la
Gestión de Proyectos que finalmente son interpretados como buenas prácticas.
Se ha utilizado para el presente trabajo la quinta edición publicada el 2013, de
acuerdo con el ANSI que es el “Instituto Nacional de Estándares de Estados
Unidos” que respalda esta guía como el único estándar en la actualidad para la
gestión de proyectos; además que los programas académicos y sus
respectivas certificaciones brindadas por el PMI están fuertemente
El PMBOK, puede aplicarse en diferentes áreas que pueden entenderse
como tipos de proyectos y que cuentan con elementos comunes importantes
entre sí, pero que no son necesariamente requeridos o están presentes en
todos los proyectos. Las áreas de aplicación usualmente están definidas en
términos de:
Los Proyectos que tienen características similares o cuentan con
elementos técnicos, tales como, desarrollo de software, medicamentos,
obras de ingeniería civil.
Se pueden considerar aquellos que tengan elementos relacionados con
la administración o gestión pública, tales como, contratos bajos las
normas establecidas por el gobierno, o instituciones públicas, o que
estén orientados al desarrollo de nuevos productos.
Por otro lado, también están los proyectos relacionados con la industria,
la fabricación o manufactura, metalúrgicos, o de fines económicos.
En ese contexto, el presente trabajo de investigación está relacionado con la
necesidad de desarrollo de software en las instituciones publicas del Gobierno
Regional de Ayacucho.
2.3.3. Áreas de conocimiento según el pmi
La Guía de los Fundamentos para la Dirección de Proyectos “PMBOK” en su
última versión, está basado en 10 áreas del conocimiento (PMBOK 2013):
1. Integración: Normalmente es un área elaborada al principio sin
embargo su comprensión es más precisa al final, “Los procesos de
integración son los que realiza el Administrador del Proyecto para