antecedentes-especialización-en-proyectos

ESPECIALIZACIÓN EN PROYECTOS INFORMÁTICOS
ANTECEDENTES
Un proyecto es un esfuerzo planificado, temporal y único, realizado para crear productos o
servicios únicos que agreguen valor o provoquen un cambio beneficioso. Esto en contraste con la
forma más tradicional de trabajar, en base a procesos, en la cual se opera en forma permanente,
creando los mismos productos o servicios una y otra vez. [1]
Gerencia de Proyectos (Project Management)
Gestión de proyectos de software es el arte y la ciencia de la planificación y dirección de proyectos
de software. Se trata de una sub-disciplina de gestión de proyectos en los que se planifican los
proyectos de software, aplicación, seguimiento y control.
Historia
En los años 1970 y 1980, la industria del software creció muy rápidamente, ya que las empresas
informáticas rápidamente reconocieron el costo relativamente bajo de la producción de software
en comparación con la producción de hardware y circuitos. Para gestionar los nuevos esfuerzos de
desarrollo, las empresas aplican los métodos de gestión de proyectos establecidos, pero los
horarios de los proyectos cayeron durante los recorridos de prueba, sobre todo cuando la
confusión se produjo en la zona gris entre las especificaciones del usuario y el software entregado.
Para ser capaz de evitar estos problemas, métodos de gestión de proyectos de software se
centraron en la coincidencia de los requisitos del usuario a los productos entregados, en un método
conocido ahora como el modelo de cascada. [2]
A medida que la industria ha madurado, el análisis de los fallos de gestión de proyectos de
software ha demostrado que las siguientes son las causas más comunes:












Objetivos de los proyectos poco realistas o no articulada
Estimaciones inexactas de los recursos necesarios
Requisitos del sistema mal definidos
El informe deficiente de la situación del proyecto
Riesgos administrados
La falta de comunicación entre los clientes, desarrolladores y usuarios
El uso de la tecnología inmadura
La incapacidad para manejar la complejidad del proyecto
Prácticas de desarrollo Sloppy
Gestión deficiente del proyecto
Política de los grupos de interés
Las presiones comerciales [3]
Los tres primeros puntos en la lista de arriba muestra las dificultades de articulación de las
necesidades del cliente de una manera tal que los recursos propios puedan cumplir los objetivos
propios del proyecto. Las herramientas específicas de gestión de proyectos de software son útiles
y muchas veces necesario, pero el verdadero arte de la gestión de proyectos de software está
aplicando el método correcto y el uso de herramientas para apoyar el método. Sin un método, las
herramientas son inútiles. Desde la década de 1960, varios métodos patentados de gestión de
proyectos de software han sido desarrollados por los fabricantes de software para su propio uso,
mientras que las empresas de consultoría informática también han desarrollado métodos similares
para sus clientes. Métodos de gestión de proyectos de software hoy en día todavía están
evolucionando, pero la tendencia actual lleva lejos del modelo de cascada a un modelo de entrega
de proyectos más cíclico que imita un ciclo de vida de liberación de software.
Proceso de desarrollo de software
Un proceso de desarrollo de software se ocupa principalmente con el aspecto de la producción de
desarrollo de software, en comparación con el aspecto técnico, tales como herramientas de
software. Estos procesos existen principalmente para apoyar la gestión de desarrollo de software,
y por lo general se inclinan hacia la solución de problemas empresariales [4]. Muchos de los
procesos de desarrollo de software se pueden ejecutar de forma similar a los procesos generales
de gestión de proyectos. Ejemplos son:
 La gestión del riesgo es el proceso de medir o evaluar el riesgo y el desarrollo de
estrategias para gestionar el riesgo. En general, las estrategias empleadas incluyen
transferir el riesgo a otra parte, evitar el riesgo, reducir el efecto negativo del riesgo, y la
aceptación de todas o algunas de las consecuencias de un riesgo en particular. La gestión
de riesgos en la gestión de proyectos de software comienza con el caso de negocios para
iniciar el proyecto, que incluye un análisis de costes y beneficios, así como una lista de
opciones de reserva para el fracaso del proyecto, llamado un plan de contingencia.

Un subconjunto de la gestión del riesgo que está ganando cada vez más atención
es la Gestión de Oportunidades, lo que significa lo mismo, excepto que el
resultado potencial de riesgo tendrá un efecto positivo, en lugar de un impacto
negativo. Aunque teóricamente manejado de la misma manera, el uso del término
"oportunidad" en lugar del término "riesgo" algo negativo ayuda a mantener un
equipo centrado en los posibles resultados positivos de cualquier riesgo
determinado registro en sus proyectos, como spin-off proyectos extraordinarios ,
y los recursos adicionales gratis.
 La gestión de requisitos es el proceso de identificación, la obtención, documentación,
análisis, seguimiento, priorizar y consensuar las necesidades y el control del cambio y
la comunicación a las partes interesadas. Nueva dirección o alterados Requisitos de
sistema informático, que incluye análisis de requerimientos, es una parte importante
del proceso de ingeniería de software, con que los analistas de negocio o los
desarrolladores de software a identificar las necesidades o requerimientos de un
cliente, que han identificado estos requisitos están entonces en condiciones de
diseñar una solución.
 La gestión del cambio es el proceso de identificar, documentar, analizar, priorizar y
acordar cambios en el alcance y el control de cambios y la comunicación a las partes
interesadas. Cambiar el análisis del impacto de alcance nuevo o alterado, que incluye
análisis de requerimientos a nivel de cambio, es una parte importante del proceso de
ingeniería del software, por lo que los analistas de negocio o los desarrolladores de
software a identificar las necesidades alteradas o requerimientos de un cliente,
después de haber identificado estos requisitos son a continuación, en una posición
para volver a diseñar o modificar una solución. Teóricamente, cada cambio puede
afectar el cronograma y el presupuesto de un proyecto de software, y por lo tanto, por
definición, debe incluir el análisis de riesgo-beneficio antes de su aprobación.
 Gestión de configuración de software es el proceso de identificar y documentar el
propio ámbito de aplicación, que es el camino producto de software, incluyendo todos
los sub-productos y los cambios y permite la comunicación de éstos a las partes
interesadas. En general, los procesos empleados incluyen el control de versiones, la
convención de nomenclatura y software acuerdos archivo.
 Gestión de lanzamiento es el proceso de identificar, documentar, priorizar y
consensuar las versiones del software y luego controlar el calendario de lanzamientos
y la comunicación a las partes interesadas. La mayoría de los proyectos de software
tienen acceso a tres ambientes de software para el software que puede ser liberada,
desarrollo, pruebas y producción. En proyectos muy grandes, donde los equipos
distribuidos necesitan integrar su trabajo antes de soltar a los usuarios, a menudo
habrá más entornos de pruebas, llamadas pruebas unitarias, las pruebas del sistema, o
las pruebas de integración, antes de la publicación de las pruebas de aceptación del
usuario.

Un subconjunto de administración de la versión que está ganando cada vez más
atención es la gestión de datos, ya que, obviamente, los usuarios sólo pueden
poner a prueba a partir de datos que se conocen, y los datos "real" es sólo en el
entorno de software llamada "producción". Para poner a prueba su trabajo, los
programadores deben por lo tanto también a menudo crean "datos falsos" o
"recibos de datos". Tradicionalmente, las versiones anteriores de un sistema de
producción fueron utilizadas para este fin, pero como las empresas dependen
cada vez más de los colaboradores externos para el desarrollo de software, los
datos de la empresa no pueden ser entregados a los equipos de desarrollo. En
entornos complejos, conjuntos de datos se pueden crear, que luego se migran a
través de entornos de prueba de acuerdo con un calendario de lanzamientos de
prueba, al igual que el horario general de versión de software.
REFERENCIAS

[1] Heldman, K. “Project Manager ́s Spotlight on Risk management,” Harbor Light Press
2005.

[2] Mersino, A. “Emotional Intelligence for Project Managers: The People Skills You Need
to Achieve Outstanding Results,” American Management Association, 2007.

[3] Peters, L., and Homer, J. “Learning to Lead, to Create Quality, to Influence Change in
Projects,” Project Management Institute.

[4] Lehmann, O. (2013). Nasa-Hundred-Rules-for-Project-Managers.pdf. Obtenido de
http://www.oliverlehmann.com/project-management-sources/Nasa-Hundred-Rules-forProject-Managers.pdf