TEMA: PROYECTO DE SOFTWARE

I.

CONCEPTO

Proyecto es un plan de trabajo, con acciones sistemticas, o sea, coordinadas entre s,

valindose de los medios necesarios y posibles, en busca de objetivos especficos a alcanzar
en un tiempo previsto .Surge con una idea, para obtener metas, ya sea porque an no se
alcanzaron, porque sobran recursos con los fines actuales, porque existen nuevas
necesidades, etctera. Una vez fijada la idea del objetivo, se elabora un diagnstico, sobre las
posibilidades de llevar esa idea adelante, para no emprender un camino hacia metas
imposibles. Luego se elabora el diseo de cmo se va a lograr ese objetivo, previendo los
recursos con los que se cuenta y elaborando estrategias. Luego el plan se pone en
funcionamiento, y a posteriori, se evalan los resultados, para ver si son satisfactorios, y si no,
establecer las causas del fracaso, para modificar ciertas acciones y repensar las estrategias.

II.

DEFINICIN DE PROYECTO

Se define como la aplicacin de conocimientos, herramientas y tcnicas para encontrar una

respuesta adecuada al planteamiento de una necesidad humana por ejemplo alimentacin,
empleo, vivienda, recreacin, educacin, salud, poltica, defensa, cultura.
Un proyecto es un plan que se desarrolla para realizar alguna cosa. Un proyecto puede ser un
pensamiento, una idea, una intencin o propsito de realizar algo y tambin puede ser algo
ms concreto, como un documento con indicaciones para realizar algo. Puede tratarse de un
primer boceto o esquema de cualquier tipo que se realiza como paso previo antes de adoptar
una forma definitiva.
Podra definirse a un proyecto como el conjunto de las actividades que desarrolla una persona
o una entidad para alcanzar un determinado objetivo. Estas actividades se encuentran
interrelacionadas y se desarrollan de manera coordinada.
El sistema permite la definicin de un proyecto mediante los siguientes datos:

Nombre.

Descripcin.

Planteamiento.

Objetivo.

Criterio de anlisis.

III.

Presupuestos.

Documentos asociados.

EL CICLO DE VIDA DEL SOFTWARE

Por ciclo de vida del software, entendemos la sucesin de etapas por las que pasa el software
desde que un nuevo proyecto es concebido hasta que se deja de usar. Estas etapas
representan el ciclo de actividades involucradas en el desarrollo, uso y mantenimiento de
sistemas de software, adems de llevar asociadas una serie de documentos que sern la
salida de cada una de estas fases y servirn de entrada en la fase siguiente.

Tales actividades son:

Adopcin e identificacin del sistema: es importante conocer el origen del sistema, as como
las motivaciones que impulsaron el desarrollo del sistema (por qu, para qu, etctera.).

Anlisis de requerimientos: identificacin de las necesidades del cliente y los usuarios que
el sistema debe satisfacer.

Especificacin: los requerimientos se realizan en un lenguaje ms formal, de manera que se

pueda encontrar la funcin de correspondencia entre las entradas del sistema y las salidas
que se supone que genera. Al estar completamente especificado el sistema, se pueden
hacer estimaciones cuantitativas del coste, tiempos de diseo y asignacin de personal al
sistema, as como la planificacin general del proyecto.

Especificacin de la arquitectura: define las interfaces de interconexin y recursos entre

mdulos del sistema de manera apropiada para su diseo detallado y administracin.

Diseo: en esta etapa, se divide el sistema en partes manejables que, como anteriormente
hemos dicho se llaman mdulos, y se analizan los elementos que las constituyen. Esto
permite afrontar proyectos de muy alta complejidad.

Desarrollo e implementacin: codificacin y depuracin de la etapa de diseo en

implementaciones de cdigo fuente operacional.

Integracin y prueba del software: ensamble de los componentes de acuerdo a la

arquitectura establecida y evaluacin del comportamiento de todo el sistema atendiendo a
su funcionalidad y eficacia.

Documentacin: generacin de documentos necesarios para el uso y mantenimiento.

Entrenamiento y uso: instrucciones y guas para los usuarios detallando las posibilidades y
limitaciones del sistema, para su uso efectivo.

Mantenimiento del software: actividades para el mantenimiento operativo del sistema. Se

clasifican en: evolucin, conservacin y mantenimiento propiamente dicho.

Existen diversos modelos de ciclo de vida, pero cada uno de ellos va asociado a unos
mtodos, herramientas y procedimientos que debemos usar a lo largo de un proyecto.

ETAPAS DEL CICLO DE VIDA DEL SOFTWARE

El ciclo de vida clsico del software siendo uno de los ms utilizados tal como lo plantean
diferentes autores, est conformado en su versin ampliada por siete etapas que se pueden
representar mediante un modelo en cascada as:

INGENIERA DE SISTEMAS: En esta etapa el analista luego de un minucioso y detallado

estudio de los sistemas de una organizacin, detecta un problema o una necesidad que
para su solucin y/o satisfaccin es necesario realizar un desarrollo de software.

ANLISIS: En esta etapa se debe entender y comprender de forma detallada cual es la

problemtica a resolver, verificando el entorno en el cual se encuentra dicho problema, de
tal manera que se obtenga la informacin necesaria y suficiente para afrontar su respectiva
solucin. Esta etapa es conocida como la del QUE se va a solucionar.

DISEO: Una vez que se tiene la suficiente informacin del problema a solucionar, es
importante determinar la estrategia que se va a utilizar para resolver el problema. Esta
etapa es conocida bajo el CMO se va a solucionar.

IMPLEMENTACIN: partiendo del anlisis y diseo de la solucin, en esta etapa se

procede a desarrollar el correspondiente programa que solucione el problema mediante el
uso de una herramienta computacional determinada.

PRUEBAS: Los errores humanos dentro de la programacin de los computadores son

muchos y aumentan considerablemente con la complejidad del problema. Cuando se
termina de escribir un programa de computador, es necesario realizar las debidas pruebas
que garanticen el correcto funcionamiento de dicho programa bajo el mayor nmero de
situaciones posibles a las que se pueda enfrentar.

DOCUMENTACIN: Es la gua o comunicacin escrita en sus diferentes formas, ya sea en

enunciados, procedimientos, dibujos o diagramas que se hace sobre el desarrollo de un
programa. La importancia de la documentacin radica en que a menudo un programa
escrito por una persona, es modificado por otra. Por ello la documentacin sirve para
ayudar a comprender o usar un programa o para facilitar futuras modificaciones
(mantenimiento).

La documentacin se compone de tres partes:

a. Documentacin Interna: Son los comentarios o mensajes que se aaden al cdigo fuente
para hacer ms claro el entendimiento de los procesos que lo conforman, incluyendo las
precondiciones y las poscondiciones de cada funcin.

b. Documentacin Externa: Se define en un documento escrito con los siguientes puntos:

Descripcin del Problema

Datos del Autor

Algoritmo (diagrama de flujo o Pseudocdigo)

Diccionario de Datos

Cdigo Fuente (programa)

c. Manual de Usuario: Describe paso a paso la manera como funciona el programa, con
el fin de que el usuario lo pueda manejar para que obtenga el resultado deseado.

MANTENIMIENTO: una vez instalado un programa y puesto en marcha para realizar la

solucin del problema previamente planteado o satisfacer una determinada necesidad, es
importante mantener una estructura de actualizacin, verificacin y validacin que permitan
a dicho programa ser til y mantenerse actualizado segn las necesidades o requerimientos
planteados durante su vida til. Para realizar un adecuado mantenimiento, es necesario
contar con una buena documentacin del mismo.

MODELOS DE CICLO DE VIDA

Para facilitar una metodologa comn entre el cliente y la compaa de software, los modelos
de ciclo de vida se han actualizado para reflejar las etapas de desarrollo involucradas y la
documentacin requerida, de manera que cada etapa se valide antes de continuar con la
siguiente etapa. Al final de cada etapa se arreglan las revisiones de manera que (texto faltante).
1. Modelo en cascada
El modelo de ciclo de vida en cascada comenz a disearse en 1966 y se termin alrededor de
1970. Se define como una secuencia de fases en la que al final de cada una de ellas se rene
la documentacin para garantizar que cumple las especificaciones y los requisitos antes de
pasar a la fase siguiente:

Ingeniera y Anlisis del Sistema.- Debido a que el software es siempre parte de un

sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del
sistema y luego asignando algn subconjunto de estos requisitos al software.

Anlisis de los requisitos del software.- El proceso de recopilacin de los requisitos se

centra e intensifica especialmente en el software. El ingeniero de software (Analistas) debe
comprender el mbito de la informacin del software, as como la funcin, el rendimiento y
las interfaces requeridas.

Diseo.- El diseo del software se enfoca en cuatro atributos distintos del programa: la
estructura de los datos, la arquitectura del software, el detalle procedimental y la

caracterizacin de la interfaz. El proceso de diseo traduce los requisitos en una

representacin del software con la calidad requerida antes de que comience la codificacin.

Codificacin.- El diseo debe traducirse en una forma legible para la mquina. El paso de
codificacin realiza esta tarea. Si el diseo se realiza de una manera detallada la
codificacin puede realizarse mecnicamente.

Prueba.- Una vez que se ha generado el cdigo comienza la prueba del programa. La
prueba se centra en la lgica interna del software, y en las funciones externas, realizando
pruebas que aseguren que la entrada definida produce los resultados que realmente se
requieren.

Verificacin.- Es la fase en donde el usuario final ejecuta el sistema, para ello el o los
programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle.

Mantenimiento.- El software sufrir cambios despus de que se entrega al cliente. Los

cambios ocurrirn debido a que hayan encontrado errores, a que el software debe
adaptarse a cambios del entorno externo (sistema operativo o dispositivos perifricos), o
debido a que el cliente requiera ampliaciones funcionales o del rendimiento.

CONCLUSIONES:
La aplicacin de la metodologa en cascada se orienta mejora el desarrollo de proyectos de
corto plazo, de poca innovacin y proyectos definitivos y detallados. Para comenzar la
aplicacin de la metodologa en cascada se necesita tener el anlisis de los requerimientos
bien definidos, el resultado del desarrollo depender de que estos requerimientos sean los
adecuados para satisfacer la necesidad del proyecto. Se caracteriza por cumplir un orden
secuencial en el desarrollo de sus tareas esto implica retardar el avance del proyecto ya que
cada etapa inicia cuando haya finalizado la anterior siempre y cuando se haya realizado la
evaluacin respectiva y resuelto los errores en caso de que los hubiera tenido. Los resultados
del proyecto solo se pueden conocer a partir de que se llegue a la aplicacin, hasta entonces el
cliente deber tener paciencia para esperar los resultados.
Ventajas al usar este mtodo son:

Se tiene todo bien organizado y no se mezclan las fases.

Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo.

Ayuda a minimizar los gastos de la planificacin porque permite realizarla sin planificacin
porque permite realizarla sin problemas.

Las desventajas al usar este mtodo son:

Gran dependencia en los requerimientos iniciales.

Difcilmente un cliente va a establecer al principio todos los requerimientos necesarios, por

lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y
no permite movilizarse entre fases.

El modelo genera pocos signos visibles de progreso hasta el final. Esto puede dar la
impresin de un desarrollo lento, existe la incertidumbre de los clientes si sus proyectos
sern entregados a tiempo.

Inicio de la codificacin muy tarde en el ciclo de vida del proyecto

2. Modelo V
El modelo de ciclo de vida V proviene del principio que establece que los procedimientos
utilizados para probar si la aplicacin cumple las especificaciones ya deben haberse creado en
la fase de diseo.

En los niveles lgicos del 1 al 4, para cada fase del desarrollo, existe una fase correspondiente
o paralela de verificacin o validacin. Esta estructura obedece al principio de que para cada
fase del desarrollo debe existir un resultado verificable.
En la misma estructura se advierte tambin que la proximidad entre una fase del desarrollo y su
fase de verificacin correspondiente va decreciendo a medida que aumenta el nivel dentro de
la V. La longitud de esta separacin intenta ser proporcional a la distancia en el tiempo entre
una fase y su homloga de verificacin.

El nivel 1 est orientado al cliente. El inicio del proyecto y el fin del proyecto constituyen
los dos extremos del ciclo. Se compone del anlisis de requisitos y especificaciones, se
traduce en un documento de requisitos y especificaciones.

El nivel 2 se dedica a las caractersticas funcionales del sistema propuesto. Puede

considerarse el sistema como una caja negra, y caracterizarla nicamente con aquellas

funciones que son directa o indirectamente visibles por el usuario final, se traduce en un
documento de anlisis funcional.

El nivel 3 define los componentes hardware y software del sistema final, a cuyo conjunto se
denomina arquitectura del sistema.

El nivel 4 es la fase de implementacin, en la que se desarrollan los elementos unitarios o

mdulos del programa.

Ventajas y desventajas del Modelo en V

Ventajas:

La relacin entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la
localizacin de fallos.

Es un modelo sencillo y de fcil aprendizaje.

Hace explcito parte de la iteracin y trabajo que hay que revisar.

Especifica bien los roles de los distintos tipos de pruebas a realizar.

Involucra al usuario en las pruebas.

Desventajas:

Es difcil que el cliente exponga explcitamente todos los requisitos.

El cliente debe tener paciencia pues obtendr el producto al final del ciclo de vida.

Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas.

El producto final obtenido puede que no refleje todos los requisitos del usuario.

3. Modelo en Espiral

El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software en gran

escala. Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el
usuario comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. El
modelo en espiral utiliza la construccin de prototipos como mecanismo de reduccin de
riesgos, pero lo que es ms importante, permite a quien lo desarrolla aplicar el enfoque de
construccin de prototipos en cualquier etapa de evolucin del producto. Mantiene el enfoque
sistemtico de los pasos sugeridos por el ciclo de vida clsico, pero lo incorpora al marco de
trabajo interactivo que refleja mejor el mundo real. El modelo demanda una consideracin
directa de los riesgos tcnicos en todas las etapas del proyecto, y si se aplica adecuadamente,
debe reducir los riesgos antes de que se conviertan en problemticos. Puede resultar difcil
convencer a grandes clientes, (particularmente en situaciones bajo contrato) de que el enfoque
evolutivo que presenta este modelo es controlable. Requiere una considerable habilidad para la
evaluacin del riesgo, y de ello depende el xito.

El Modelo en Espiral se divide en un nmero de actividades estructurales, tambin llamadas

"regiones de tareas" . Generalmente existen entre tres y seis regiones de tareas:

1. Comunicacin con el cliente.- Las tareas requeridas para establecer comunicacin entre
el desarrollador y el cliente, sea revisar especificaciones, plantear necesidades, etc.

2. Planificacin.- Las tareas requeridas para definir recursos, tiempos e informacin relacionada
con el proyecto.

3. Anlisis de riesgos.- Las tareas requeridas para evaluar riesgos tcnicos y de gestin.

4. Ingeniera.- Las tareas requeridas para construir una o ms representaciones de la

aplicacin

5. Construccin y adaptacin.- Las tareas requeridas para construir, probar, instalar y

proporcionar soporte al usuario.

6. Evaluacin del cliente.- Las tareas requeridas para obtener la reaccin del cliente, segn la
evaluacin de las representaciones del software creadas durante la etapa de ingeniera e
implementada durante la etapa de instalacin.

Cada una de las regiones estn pobladas por una serie de tareas que se adaptan a las
caractersticas del proyecto que va a emprenderse. Para proyectos pequeos el nmero de
tareas y su formalidad es bajo, para proyectos mayores y ms crticos, cada regin
contiene tareas que se definen para lograr un nivel ms alto de formalidad.
Cuando empieza este proceso evolutivo, el equipo de trabajo gira alrededor de las agujas
del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de
una especificacin de productos, los pasos siguientes en la espiral se podran utilizar para
desarrollar un prototipo y progresivamente versiones ms sofisticadas del software.
Cada paso de la regin de planificacin produce ajustes en el plan del proyecto. . El coste y
la planificacin se ajustan en funcin de la evaluacin del cliente. Adems, el gestor del
proyecto ajusta el nmero planificado de iteraciones requeridas para completar el proyecto
o el producto software de que se trate.
La siguiente figura muestra grficamente el Modelo Espiral, para las seis regiones de
tareas y suponiendo un proyecto tal que forzosamente requiere iniciar en la
conceptualizacin previa a la vuelta de desarrollo, an cuando hemos dicho que
frecuentemente se puede iniciar desde esta tarea. Asimismo, se presenta la terminacin del
proyecto en la ltima vuelta, como mantenimiento del mismo proyecto, pareciese que ah
terminase el ciclo, sin embargo, la vuelta siguiente existe y corresponde al inicio de un
nuevo proyecto que puede o no tomar como base el proyecto anterior.

Ventajas y desventajas del Modelo en Espiral

Ventajas:

Incorpora muchas de las ventajas de los otros ciclos de vida

Conjuga la naturaleza iterativa de los prototipos con los aspectos controlados y sistemticos
del modelo clsico

Proporciona el potencial para el desarrollo rpido de versiones incrementales

Puede adaptarse y aplicarse a lo largo de la vida del software

Es un enfoque realista del desarrollo del software

Permite aplicar el enfoque de construccin de prototipos en cualquier momento para reducir

riesgos

Reduce los riesgos antes de que se conviertan en problemticos

Controla muy bien los riesgos y mientras ms iteraciones se realicen, menos riesgos habr

Monitoriza y controla los riesgos continuamente

Desventajas:

IV.

Puede resultar difcil convencer a algunos clientes de que el enfoque evolutivo es

controlable

Slo resulta aplicable para proyectos de gran tamao

Supone una carga de trabajo adicional, no presente en otros ciclos de vida

Requiere una considerable habilidad para la evaluacin y resolucin del riesgo, y se basa
en esta habilidad para el xito

Si un riesgo importante no es descubierto y gestionado, indudablemente surgirn problemas

Es bastante complicado de realizar y su complejidad puede incrementarse hasta hacerlo

impracticable

El modelo no se ha utilizado tanto como otros, por lo que tendrn que pasar aos antes de
que determine con certeza la eficacia de este modelo.

PROCESO DE DESARROLLO DE SOFTWARE

Se pretende desarrollar un tema bastante especial en el proceso de desarrollo de software, el
cual es la base para que todo proyecto independientemente de cual sea su porte- se realice de
forma correcta y entendible.
El trabajo consta de tres grandes partes las cuales son:

Los fundamentos principales de una especificacin de requerimientos.

Las metodologas que se aplican hoy en da para su construccin.

Una tercera parte en donde se pretende conocer cmo se lleva a cabo dicho proceso en
una empresa de software.

1. Fundamentos del Anlisis de Requerimientos

Es el conjunto de tcnicas y procedimientos que nos permiten conocer los elementos
necesarios para definir un proyecto de software, es la etapa ms crucial del desarrollo de un
proyecto de software.
La IEEE los divide en funcionales y no funcionales:

Funcionales: Condicin o capacidad de un sistema requerida por el usuario para resolver un

problema o alcanzar un objetivo.

No Funcionales: Condicin o capacidad que debe poseer un sistema par satisfacer un

contrato, un estndar, una especificacin u otro documento formalmente impuesto.
Para realizar bien el desarrollo de software es esencial realizar una especificacin completa de
los requerimientos de los mismos. Independientemente de lo bien diseado o codificado que
est, un programa pobremente especificado decepcionar al usuario y har fracasar el
desarrollo.
Tanto el que desarrolla el software como el cliente tienen un papel activo en la especificacin
de requerimientos. El cliente intenta reformular su concepto, algo nebuloso, de la funcin y
comportamiento de los programas en detalles concretos.

2. Anlisis de Requerimientos
El anlisis de requerimientos es la tarea que plantea la asignacin de software a nivel de
sistema y el diseo de programas. El anlisis de requerimientos facilita al ingeniero de sistemas
especificar la funcin y comportamiento de los programas, indicar la interfaz con otros
elementos del sistema y establecer las ligaduras de diseo que debe cumplir el programa. El
anlisis de requerimientos permite al ingeniero refinar la asignacin de software y representar
el dominio de la informacin que ser tratada por el programa. El anlisis de requerimientos de
al diseador la representacin de la informacin y las funciones que pueden ser traducidas en
datos, arquitectura y diseo procedimental. Finalmente, la especificacin de requerimientos
suministra al tcnico y al cliente, los medios para valorar la calidad de los programas, una vez
que se haya construido.

3. Tareas del Anlisis

El anlisis de requerimientos puede dividirse en cuatro reas:

Reconocimiento del problema

Evaluacin y sntesis

Especificacin

Revisin.

Inicialmente, el analista estudia la especificacin del sistema (si existe) y el plan de proyecto.
Es importante comprender el contexto del sistema y revisar el mbito de los programas que se
us para generar las estimaciones de la planificacin. A continuacin, debe establecerse la
comunicacin necesaria para el anlisis, de forma que se asegure el reconocimiento del
problema.
Las formas de comunicacin requeridas para el anlisis se ilustran en la Figura 2. El analista
debe establecer contacto con el equipo tcnico y de gestin del usuario/cliente y con la
empresa que vaya a desarrollar el software. El gestor del programa puede servir como
coordinador para facilitar el establecimiento de los caminos de comunicacin. El objetivo del
analista es reconocer los elementos bsicos del programa tal como lo percibe el
usuario/cliente.

La evaluacin del problema y la sntesis de la solucin es la siguiente rea principal de trabajo

del anlisis. El analista debe evaluar el flujo y estructura de la informacin, refinar en detalle
todas las funciones del programa, establecer las caractersticas de la interfase del sistema y
descubrir las ligaduras del diseo, Cada una de las tareas sirven para descubrir el problema de
forma que pueda sintetizarse un enfoque o solucin global.
Las tareas asociadas con el anlisis y especificacin existen para dar una representacin del
programa que pueda ser revisada y aprobada por el cliente. En un mundo ideal el cliente
desarrolla una especificacin de requerimientos del software completamente por s mismo.
Esto se presenta raramente en el mundo real. En el mejor de los casos, la especificacin se
desarrolla conjuntamente entre el cliente y el tcnico.
Adems, se realiza una nueva apreciacin del plan del proyecto de software para determinar si
las primeras estimaciones siguen siendo validas despus del conocimiento adicional obtenido
durante el anlisis.

4. Principios del Anlisis

En la pasada dcada, se desarrollaron varios mtodos de anlisis y especificacin del software.
Los investigadores han identificado los problemas y sus causas y desarrollando reglas y
procedimientos para resolverlos. Cada mtodo de anlisis tiene una nica notacin y punto de
vista. Sin embargo, todos los mtodos de anlisis estn relacionados por un conjunto de
principios fundamentales:

El dominio de la informacin, as como el dominio funcional de un problema debe ser

representado y comprendido.

El problema debe subdividirse de forma que se descubran los detalles de una manera
progresiva (o jerrquica)

Deben desarrollarse las representaciones lgicas y fsicas del sistema.

Aplicando estos principios, el analista enfoca el problema sistemticamente. Se examina el

dominio de la informacin de forma que pueda comprenderse su funcin mas
completamente. La particin se aplica para reducir la complejidad. La visin lgica y fsica
del software, es necesaria para acomodar las ligaduras lgicas impuestas por los
requerimientos de procesamiento, y las ligaduras fsicas impuestas por otros elementos del
sistema.

5. El dominio de la Informacin
Todas las aplicaciones del software pueden colectivamente llamarse procesamiento de datos.
Este trmino contiene la clave de lo que entendemos por requerimientos del software. El
software se construye para procesar datos; para transformar datos de una forma a otra; esto
es, para aceptar entrada, manipularla de alguna forma y producir una salida. Este
establecimiento fundamental de los objetivos es verdad tanto si construimos software por lotes

para un sistema de nominas, como software empotrado en tiempo real para controlar el flujo de
la gasolina de un motor de automvil; el dominio de la informacin contiene tres visiones
diferentes de los datos que se procesan por los programas de computadoras:

El flujo de informacin.

El contenido de la informacin.

La estructura de la informacin.

Para comprender completamente el dominio de la informacin, deben considerarse cada una

de estas tres partes.
El flujo de la informacin representa la manera en la que los datos cambian conforme pasan a
travs de un sistema. Refirindonos a la siguiente figura, la entrada se transforma en datos
intermedios y ms adelante se transforma en la salida.

6. Particin
Normalmente los problemas son demasiado grandes y complejos para ser comprendidos como
un todo. Por esta razn, tendemos a particionar (dividir) tales problemas en partes que puedan
ser fcilmente comprendidas, y establecer interfases entre las partes, de forma que se realice

la funcin global. Durante el anlisis de requerimientos, el dominio funcional y el dominio de la

informacin del software pueden ser particionados.
En esencia la particin descompone un problema en sus partes constituyentes.
Conceptualmente, establecemos una representacin jerrquica de la funcin o informacin y
luego partimos el elemento superior mediante:

Incrementando los detalles, movindonos verticalmente en la jerarqua.

Descomponiendo funcionalmente el problema, movindose horizontalmente en la jerarqua.

7. Visiones Lgicas y Fsicas

La visin lgica de los requerimientos del software presenta las funciones que han de
realizarse y la informacin que ha de procesarse independientemente de los detalles de
implementacin.

La visin fsica de los requerimientos del software presenta una manifestacin del mundo real
de las funciones de procesamiento y las estructuras de informacin. En algunos casos se
desarrolla una representacin fsica como el primer paso del diseo del software. Sin embargo
la mayora de los sistemas basados en computador, se especifican de forma que se dictan
ciertas recomendaciones fsicas.
8. Construccin de Prototipos de Software
En anlisis debe ser conducido independientemente del paradigma de ingeniera de software
aplicado. Sin embargo, la forma que ese anlisis tomara puede variar. En algunos casos es
posible aplicar los principios de anlisis fundamental y derivar a una especificacin en papel del
software desde el cual pueda desarrollarse un diseo. En otras situaciones, se va a una
recoleccin de los requerimientos, se aplican los principios de anlisis y se construye un
modelo de software, llamado un prototipo, segn las apreciaciones del cliente y del que lo
desarrolla. Finalmente, hay circunstancias que requieren la construccin de un prototipo al
comienzo del anlisis, puesto que el modelo es el nico mediante el que los requerimientos
pueden ser derivados efectivamente.

9. Un escenario para la construccin de prototipos

Todos los proyectos de ingeniera de software comienzan con una peticin del cliente. La
peticin puede estar en la forma de una memoria que describe un problema, un informe que
define un conjunto de objetivos comerciales o del producto, una peticin de propuesta formal
de una agencia o compaa exterior, o una especificacin del sistema que ha asignado una
funcin y comportamiento al software, como un elemento de un sistema mayor basado en
computadora. Suponiendo que existe una peticin para un programa de una de las formas
dichas anteriormente, para construir un prototipo del software se aplican los siguientes pasos:

PASO 1. Evaluar la peticin del software y determinar si el programa a desarrollar es un buen

candidato para construir un prototipo.

PASO 2. Dado un proyecto candidato aceptable, el analista desarrolla una representacin

abreviada de los requerimientos.
Antes de que pueda comenzar la construccin de un prototipo, el analista debe representar los
dominios funcionales y de informacin del programa y desarrollar un mtodo razonable de
particin. La aplicacin de estos principios de anlisis fundamentales, pueden realizarse
mediante los mtodos de anlisis de requerimientos.

PASO 3. Despus de que se haya revisado la representacin de los requerimientos, se crea un

conjunto de especificaciones de diseo abreviadas para el prototipo.
El diseo debe ocurrir antes de que comience la construccin del prototipo.

PASO 4. El software del prototipo se crea, prueba y refina Idealmente, los bloques de
construccin de software preexisten se utilizan para crear el prototipo de una forma rpida.
Desafortunadamente, tales bloques construidos raramente existen.

PASO 5. Una vez que el prototipo ha sido probado, se presenta al cliente, el cual "conduce la
prueba" de la aplicacin y sugiere modificaciones.
Este paso es el ncleo del mtodo de construccin de prototipo. Es aqu donde el cliente puede
examinar una representacin implementada de los requerimientos del programa, sugerir
modificaciones que harn al programa cumplir mejor las necesidades reales.

PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos estn
formalizados o hasta que el prototipo haya evolucionado hacia un sistema de produccin.

10. Especificacin
No hay duda de que la forma de especificar tiene mucho que ver con la calidad de la solucin.
Los ingenieros de software que se han esforzado en trabajar con especificaciones incompletas,
inconsistentes o mal establecidas han experimentado la frustracin y confusin que
invariablemente se produce. Las consecuencias se padecen en la calidad, oportunidad y
completitud del software resultante.
Los lenguajes de especificacin formal conducen a representaciones formales de los
requerimientos que pueden ser verificados o analizados.

11. Principios de Especificacin

La especificacin, independientemente del modo en que se realice, puede ser vista como un
proceso de representacin. Los requerimientos se representan de forma que conduzcan
finalmente a una correcta implementacin del software.

12. Mtodos de Anlisis de Requerimientos

Las metodologas de anlisis de requerimientos combinan procedimientos sistemticos con una
notacin nica para analizar los dominios de informacin y funcional de un problema de
software; suministra un conjunto de heursticas para subdividir el problema y define una forma
de representacin para las visiones lgicas y fsicas. En esencia, los mtodos de anlisis de
requerimientos del software, facilitan al ingeniero de software aplicar principios de anlisis
fundamentales, dentro del contexto de un mtodo bien definido.
El papel de los mtodos de anlisis de requerimientos, es asistir al analista en la construccin
de "una descripcin precisa e independiente" del elemento software de un sistema basado en
computadora.

13. Metodologas de Anlisis de Requerimientos

Las metodologas de anlisis de requerimientos facilitan al analista la aplicacin de los
principios fundamentales del anlisis de una manera sistemtica.
Caractersticas Comunes
Aunque cada mtodo introduce nueva notacin y heurstica de anlisis, todos los mtodos
pueden ser evaluados en el contexto de las siguientes caractersticas comunes:

Mecanismos para el anlisis del dominio de la informacin

Mtodo de representacin funcional

Definicin de interfaces

Mecanismos para subdividir el problema

Soporte de la abstraccin

Representacin de visiones fsicas y lgicas

Aunque el anlisis del dominio de la informacin se conduce de forma diferente en cada

metodologa, pueden reconocerse algunas guas comunes.
Todos los mtodos se enfocan (directa o indirectamente) al flujo de datos y al contenido o
estructura de datos. En la mayora de los casos el flujo se caracteriza en el contexto de las

transformaciones (funciones) que se aplican para cambiar la entrada en la salida. El contenido

de los datos puede representarse explcitamente usando un mecanismo de diccionario o,
implcitamente, enfocando primero la estructura jerrquica de los datos.
Las funciones se describen normalmente como transformaciones o procesos de la informacin.

14. Mtodos de Anlisis Orientados al Flujo de Datos

La informacin se transforma como un flujo a travs de un sistema basado en computadora. El
sistema acepta entrada de distintas formas; aplica un hardware, software y elementos humanos
para transformar la entrada en salida; y produce una salida en distintas formas. La entrada
puede ser una seal de control transmitida por un transductor, una serie de nmeros escritos
por un operador humano, un paquete de informacin transmitido por un enlace a red, o un
voluminoso archivo de datos almacenado en memoria secundaria.

Una tcnica para representar el flujo de informacin a travs del sistema basado en
computadora se ilustra en la figura . La funcin global del sistema se representa como una
transformacin sencilla de la informacin, representada en la figura como una burbuja. Una o
ms entradas. Representadas como flechas con etiqueta, conducen la transformacin para
producir la informacin de salida. Puede observarse que el modelo puede aplicarse a todo el
sistema o solo a un elemento de software. La clave es representar la informacin dada y
producida por la transformacin.

15. Diagramas de Flujos de Datos

Conforme con la informacin se mueve a travs del software, se modifica mediante una serie
de transformaciones. Un diagrama de flujos de datos (DFD), es una tcnica grafica que
describe el flujo de informacin y las transformaciones que se aplican a los datos, conforme se
mueven de la entrada a la salida. La forma bsica de un DFD se ilustra en la figura. El
diagrama es similar en la forma a otros diagramas de flujo de actividades, y ha sido
incorporado en tcnicas de anlisis y diseos propuesto por Yourdon y Constantine, DeMarco y
Gane y Sarson. Tambin se le conoce como un grafo de flujo de datos o un diagrama de
burbujas.

16. Descripciones Funcionales

Una vez que ha sido representado el dominio de la informacin (usando un DFD y un
diccionario de datos), el analista describe cada funcin (transformacin) representada, usando
el lenguaje natural o alguna otra notacin estilizada. Una de tales notaciones se llama ingls
estructurado (tambin llamado lenguaje de diseo del programa o proceso(LDP)). El ingls
estructurado incorpora construcciones procedimentales bsicas secuencia, seleccin y
repeticin- junto con frases del lenguaje natural, de forma que pueden desarrollarse
descripciones procedimentales precisas de las funciones representadas dentro de un DFD.

17. Mtodos Orientados a la Estructura de Datos

Hemos ya observado que el dominio de la informacin para un problema de software
comprende el flujo de datos, el contenido de datos y la estructura de datos. Los mtodos de
anlisis orientados a la estructura de datos representan los requerimientos del software
enfocndose hacia la estructura de datos en vez de al flujo de datos. Aunque cada mtodo
orientado a la estructura de datos tiene un enfoque y notacin distinta, todos tienen algunas
caractersticas en comn:

a. Todos asisten al analista en la identificacin de los objetos de informacin clave (tambin

llamados entidades o tems) y operaciones (tambin llamadas acciones o procesos).
b. Todos suponen que la estructura de la informacin es jerrquica.
c. Todos requiere que la estructura de datos se representan usando la secuencia, seleccin y
repeticin.
d. Todos dan una conjunto de pasos para transformar una estructura de datos jerrquica en
una estructura de programa.

V.

DEFINICIN DE LA VISIN DEL PROYECTO

La importancia de la visin radica en que es una fuente de inspiracin para el negocio,

representa la esencia que gua la iniciativa, de l se extraen fuerzas en los momentos difciles y
ayuda a trabajar por un motivo y en la misma direccin.

Desde el punto de vista de construccin de una aproximacin global del sistema:

institucionalidad cultural en interaccin y comunicacin con su entorno o campo cultural, resulta
coherente postular que los proyectos no deberan constituir unidades aisladas, nicas y
autorreferenciales respecto de un problema, necesidad o situacin sobre la cual hemos tomado
la decisin de actuar, es decir, entendemos el proyecto como una unidad lgica de actuacin
respecto de la globalidad en donde eventualmente intervienen otras acciones.
Una visin establece entonces que si bien un proyecto, como unidad, culmina en un
determinado momento, sus resultados deberan sentar condiciones de sostenibilidad, esto es,
la posibilidad de continuidad de procesos en el accionar o actividad normal de la institucin o
mediante la realizacin de otros proyectos .

Visin del software por desarrollar

Para los voluntarios del PEA Vida Abundante, quienes requieren mejorar sus canales de
comunicacin y gestionar la informacin de los expedientes de manera centralizada y
accesible.

Desde cualquier lugar el Sistema de Expediente Electrnico del PEA es un sistema

colaborativo.

De gestin de la informacin al estilo de una red social que les ayudar a eliminar el uso de
expedientes de papel y a diferencia del sistema de expedientes que actualmente llevan en
papel.

Nuestro producto les permitir tener acceso a la informacin a travs del Internet, les
facilitar la.

Comunicacin por correo electrnico y les ayudar a reducir el uso de papel en sus
procesos.

Planificacin del alcance de un proyecto.

El plan de gestin del alcance del proyecto es una herramienta de planificacin que describe
cmo el equipo definir el alcance del proyecto, desarrollar el enunciado del alcance del
proyecto detallado, definir y desarrollar la estructura de desglose del trabajo, verificar y
controlar el alcance del proyecto.
La verificacin del alcance es el proceso de obtener la aceptacin formal por parte de los
interesados del alcance del proyecto completado y los productos entregables relacionados.
Verificar el alcance del proyecto incluye revisar los productos entregables para asegurarse de
que cada uno se complete satisfactoriamente
Si el proyecto se termina antes de lo previsto, el proceso de verificacin del alcance del
proyecto debera establecer y documentar el nivel y alcance de lo completado.
Entradas

Enunciado del Alcance del Proyecto.

Plan de Gestin del Alcance del Proyecto.

Productos Entregables Los productos entregables son aquellos que se han completado total
o parcialmente, y constituyen una salida del proceso Dirigir y Gestionar la Ejecucin del
Proyecto.

Herramientas y Tcnicas

Inspeccin Medir, examinar y verificar, a fin de determinar si el trabajo y los productos

entregables cumplen con los requisitos y los criterios de aceptacin del producto.

Las inspecciones pueden denominarse revisiones, revisiones de productos, auditoras y

revisiones generales.

Salidas

Productos Entregables Aceptados.

Cambios Solicitados.

Acciones Correctivas Recomendadas.

Cada proyecto exige un delicado equilibrio entre las herramientas, las fuentes de datos, las
metodologas, los procesos y los procedimientos, y otros factores, con el fin de asegurar que el
esfuerzo dedicado a actividades para determinar el alcance sea acorde al tamao, la
complejidad y la importancia del proyecto.

VI.

GESTIN DEL TIEMPO DEL PROYECTO

La gestin del tiempo incluye todas las actividades necesarias para conseguir cumplir con el objetivo de fecha
de entrega del producto del proyecto. Incluye las siguientes actividades: identificacin de actividades,
secuenciamiento lgico de actividades, estimacin de duracin de las actividades, y elaboracin del
cronograma de proyecto. Para la elaboracin del cronograma veremos diversos mtodos como el PERT-CPM
con nivelado de recursos, la simulacin, y el mtodo de cadena crtica.

a. Identificacin de Actividades
Las tareas en que se dividen los paquetes de trabajo del proyecto se componen de actividades
que son los entregables de menor nivel del EDT/WBS. La descomposicin de las tareas en
actividades ha de realizarse por tanto, a partir del EDT/WBS del proyecto. En el caso de
grandes proyectos, la descomposicin en actividades slo puede realizarse a corto plazo ya
que es entonces cuando es posible descomponer el alcance a nivel de paquete de trabajo y es
posible realizar una planificacin de detalle. A medio y largo plazo, la desagregacin de las
diferentes ramas del EDT/WBS aun no se ha producido o es baja, por lo que la identificacin y
planificacin ser la correspondiente a actividades no desagregadas de alto nivel
(agrupaciones de actividades o actividades resumen, e hitos). Existen por tanto diferentes
niveles de identificacin y planificacin en funcin del grado de desagregacin del EDT/WBS.
En la identificacin de actividades e hitos pueden emplearse listas de actividades o plantillas de
proyectos similares realizados en la organizacin ejecutante. Estas listas habrn de ser
revisadas de acuerdo al proyecto de que se trate, aadiendo o suprimiendo actividades.

b. Secuenciamiento de Actividades
Una vez identificadas los hitos y las actividades de diferente nivel que componen el alcance del
proyecto, es preciso identificar y documentar las relaciones lgicas que existen entre ellas.
Para ello pueden utilizarse redes o plantillas de proyectos anteriores similares o porciones de
estas redes, tambin llamadas subredes.

Las relaciones de prelacin o dependencias existentes entre las actividades del proyecto
pueden venir impuestas por la naturaleza del trabajo a realizar (dependencias mandatorias),
ser establecidas o elegidas por el equipo de proyecto (dependencias discrecionales), o ser
impuestas externamente (dependencias externas). Como ejemplo de estas ltimas podemos
citar el caso en el que el cliente requiera una revisin especfica para verificar la calidad de
algn componente especfico del proyecto. Existen dos mtodos o diagramas de redes
utilizados para representar grficamente las relaciones lgicas entre las actividades del
proyecto:

Mtodo PDM (Precedence Diagramming Method): este mtodo utiliza nodos para
representar las actividades. Los nodos estn conectados mediante flechas para mostrar
las relaciones de prelacin entre las actividades. Los solapes y desplazamientos entre
actividades pueden ser representados en este mtodo, indicando su duracin sobre la
flecha correspondiente. Este mtodo recibe tambin el nombre de Actividad Sobre
Nodo (AON: Activity On Node) y es el mas utilizado por las aplicaciones informticas
de gestin de proyectos.

Mtodo ADM (Arrow Diagramming Method): este mtodo utiliza flechas para
representar las actividades del proyecto. Las actividades estn conectadas mediante
sucesos que muestran las relaciones de prelacin entre ellas. El mtodo tambin es
conocido como Actividad Sobre Flecha (AOA: Activity on Arrow).

c. Estimacin de los recursos de las actividades

Proceso que consiste en determinar el tipo y las cantidades de materiales, personas, equipos,
instalaciones y suministros requeridos para ejecutar cada actividad.

d. Estimacin de la duracin de las actividades

La estimacin de la duracin de las actividades exige determinar previamente las cantidades y
los tipos de recursos necesarios. Para ello podemos recurrir a diversas alternativas como: la
opinin de expertos, anlisis de alternativas de ejecucin (con diferentes combinaciones de
recursos y cantidades), informacin publicada (tasas e produccin, etc), estimacin de detalle,
etc. La estimacin de recursos por actividad servir tambin para determinar su coste, por lo
que ambos procesos de estimacin de coste y duracin se realizan en paralelo. Una vez
obtenidos los recursos necesarios o esfuerzo correspondientes a la actividad es posible, caso

de conocer la disponibilidad de recursos de acuerdo a los calendarios de los mismos,

determinar la duracin de las actividades del proyecto. No obstante, la disponibilidad real de
recursos en esta fase es casi siempre aproximada y deber ser verificada en una fase posterior
(ver ms adelante, apartado: Nivelado de recursos). En cualquier caso, es muy conveniente
que en la estimacin de duracin participe activamente el responsable de su ejecucin.
Por regla general la duracin de la tarea es una estimacin razonable que es recomendable
que se realice:

En base a las estimaciones en las experiencias de otras personas, normalmente

responsables de la ejecucin de esas tareas.

En base a las estimaciones en su propia experiencia, si ya ha tenido experiencia en la

realizacin de las tareas descritas.

En base a datos de otros proyectos (estimacin por analoga) si se disponen de

registros adecuados y fiables.

En base a una estimacin paramtrica. La estimacin paramtrica utiliza una relacin

estadstica entre los datos histricos y otras variables para calcular una estimacin de
parmetros de una actividad tales como coste, presupuesto y duracin.

e. Desarrollo del Cronograma

El cronograma del proyecto (project schedule) puede definirse como el conjunto de fechas
planificadas para realizar las actividades e hitos del proyecto, y constituye el Plan de
Referencia de Tiempo o Lnea de Base de Tiempos contra la que se medir el progreso
alcanzado durante la ejecucin. La determinacin del cronograma se realiza a partir de la lista
de actividades, la relacin lgica entre ellas expresada en forma de diagrama de red, la
duracin de las actividades, la disponibilidad de recursos (ver nivelado de recursos), y el
anlisis de riesgos realizado en el que se identifican los riesgos principales del proyecto
(registro de riesgos). Respecto a este ltimo punto, se prestar especial atencin a los puntos
de convergencia de la red, que suelen ser hitos de proyecto donde el riesgo puede ser elevado.
En muchos proyectos existen adems fechas impuestas externamente que afectan a la
elaboracin del cronograma de proyecto. As por ejemplo, puede haber una fecha de
terminacin de proyecto como sucede en un proyecto bajo contrato donde existe una fecha
impuesta por el cliente, una fecha marcada por una regulacin de carcter obligatorio, una
fecha de terminacin impuesta por una oportunidad de mercado, etc. Tambin puede haber
fechas relacionada con el comienzo (como por ejemplo, iniciar el proyecto una vez firmado el
contrato) o fechas intermedias relacionadas con entregables determinados (como sucede en el
caso de entregables de proyecto que son inputs de otros proyectos dentro del mismo
programa).
Estas fechas impuestas hacen que en muchos casos sea necesario recurrir a determinadas
tcnicas (compresin de actividades, trabajo en paralelo, etc) durante la planificacin del
cronograma de proyecto.

f. Control del Cronograma

Controlar el Cronograma es el proceso por el que se da seguimiento al estado del proyecto
para actualizar el avance del mismo y gestionar cambios a la lnea base del cronograma.

El software de gestin de proyectos para la elaboracin de cronogramas permite hacer un

seguimiento de las fechas planificadas en comparacin con las fechas reales, y de proyectar
los efectos de los cambios al cronograma del proyecto.
VII.

DEFINICIN DE ACTIVIDADES Y SECUENCIAS

Todas las actividades que se realizan para cumplir con un fin principal definido, en un tiempo
establecido utilizando recursos tanto humanos como materiales y para el cual se debe tener
presupuestados los costos en que se incurrirn.
El objetivo principal de la Gestin de Proyectos es administrar, planificar, coordinar,
seguimiento y control de todas las actividades y los recursos asignados para la ejecucin del
proyecto de una forma que se pueda cumplir con el alcance en el tiempo establecido y con los
costos presupuestados.
En todo proyecto participa un ejecutor o gestor, los beneficiarios finales y los actores
institucionales.

Las reas que son determinantes para el xito de un buen proyecto son: la visibilidad,
desviaciones, frecuencia, toma de decisiones y las tcnicas de seguimiento. Adems de esto la
comunicacin es el proceso esencial de la gestin de proyectos, desde la etapa de inicio hasta
la de cierre, es importante saber bien Qu se comunica y de qu manera? Con qu
frecuencia y grado de detalle? Todo esto para dar a conocer de una forma clara las metas y
propsitos y lograr que se cumplan.
Sin importar la dimensin del tamao del proyecto es necesario que cuenten con un
administrador o gestor de proyectos que cuente con habilidades para poder manejar de manera
eficiente las diferentes etapas del proyecto y tomar las medidas necesarias.
De acuerdo con el Project Management Institute (PMI) las caractersticas de un proyecto son:

Un producto, bien o artculo producido, que es cuantificable y que puede ser un elemento
terminado o un componente o un servicio prestado.

La capacidad de prestar un servicio como, por ejemplo, la capacidad de produccin o de

prestacin de servicio de las funciones del negocio, que respaldan la produccin, la
distribucin, etc.

Un resultado que puede ser obtenido de diversas formas: salidas, documentos, ideas, etc.

La singularidad es una caracterstica importante de los productos o entregables de un

proyecto.

La elaboracin gradual, que es una caracterstica de los proyectos que acompaa a los
conceptos de temporal y nico. Elaboracin gradual significa desarrollar en pasos e ir
aumentando mediante incrementos.

Las tres restricciones principales o posibilidades de alteracin en los proyectos son el alcance,
tiempo y costos.

Los proyectos se dividen en fase con el objetivo primordial de facilitar la gestin y mejorar el
control de una forma que se pueda mantener alineado con los objetivos establecidos.
Para poder administrar un proyecto en un contexto de calidad, este deber pasar por varias
fases, al final de las cuales debern definirse los acontecimientos importantes. Cada etapa se
relaciona con una prestacin y una validacin basadas en un documento especfico.

Las etapas, actividades, o ciclo de vida de la gestin de proyecto son las definidas a
continuacin:

a. Iniciacin
En esta parte es donde se comienza el proyecto, se identifica una idea, aqu se redacta la
propuesta especfica del proyecto, los objetivos, el alcance, la calidad, se estima como se
llevar a cabo y se hace una evaluacin de los riesgos, adems se hacen estimaciones de
tiempos, costes teniendo en cuenta los recursos humanos materiales y financieros
disponibles. Este proceso es esencial para alcanzar el xito en un proyecto, porque unos
objetivos mal planteados conducirn al fracaso del proyecto aun cuando la gestin sea
adecuada.
En esta etapa se hace la la redaccin de la propuesta especfica objeto, objetivos, alcance,
calidad y estima riesgos del proyecto, y describe cmo l se llevara a cabo. Incluye
tambin estimaciones de costo y tiempo, y efecta la integracin de todo lo anterior con lo
que sigue, y justifica -evaluando credenciales y circunstancias- por qu el contrato del
proyecto se debe dar a una organizacin o equipo en particular, y bajo qu condiciones.
En esta etapa es bueno elaborar la prefactibilidad del proyecto enfocada en los siguientes
aspectos:

Prefactibilidad tcnica.
Prefactibilidad econmica.
Prefactibilidad legal.
Prefactibilidad ambiental.

Esta fase tiene una gran trascendencia para la buena marcha del proyecto y puede ser
esencial, por lo que debe ser especialmente cuidada. En ocasiones esta parte es
menospreciada lo cual puede llevar el proyecto al fracaso.

b. Planeacin
Para que el proyecto tenga xito, antes que todo es necesario planificar con cuidado.

Esta etapa define el alcance de lo que se quiere hacer esta planificacin debe ser conciso y
expresar de forma precisa
Se realiza la planificacin de todas las actividades necesarias para llevara a cabo el
proyecto, considerando las prioridades del proyecto, los recursos necesarios, los
tiempos esperados para ejecutar cada una de las tareas y sus funcionalidades.
La planificacin se refiere a la identificacin de actividades, hitos y entregable del proyecto,
incluso posibilidades de mitigacin de riesgos.
Existen diferentes herramientas y tcnicas para abordar la planificacin de un buen
proyecto, las cuales permiten definir los tiempos, reas de trabajo y las distintas etapas del
desarrollo del proyecto que permiten definir el curso de accin a seguir que ser tomado.
Definimos de una forma clara lo que queremos conseguir (objetivos), en que tiempo lo
haremos (cronograma) y el coste que tendr lograrlo (presupuesto).

c. Ejecucin
Se refiere a la implementacin o puesta en marcha del proyecto, consiste en poner en
prctica la planificacin llevada a cabo previamente.
Durante la ejecucin del proyecto, se debe poner nfasis en la comunicacin para tomar
decisiones lo ms rpido posible en caso de que surjan problemas.
Adems, se debern organizar regularmente reuniones para administrar el equipo del
proyecto, es decir discutir regularmente el progreso del proyecto y determinar las
prioridades siguientes.
Se realiza para coordinar los recursos que son necesarios para desarrollar los procesos
planificados.
Esta fase suele implicar contratos de estudios, de asistencia tcnica, de servicios o de
suministros.
Se monitorea el avance real del proyecto para que se pueda adaptar el proyecto a los
cambios contextuales.
Esta etapa representa el conjunto de tareas y actividades que supone la realizacin del
proyecto, es decir el proyecto del que se trate.

d. Control
El fin de las actividades de control es asegurar que los objetivos sean alcanzados en el
tiempo y calidad planificada, realizando una buena supervisin y medicin del rendimiento
de los resultados, con el objetivo de que se puedan tomar acciones correctivas, esto se
hace mediante la comparacin entre la planificacin realizada y los valores incurridos.
Las informaciones de control deben ser proporcionadas de manera oportuna y a tiempo, sin
retrasos para tomar acciones correctivas antes de que sea tarde.

Aqu debe haber un buen liderazgo y buena supervisin por parte del Gestor del proyecto,
puede imprimir reportes revisar el progreso y aplicar mejoras.
Monitorizacin del trabajo realizado analizando de cmo el proceso difiere de lo planificado
e indicando las acciones correctoras necesarias. Incluye el liderazgo, proporcionando
directrices a los recursos humanos, para que realicen su trabajo de forma efectiva y a
tiempo.

Para esto podemos usar varios mtodos de control como son:

Diagrama de Gantt.- La herramienta bsica que se utiliza para realizar la planificacin

del trabajo de un proyecto es el diagrama de Gantt. Es un diagrama de barras que
muestra el origen y el final de las diferentes unidades mnimas de trabajo y los grupos
de tareas as como las dependencias entre unidades mnimas de trabajo (pueden ser
fin-comienzo, fin-fin, comienzo-fin, comienzo-comienzo).
PERT.- La tcnica de revisin y evaluacin de programas o PERT es bsicamente un
mtodo para describir, enlazar y analizar todas y cada una de las tareas involucradas
en completar un proyecto dado, especialmente el tiempo para completar cada tarea en
funcin de talentos y recursos, e identificar el tiempo mnimo necesario para completar
el proyecto total en funcin de los talentos y recursos.
Cadena Critica.- La Gestin de Proyectos por Cadena Crtica (CCPM) es un mtodo que
se enfoca en los recursos requeridos para ejecutar las tareas del proyecto. Tiende a
mantener el uso de los recursos nivelado, pero les pide ms flexibilidad en sus horas
de trabajo y de ser capaces de cambiar rpidamente de tarea o de cadena de tarea
para no retrasar el proyecto entero.

e. Cierre
Es la culminacin del proyecto, todo proyecto tiene una existencia temporal, y finaliza
cuando se cumple con lo establecido.
Tambin es llamada fase de puesta en marcha del proyecto.
Cierre es la etapa final de un proyecto en la que ste es revisado, y se llevan a cabo las
valoraciones pertinentes sobre lo planeado y lo ejecutado, as como sus resultados, en
consideracin al logro de los objetivos planteados.
Se realizan las pruebas finales de correccin de la solucin y la verificacin.
En esta fase se deber elaborar un documento de finalizacin donde se describe cmo se
ha llevado cabo el proyecto, los problemas que se han detectado, la metodologa utilizada,
la forma de organizacin, la experiencia ganada, y lo ms importante, las conclusiones a
las que se llega una vez se ha finalizado el proyecto.

BIBLIOGRAFA

Definicin de Proyecto

http://es.scribd.com/doc/3271816/DEFINICION-DE-PROYECTO#scribd

http://todosobreproyectos.blogspot.com/2009/10/concepto-de-proyecto.html

Ciclo de vida del Software

http://aposta.uv.es/givaro/modulo/Ciclo.htm

Etapas del ciclo de vida del Software

http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060024/Lecciones/Capitulo
%20I/problemas.htm

Modelos de Ciclo de Vida

Modelo Cascada

 http://www.academia.edu/6362716/METODO_EN_CASCADA

Modelo V
http://www.iiia.csic.es/udt/es/blog/jrodriguez/2008/metodologia-desarrollo-sotware-modelo-en-vo-cuatro-niveles

Modelo en Espiral

http://spanishpmo.com/index.php/ciclos-de-vida-modelo-en-espiral/

http://www.sites.upiicsa.ipn.mx/polilibros/portal/Polilibros/P_externos/Administracion_informatic
a_de_las_organizaciones_Ramon_E_Enriquez_Gonzalez/AIO2_Mod_ESPIRAL.html

Proceso de desarrollo de software

http://www.monografias.com/trabajos5/desof/desof.shtml

Definicin de la Visin del Proyecto

http://eprints.rclis.org/6761/1/serie_7.pdf

Planificacin del alcance de un Proyecto

http://www.iue.edu.co/documents/emp/gestionAlcance.pdf
https://formulaproyectosurbanospmipe.wordpress.com/
https://www.youtube.com/watch?v=Ad-tDJEEf5s

Gestin del Tiempo del Proyecto

http://www.eoi.es/wiki/index.php/GESTI
%C3%93N_DEL_TIEMPO_EN_PROYECTOS_en_Gesti%C3%B3n_de_proyectos
http://www.ehu.eus/asignaturasKO/PM/Gestion/gespro1va.htm

Definicin de Actividades y Secuencias

 http://www.eoi.es/blogs/awildacarolinaberiguete/2012/01/31/las-actividades-de-la-gestion-deproyectos/