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

DEDICATORIA .........................................................................................................ii

AGRADECIMIENTO ............................................................................................... iii

RESUMEN ................................................................................................................. iv

ABSTRACT...............................................................................................................v

ÍNDICE DE CONTENIDO ..................................................................................... vi

ÍNDICE DE GRÁFICOS
................................................................................................................................... vii
i

I. INTRODUCCIÓN .................................................................................................. 1

II. PROYECTO DE SOFTWARE ............................................................................. 6

2.1. Antecedentes ................................................................................................... 6

2.1.1. Antecedentes a nivel internacional........................................................6

2.1.2. Antecedentes a nivel nacional ............................................................. 9

2.1.3. Antecedentes a nivel regional ............................................................ 11

2.2. Bases teóricas ............................................................................................... 13

2.2.1. Sistema de Venta ................................................................................ 13

2.2.2. Distribuidora Josymar ........................................................................ 14

2.2.3. Las Tecnologías de información y comunicaciones (TIC) ................. 16

vi
 2.2.4 Componentes de un punto de venta ..................................................... 18

2.2.5. Herramientas utilizadas en el desarrollo del Sistema de Ventas…….26

2.3. Sistema de hipótesis ..................................................................................... 38

2.3.1. Hipótesis principal .............................................................................. 38

2.3.2. Hipótesis específicas .......................................................................... 38

III. METODOLOGIA .............................................................................................. 39

3.1. Diseño de la investigación ........................................................................... 39

3.2. Población y Muestra .................................................................................... 39

3.3. Técnicas e instrumentos .............................................................................. 39

3.3.1. Técnica .............................................................................................. 39

3.3.2. Instrumentos ...................................................................................... 39

3.4. Procedimiento de recolección de datos ....................................................... 40

3.5. Definición operacional de las variables en estudio ..................................... 41

3.6. Plan de análisis ............................................................................................ 42

IV. RESULTADOS ................................................................................................ 43

4.1. Resultados de la información obtenida ....................................................... 43

4.2. Análisis de resultados ................................................................................. 54

4.3. Propuesta de mejora ................................................................................... 55

4.4. Propuesta del sistema ................................................................................. 55

V. CONCLUSIONES ............................................................................................. 79

VI. RECOMENDACIONES ..................................................................................80

vi
i
VII. REFERENCIAS BIBLIOGRÁFICAS ............................................................ 81

ANEXOS ................................................................................................................ 85

vi
ii
 ÍNDICE DE GRÁFICOS

Gráfico Nro. 1: Áreas a Gestionar ........................................................................... 16

Gráfico Nro. 2: Computadora para sistema de venta… ............................................ 19

Gráfico Nro. 3: Monitor ............................................................................................ 20

Gráfico Nro. 4: Lector de codigos ............................................................................ 21

Gráfico Nro. 5: Impresora matricial… ......................................................................22

Gráfico Nro. 6: Impresora ticketera .......................................................................... 23

i
x
I. 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?,

1
 ¿cuánto costará cada proyecto? y ¿qué recurso humano se requiere?
suficientemente motivado para los logros y éxitos del mismo, entre otros.

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

2
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

Perso
Tecnología
nas
3
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.

4
III. 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

REQUISITOS

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 BB.DD.,tanto para el
desarrollo, como para la pre-producción (entorno integración).

6
3.4. Gestión de Riesgo.
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ó Riesgos
Análisis de Riesgos
n de
Gestión Riesgos Priorización de

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

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
De Implantación Calidad
S

8
 IV. 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 RR.HH. 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/
Infraestructu Adquisición de
ra Recursos

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

la gestión de Cadena de Suministro Verde)y los estándares vigentes en Proyecto
requerimientos el SC (Cadena de Suministros) para la función del
(RM) miembro del 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

el vigentes en el SC para la función del miembro del equipo. Proyecto
aseguramiento Además:
Analista B
de calidad
- Participa en las revisiones del proceso y auditorías
(QA)
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.
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.
10
 %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

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

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

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

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

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

7.1.Planificació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:

7.2.Gestió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

11
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

7.3.Estimació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
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.
11
 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
 VIII. CONCLUSIONES

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
 IX. 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
 X. 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
Editorial.

11
ANEXOS

8
7
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 colabora.

8
8