Madre de Dios Capital de la Biodiversidad

UNIVERSIDAD NACIONAL AMAZÓNICA DE

MADRE DE DIOS
FACULTAD DE INGENIERIA
ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS E
INFORMATICA

TEMA:

GESTION DE PROYECTOS DE SOFTWARE

EJECUTORES:

ACUÑA CARRASCO, ABNER

PEÑA MONDRAGON, ALBERTO

DOCENTE
FERREYROS YUCRA, JAIR EMERSON

CURSO
INGENIERIA DEL SOFTWARE
Madre de Dios - Perú
2019
 DEDICATORIA

El presente trabajo investigativo lo dedicamos principalmente a Dios, por ser el

inspirador y darnos fuerza para continuar en este proceso de obtener uno de los anhelos
más. deseados. A nuestros padres, por su amor, trabajo y sacrificio en todos estos años,
gracias a ustedes hemos logrado llegar hasta aquí́ y convertirnos en lo que somos. Ha
sido el orgullo y el privilegio de ser sus hijos, son los mejores padres. Agradecemos a
nuestros docentes de la Escuela de Ingeniería de nuestra Universidad Nacional
Amazónica de Madre de Dios, por haber compartido sus conocimientos a lo largo de
esta etapa de nuestra profesión.

Acuña Carrasco Abner

Peña Mondragón Alberto

ii
 AGRADECIMIENTO

Principalmente A Dios, por derramar en nosotros sus bendiciones, permitiéndonos

obtener las fuerzas y confianza necesarias para afrontar con actitud y responsabilidad
toda esta maravillosa etapa de nuestra vida Universitaria. A la Universidad Nacional
Amazónica de Madre de Dios, por contar con las herramientas y con un personal
altamente competitivo, los cuales fueron claves para mí desarrollo profesional hasta el
momento. Así mismo, expresar mi agradecimiento a todas aquellas personas que
directa o indirectamente favorecieron en esta investigación. Aunque el tiempo pase, lo
importante es, concluir lo que se ha empezado.

Acuña Carrasco Abner

Peña Mondragón Alberto
.

iii
 RESUMEN

Gestión de Proyectos de Software. La Gestión de Proyectos no es más que la capacidad

de reconocer los desafíos que te proporciona el cliente o la Empresa, para a través de
ellos encontrar, revisar y evaluar las múltiples soluciones, seleccionando la que más
responda a las definiciones de eficiencia y calidad, para después ponerla en práctica,
acorde a los objetivos y planificación establecidos. La gestión de proyectos
simplemente en conducir un proyecto desde el comienzo hasta un final satisfactorio,
haciendo uso conjunto de procesos, conocimientos, habilidades, herramientas y
técnicas que orienten y motiven al personal a realizar satisfactoriamente su trabajo
dentro del proyecto. Se dice que el software es un producto no tangible. El desarrollo
Software contiene aspectos de todas las corrientes del mundo de los negocios, pero
tiene poca experiencia en construir productos software. El directivo de un proyecto
software es la persona que se responsabiliza de la ejecución del proyecto software.
Debe estar al tanto y seguir todas las fases del SDLC por las que el software pasará.

Palabras clave: Diseño, Implementación, Sistema, Software, Proyecto, Gestión,

Eficiencia, Calidad, Procesos, Herramientas.

iv
 ABSTRACT

Management of Software Projects. Project Management is nothing more than

the ability to recognize the challenges that the client or the Company provides
you, through them find, review and evaluate the multiple solutions, selecting
the one that most responds to the definitions of efficiency and quality, to then
put it into practice, according to the objectives and planning established. Project
management simply to conduct a project from the beginning to a satisfactory
end, making joint use of processes, knowledge, skills, tools and techniques that
guide and motivate the staff to successfully perform their work within the
project. It is said that software is a non-tangible product. Software development
contains aspects of all currents of the business world, but has little experience
in building software products. The manager of a software project is the person
who is responsible for the execution of the software project. You must be aware
of and follow all the phases of the SDLC through which the software will pass.

Keywords: Design, Implementation, System, Project, Management, Software, Efficiency,

Quality, Processes, Tools.

v
 ÍNDICE DE CONTENIDO

Contenido
DEDICATORIA ............................................................................................................. 2

AGRADECIMIENTO .................................................................................................... 3

RESUMEN ..................................................................................................................... 4

ABSTRACT.................................................................................................................... 5

ÍNDICE DE CONTENIDO........................................................................................ 1

INTRODUCCIÓN .......................................................................................................... 3

I. PROYECTO DE SOFTWARE ........................................................................... 4

2.1. Gestión de Proyectos ........................................................................................... 4

2.1.1. Ingeniería Colaborativa ............................................................................. 4

2.1.2. Mejora de Procesos ................................................................................... 5

2.1.3. Antecedentes a nivel regional ................................................................... 6

II. CREACION DEL PLAN DE PROYECTO ........................................................ 5

3.1. Definición del ámbito del Proyecto, y gestión de expectativas y requerimientos

5

3.2. Objetivos ............................................................................................................. 5

3.3. Gestión de Creación. ........................................................................................... 6

3.3.1. Gestión expectativa ................................................................................... 6

3.3.2. Gestión Requerimientos ............................................................................ 6

3.4. Gestión de Riesgo. .............................................................................................. 6

3.5. Identificación y Análisis ..................................................................................... 8

1
 III. PLANIFICACION .............................................................................................. 9

4.1. Definición ............................................................................................................ 9

4.2. Roles ................................................................................................................. 10

5. Proyecto software .............................................................................................. 11

V. PROYECTO DE SOFTWARE ......................................................................... 12

6. Gestión de Proyectos de Software..................................................................... 12

VI. ACTIVIDADES DE LA GESTION ................................................................. 13

7. Gestión de Software .......................................................................................... 13

7.1. Planificación del proyecto ................................................................................. 14

7.2. Gestión del alcance ........................................................................................... 14

7.3. Estimación del proyecto .................................................................................... 14

 Estimación del tamaño del Software ................................................................. 14

 Estimación del esfuerzo .................................................................................... 15

 Estimación del tiempo ....................................................................................... 15

 Estimación del coste .......................................................................................... 15

VII. CONCLUSIONES ............................................................................................ 16

VIII. RECOMENDACIONES ......................................................................... 17

IX. REFERENCIAS BIBLIOGRÁFICAS .............................................................. 18

2
 INTRODUCCIÓN

Existen muchas evidencias que refuerzan la afirmación de que los proyectos de

desarrollo de software requieren una profundización y un tratamiento adecuado
a sus características particulares. Los tipos de sistemas de software que la
tecnología ha hecho posible y que la sociedad demanda están creciendo en
tamaño, complejidad, distribución e importancia, lo que constituye un reto
importante al presionar los límites de lo que la industria del software sabe
“cómo” desarrollar.

A pesar de ello, muchas organizaciones en la actualidad no usan metodologías

formales en sus proyectos, conformándose con realizar su trabajo en base al
sentido común y a la experiencia del equipo. Al constituir guías y principios de
trabajo, las metodologías permiten al equipo de proyectos sacar provecho de las
experiencias previas, al tiempo que con frecuencia garantizan la repetibilidad del
trabajo realizado. Es por eso que, en el mundo de la ingeniería de software actual,
se requiere el uso de metodologías y procesos dinámicos, para desarrollar
productos y servicios de forma rápida y confiable.

Un hecho claro es, sin embargo, que no existe una única metodología que sea
adecuada para cualquier proyecto. Es por esto que resulta muy importante
conocer las diversas metodologías que puedan ser aplicables a los proyectos, así
como manejar las herramientas que permitirán su selección, adaptación o incluso
su formulación.
Como respuesta a estos múltiples impactos, gran parte de las empresas y
organizaciones confían sus sistemas de información a los elementos que integran
el desarrollo del software. Básicamente, la finalidad que persigue la gestión de
proyectos es hacer cuestionamientos de estimaciones frente a lo que sucederá,
por ejemplo, con nuevas soluciones, analizar lo que pasó con un proyecto previo
y, posteriormente, tratar de dar respuestas cuantitativas a preguntas claves como:
¿cuál será el plazo de entrega para cada proyecto?, ¿cuánto costará cada

3
 proyecto? y ¿qué recurso humano se requiere? suficientemente motivado para
los logros y éxitos del mismo, entre otros.

I. PROYECTO DE SOFTWARE

2.1. Gestión de Proyectos

La gestión de proyectos vista como una herramienta de control de procesos al

interior de una organización, es el primer elemento distintivo del proyecto
mencionado en este documento, donde la prospectiva tomada por el PMBOK,
según el Proyect Management Institute [14], ha sido tomada como una guía
metodológica que agrupa un compendio de buenas prácticas en gerencia de
proyectos, una colección de procesos y áreas de conocimiento generalmente
aceptadas como las mejores prácticas dentro de la gestión de proyectos. El
PMBOK reconoce cinco grupos de procesos básicos y nueve áreas de
conocimiento comunes a casi todos los proyectos; tanto los grupos de procesos
como las áreas de conocimiento fueron tomados en su totalidad para la
adaptación de técnicas de ingeniería colaborativa.

2.1.1. Ingeniería Colaborativa

En El otro eje desarrollado en el proyecto es la denominada ingeniería de la

colaboración, disciplina adscrita a la ingeniería del software, que plantea como
primera instancia en su conceptualización el valor de reconocer el trabajo en
grupo o trabajo colaborativo, como se le mencionará de ahora en adelante. Este
aspecto se refiere a contar con un objetivo común en la organización, que
canalice los esfuerzos individuales y ofrezca un sentido de pertenencia, que
fomente la unión entre los miembros del grupo para mejorar su capacidad de
aprender, tomando en consideración otros puntos de vista, así como distintas
maneras de hacer las cosas, interpretaciones diferentes de conceptos y
experiencia, esto es, trabajar colaborativamente.

4
2.1.2. Mejora de Procesos

En Una alternativa en el desarrollo de software de calidad, es contemplar los

beneficios que la mejora de procesos, disciplina de la ingeniería de software
proporciona a los procesos de desarrollo, cuando se intenta cambiar la forma
en que se realizan las tareas en una organización, con el fin de mejorar en
cuanto a calidad y productividad. Algunos beneficios de implementar la mejora
de procesos en una organización son la reducción de errores en el software; la
reducción en el tiempo de entrega y el incremento en la eficiencia de pruebas;
además que facilita la definición y cumplimiento de los objetivos de calidad,
mejorando la comunicación del equipo de trabajo e incremento de la
satisfacción del cliente frente al producto entregado.

Uno de los propósitos que busca la aplicación de estrategias de mejora de

procesos software es garantizar un mecanismo de mejora continua en las
organizaciones, que permita auditar desarrollos de software internos,
planificar la estrategia de ingeniería del software de la empresa, entre
muchos otros beneficios .Por lo tanto, la adopción de modelos definidos y
comprobados como Competisoft, permite contribuir a la dinamización,
comprensión y ejecución de prácticas de gestión de proyectos
especialmente orientadas a micro y pequeñas empresas.
Gráfico Nro 1: Áreas a Gestionar

Procesos

Persona
ecnología
5
2.1.3. Antecedentes a nivel regional

Evitar siempre la reinvención de la rueda, tanto en métodos como en

herramientas (no es recomendable ‘’la improvisación’’).
Analizadas las características del proyecto, los principales procesos a
considerar son casi siempre:
 Como validamos el cumplimiento de expectativas de nuestro “cliente”
 Como vamos a gestionar los riesgos del proyecto
 Como vamos a planificar (definición y seguimiento semanal)
Asociado a la Ingeniería del Software, que ciclo de vida debe ser aplicado,
centrándose en dos aspectos fundamentales: La obtención de requerimientos, y
la posterior validación en todo el ciclo de vida de que el software cumple con
estos requerimientos (revisiones/pruebas y gestión de la configuración)
Como se van a gestionar los costes, no sólo directos, sino también los indirectos
(puesto de trabajo, recursos administrativos, bonus/malus proveedor, garantías,
formación…)..

En Una de las principales causas de proyectos fracasados es la mala definición

de roles y responsabilidades, tanto a nivel interno como del cliente/usuario, que
afloran de manera indirecta (mala valoración, pruebas defectuosas,)
 Una buena gestión del proyecto ha de permitir definir, y mantener:
 Responsabilidades a nivel de cliente/usuario final:
 ¿Van a haber resistencias al cambio, o simplemente boicoteadores?
 ¿Quién define los requisitos es quien va a usar la aplicación?
 ¿Existen recursos humanos de parte del cliente/organización para
abordar el proyecto?
Responsabilidades y funciones del equipo de trabajo:
Saber determinar el nivel de compromiso con el proyecto con relación a la
criticidad del rol de cada persona.
Fijar diferencial capacidades (técnicas y de gestión) con relación a las
necesidades del proyecto.

6
II. CREACION DEL PLAN DE PROYECTO

3.1. Definición del ámbito del Proyecto, y gestión de expectativas y requerimientos

El Plan de Proyecto es un conjunto de planes para cada elemento a gestionar, controlados

cada uno bajo su propio “versionado”, cada plan tiene anexados un conjunto de documentos
que demuestran la aplicación del mismo. Determinar la dimensión de los tres ejes que
definen el objetivo de un proyecto. Se debe tomar como punto de partida el contrato con el
Cliente (si existe), o en su defecto el acta de la reunión de lanzamiento/aprobación del
proyecto.

3.2. Objetivos

Han de quedar perfectamente identificados los objetivos de negocio que han decidido la
realización de dicho proyecto:
 Expectativas y Requisitos del cliente
 Fecha límite de implantación asociada a motivos de negocio.
 Presupuesto aprobado para este proyecto.
Sobre todo, objetivos que no son misión de este proyecto su consecución.

Gráfico Nro. 2: Objetivos

COSTE

OBJETIVO

TIEMPO

REQUISITOST

5
 3.3. Gestión de Creación.

3.3.1. Gestión expectativa

Quien tiene la única visión válida de si un proyecto ha sido exitoso o no, es el “cliente/s
destinatario/s” (muchas veces no coincide con el usuario final).
En consecuencia, es fundamental que el Gestor del Proyecto tenga explicitadas, dentro
de lo posible, las expectativas del “cliente/s”.
Para ello debería ser posible el crear una matriz donde:
 Definir cada expectativa en términos de negocio del “cliente”
 Identificar la prioridad de su cumplimiento
 Identificar el parámetro objetivamente medible que indica el valor actual, el
valor objetivo, así como cuando se prevé obtener dicho valor
 Medir periódicamente el valor de dicho parámetro
 Definir acciones/responsables asociados al seguimiento de dichas expectativas.
3.3.2. Gestión Requerimientos

La Recoger de una manera formal los requerimientos del cliente que conforman el objeto
del proyecto, así como cuales han sido los cambios posteriormente solicitados y aprobados
de estos requerimientos originales, son la base que facilita una gestión exitosa.
• En este capítulo del Plan de Proyecto deben recogerse:
– Documentos, o ubicación física o electrónica, que indican cuales son los requisitos
originalmente aprobados por el “cliente”, así como los cambios posteriormente
solicitados/aprobados.
– Documentos, o ubicación física o electrónica, que recogen la transformación de
estos requerimientos en diseño físico, tanto de datos como procesos. Por ejemplo,
donde encontrar el modelo conceptual de datos y de procesos, o el modelo lógico
de procesos, ...
– Ubicaciones de los diferentes conjuntos de software y [Link].,tanto para el
desarrollo, como para la pre-producción (entorno integración).
3.4. Gestión de Riesgo.

6
 1. Riesgo.
Un posible evento futuro que, si ocurre, puede provocar resultados inesperados.
2. Riesgos del Proyecto.
Efecto acumulado de los sucesos con resultado incierto que afectan negativamente a
los objetivos del proyecto.
3. Gestión del riesgo.
Conjunto de actividades realizadas para la identificación, análisis y control de los
riesgos de un proyecto.

¿Las Por qué es necesaria la gestión del Riesgo?

 Los proyectos tienen tendencia a complicarse y a crecer
 Cada vez son necesarias más y diversas tecnologías
 El número de usuarios es mayor
 Los cambios en los negocios cada vez son más radicales
Gráfico Nro. 3: Valoración y Control

Identificación de
Valoración
Análisis de Riesgos
de Riesgos

Gestión de Priorización de Riesgos

Riesgos Planificación de la
Control de
Resolución de Riesgos
Riesgos
Monitorización de

7
 3.5. Identificación y Análisis

Los Identificación de los Riesgos

− Se debe mantener un inventario de los riesgos identificando la causa y el
efecto que tendrá.
− Las fuentes pueden ser muy diversas, como sesiones de Brainstorming,
datos de Consultores, Análisis Causa-Efecto, Herramientas, etc.
− Nuestras fuentes son las Suposiciones realizadas al recoger los
requerimientos, el plan de trabajo (camino crítico) y el análisis de los
Costes esperados.
Análisis de los Riesgos
− Se identifica cuándo puede ocurrir, el impacto que puede tener, la
probabilidad de que ocurra y la proximidad al núcleo del proyecto.
− Nosotros utilizamos un método cualitativo, asignando las letras A (bueno)
a D (malo) a cada concepto.
− sistema de venta adaptado a sus necesidades y que cumpla los
requerimientos identificados en la entidad beneficiaria de esta
investigación.

Gráfico Nro. 4: Gestión Calidad

De Proyectos
C
O
S De Implantación Calidad
T
E

8
 III. PLANIFICACION

4.1. Definición
La planificación define los objetivos o metas de la organización, trazándose una
estrategia a seguir para alcanzar dichas metas y realizar un conjunto de planes para
coordinar las actividades. Planificar consiste en evaluar la realidad del entorno
teniendo en cuenta parámetros como recursos, tiempo, estimación, objetivos y
metas que hacen que la planificación sea dinámica ya que esta se reajusta entre
medios y fines, integral puesto que relaciona todos los elementos de una manera
independiente, práctica la cual nos lleva a la acción, anticipadora pues se hace un
intento por pronosticar el futuro e instrumental ya que es un medio dirigido a
lograr los objetivos.
Plan de Trabajo se encontrará condicionado por la política de [Link]. que impere
en la empresa. No obstante, en mayor o menor medida, será indispensable detallar
los siguientes aspectos del proyecto.
Gráfico Nro. 5: Planificacion

Definición de Roles y

Roles y Responsabilidades
Responsabilidades

Plan de Reasignación/
Infraestructur
Adquisición de Recursos
a

9
4.2. Roles
Es fundamental que en un proyecto cada miembro del equipo de trabajo tenga
claras sus responsabilidades. En el cuadro siguiente se define las
responsabilidades de algunos de los miembros de un equipo.

Función Responsabilidades Persona(s)

Especialista en Definidas por la versión vigente de GSCM (Gestión de Jefe Proyecto

la gestión de Cadena de Suministro Verde)y los estándares vigentes en el
requerimientos SC (Cadena de Suministros) para la función del miembro del
(RM) equipo. Además:

- Interlocutor válido para los compromisos con el

cliente

- Responsable para las peticiones de desarrollo

pequeñas y medianas

Especialista en Definidas por la versión vigente de GSCM y los estándares Jefe Proyecto
el vigentes en el SC para la función del miembro del equipo.
Analista B
aseguramiento Además:
de calidad (QA)
- Participa en las revisiones del proceso y auditorías de
QA

- Participa y puede liderar las revisiones de productos

Especialista en Definidas por la versión vigente de GSCM y los estándares Analista A

la gestión de vigentes en el SC para la función del miembro del equipo.
Analista B
configuración Además:
(CM)
- Da soporte al resto del equipo en las actividades del
control de cambios y versiones

- Realiza las revisiones de las Baselines según lo

planificado en el Plan de gestión de configuración

Requerimientos Plantilla: A partir de la planificación del proyecto, se debe

analizar la necesidad de recursos por perfiles profesionales, así como cual ha de
ser la evolución de la pirámide durante la vida del proyecto.

10
 Es importante el saber calcular, a partir del número equivalente de recursos
obtenidos de la planificación del proyecto, los recursos que realmente son
necesarios en función del % de utilización de los mismos.
%Utilización = (Horas Disponibles - Formación - Bajas - Vacaciones) / Horas
Disponibles
Por ejemplo, en el cuadro siguiente, cada mes será necesario prever un recurso
más por meses.
Gráfico Nro. 5: Cuadro de Utilización

Enero Febrero Marzo Abril Mayo

JefeProyecto 1 1 1 1 1
Analistas 2 2 2 2 1
A/P 1 2 3 3 2
Programadores 1 3 5 5 2
TOTAL EQUIVALENTE 5 8 11 11 6
%Utilización 85% 90% 90% 90% 90%
TOTAL PERSONAS 5,88 8,89 12,22 12,22 6,67

IV. NECESIDA DE LA GESTION

5. Proyecto software

Se dice que el software es un producto no tangible. El desarrollo de Software

contiene aspectos de todas las corrientes del mundo de los negocios, pero tiene poca
experiencia en construir productos software. La mayor parte de los productos
software se diseñan para satisfacer las necesidades de los clientes. Lo más
importante es que la tecnología subyacente cambia y avanza tan frecuente y
rápidamente que la experiencia de un producto quizá no se pueda aplicar a otro.
Todo este tipo de negocios y limitaciones del entorno traen con ellos riesgo en el
desarrollo del software, por eso es esencial gestionar los proyectos software de
manera eficiente.
Gráfico Nro. 6: Cuadro de Utilización

11
La imagen de arriba muestra las limitaciones triples para los proyectos software. Es una
parte esencial de la organización del software entregar un producto de calidad, manteniendo
el coste dentro de las limitaciones del presupuesto del cliente y entregar el proyecto a tiempo.
Hay muchos factores, internos y externos, que pueden causar un impacto en este triángulo
de triples limitaciones. Cada uno de los 3 factores puede causar un impacto en los otros dos
de forma grave.
Por tanto, la gestión del proyecto software debe incorporar los requisitos del usuario junto
con el presupuesto y las limitaciones de temporales.

V. PROYECTO DE SOFTWARE

6. Gestión de Proyectos de Software

gestión de proyectos busca las técnicas necesarias para planificar, organizar, supervisar y
controlar proyectos de software. El objetivo de gestionar proyectos es tener un producto
de alta calidad.

La gestión de un proyecto de software se centra en tres partes como son:

 Personal
 Problema
 Proceso

Personal: El factor humano es importante en la ingeniería de software. Es importante

tener la capacidad de gestión del personal con el fin de aumentar la preparación en la
organización del software; ayudando a atraer, motivar y retener el talento necesario para
mejorar su capacidad de desarrollo de software.

11
En toda organización que alcanza la madurez en el área de gestión de personal tiene una
mayor probabilidad de implementar unas eficaces prácticas de ingeniería de software,
esto guía a que las organizaciones tengan un proceso de software maduro.

El problema: Se establecen los objetivos y se deben considerar soluciones alternativas e

identificar las dificultades técnicas y de gestión. Con esta información es posible definir
unas estimaciones razonables del costo, una valoración efectiva del riesgo, una
subdivisión realista de las tareas del proyecto o una planificación del proyecto asequible
que proporcione una indicación fiable del progreso.

El desarrollador de software y el cliente deben reunirse para definir los objetivos del
proyecto. Los objetivos identifican las metas generales del proyecto sin considerar cómo
se conseguirán.

Se identifican los datos primarios, funciones y comportamientos que caracterizan el

problema, intenta abordar estas características de una manera cuantitativa. También se
consideran las soluciones alternativas, estas permiten a los gestores y a los profesionales
seleccionar el mejor enfoque.

Proceso: En el proceso de software proporciona la estructura desde la que se puede

establecer un detallado plan para el desarrollo del software. Las actividades estructurales
se pueden aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o
complejidad, además permiten a las actividades estructurales adaptarse a las
características del proyecto de software y a los requisitos del equipo del proyecto.

VI. ACTIVIDADES DE LA GESTION

7. Gestión de Software

La gestión del proyecto Software comprende un gran número de actividades, que contienen
la planificación del proyecto, decidir el alcance del producto software, estimar el coste
respecto a la temporalización de tareas y eventos, y la gestión de los recursos. Las
actividades de gestión del proyecto pueden incluir:

 Planificación del proyecto

 Gestión del alcance
 Estimación del Proyecto

11
 [Link]ón del proyecto

La planificación del proyecto Software es una tarea que se realiza antes de la producción del
software empiece. Está ahí para la producción de software, pero no implica una actividad
concreta que tenga una conexión directa con la producción de software; más bien es un
conjunto de procesos, que facilitan la producción de software. La planificación del proyecto
puede incluir:

[Link]ón del alcance

Define el alcance de un proyecto; esto incluye todas las actividades y procesos que se
requieren para crear un producto software distribuible. La gestión del alcance es esencial
porque crea condiciones del proyecto por medio de la definición de lo que se debe realizar
en el proyecto y lo que no. Esto hace que el proyecto contenga tareas limitadas y
cuantificables, con lo que puede ser documentado fácilmente y por tanto evitar costes y
tiempo excedidos.

Durante la gestión del alcance del proyecto, es necesario:

 Definir el alcance
 Decidir su verificación y control
 Dividir el proyecto en pequeñas partes para facilitar su gestión.
 Verificar el alcance
 Controlar el alcance incorporando cambios a éste

[Link]ón del proyecto

Para una gestión efectiva, es necesario que se realice una estimación acurada de varias
medidas. Los directores pueden gestionar y controlar el proyecto de forma más eficiente y
efectiva haciendo estimaciones correctas.

La estimación del proyecto puede incluir los siguientes aspectos:

 Estimación del tamaño del Software
El tamaño del Software se puede estimar en KLOC (Kilo Línea de código) o
calculando el número de puntos de función en el software. Las líneas de código

11
 dependen de las prácticas de codificación y los puntos de función, que cambian
según el usuario o los requisitos del software.
 Estimación del esfuerzo
Los directores estiman los esfuerzos en términos de requisitos de personal y las horas
de trabajo requeridas para producir el software. Para la estimación de esfuerzos se
debe conocer el tamaño del software. Esto lo pueden aportar la experiencia misma
de los directores, los datos históricos de la organización, o el tamaño del software se
puede convertir en esfuerzos usando alguna formulación estándar.
 Estimación del tiempo
Una vez el tamaño y los esfuerzos se han estimado, podemos proceder a estimar el
tiempo que requeriremos para producir el software. Los esfuerzos requeridos se
dividen en categorías según los requisitos del sistema y la interdependencia de varios
componentes del software. Las tareas del Software se dividen en pequeñas tareas,
actividades o eventos por la 'Work Breakthrough Structure (WBS)' en español
'Estructura de descomposición del trabajo'. Las tareas se temporalizan diariamente o
en los meses del calendario.

La suma del tiempo requerido para completar todas las tareas en horas o días es el
tiempo total que se invierte para terminar el proyecto.
 Estimación del coste
Este debe de ser considerado como el más difícil de todos porque depende de más
elementos que los anteriormente mencionados. Para estimar el coste de un proyecto,
se requiere considerar:

 El tamaño del software

 La calidad del Software
 El Hardware
 Herramientas o software adicional, licencias, etc.
 Personal formado para tareas concretas
 Implicaciones de viaje
 Comunicación
 Formación y soporte

11
 [Link]

Además de las responsabilidades de análisis y diseño de sistemas, los analistas de

sistemas asumen con frecuencia el papel de directores de proyectos. Una mala
gestión de proyectos desemboca a menudo en la no definición de necesidades de
usuario final, en excesos de costos y en retrasos en la entrega de los proyectos.
Las causas de estos problemas pueden ser omisiones realizadas durante el
desarrollo de sistemas, definición imprecisa de objetivos, estimaciones de costos
prematuras, deficientes técnicas de estimación, mala gestión de tiempo y falta
de liderazgo. Es responsabilidad del analista de sistema evitar estos errores y
llevar a buen término el proyecto tanto en tiempo como en presupuesto. Entre las
funciones básicas de la dirección de proyecto se incluyen la planificación de las
tareas de proyecto, la elección del equipo de proyecto, la organización y la
planificación de los esfuerzos del proyecto, la dirección del equipo y el control de
la evaluación del.

11
 VIII. RECOMENDACIONES

1. Tener los datos más recientes del mercado donde está insertada la organización
permite un marco para el aprovechamiento no solo de ésta sino de otras
herramientas.
2. Si existe algún elemento que se ignore o algún inconveniente sobre la organización y
sus procesos, este es el mejor momento para resolverlo.
3. Evaluar el estado del software y hardware de la organización y determinar qué tan
compatibles son con respecto a la nueva tecnología que se pretende implantar.
4. Preservar la información clave de la empresa ante cualquier cambio de software que
se desee realizar.
5. Es importante establecer una estrategia para combatir la resistencia al cambio desde
el principio.
6. Contar con el apoyo de la alta directiva y la gerencia de cada departamento de la
organización es importante.
7. Investigar lo más que se pueda sobre el software que se pretende implantar.
8. Evaluar los costos que significará la adquisición de la herramienta y su implantación,
incluido el entrenamiento del personal.
9. A la par de la selección del software de preferencia, es importante considerar al
proveedor. Es esencial conocerlo y tener referencia de otros de sus clientes.
10. El proveedor debe estar dispuesto a involucrarse en el proceso de implantación de la
herramienta dentro de la empresa. Especialmente, debe brindar luces sobre la
metodología de instalación del software, la formación del recurso humano de la
organización y el posterior soporte técnico.
11. Debe considerarse que una vez que se ponga en funcionamiento la herramienta, es
necesario aplicar procesos de auditoría periódicos. En estos se puede involucrar al
proveedor y al departamento de la empresa dedicado a esta tarea. Aunque lo ideal es
contar con asesores externos e imparciales que arrojen datos objetivos sobre el aporte
del uso de la herramienta.
12. Es fundamental tener una buena disposición ante la tecnología para abrirse al
proceso y hacer no solo la mejor elección e implantación, sino también obtener los
mejores resultados con el uso de la herramienta.

11
 IX. REFERENCIAS BIBLIOGRÁFICAS

a. Hernández, R., Fernández, C. y Baptista L. (2006). Metodología de la

investigación
i. (4ta ed.). México. McGraw Hill Interamericana S.A.

b. Pressman, R. (1998). Ingeniería del Software. Un enfoque práctico (4ta ed.).

Madrid.
i. McGraw Hill Interamericana de España, S.A.U.

c. McDonnell, S. (1997). Desarrollo y Gestión de Proyectos Informáticos (1era

ed.).
i. Madrid. McGraw Hill Interamericana de España, S.A.U.

d. Joyanes, L. (1998). Programación orientada a objetos (2a ed.).

Madrid. McGraw Hill Interamericana de España, S.A.U.

e. Palacios, L. (2005). Gerencia de proyectos. Un enfoque latino (3a ed.).

Venezuela.
i. Publicaciones Universidad Católica Andrés Bello.

f. Balestrini, M. (2006). Como se elabora el proyecto de investigación.

Venezuela. BL Consultores Asociados, Servicio Editor

11