Estandar Internacional de Perfiles

Se definen con el objetivo de empaquitar referencias a y/o partes de otros documentos de manera formal para adaptarlos a las necesidades de las VSE. Preparar perfiles es un proceso definido de ISO/IEC JTC1, lo cual implica dos tipos de documentos:
*Marco de trabajo y taxanomia (TR29110-2). este documento establece la logia detras de la definicion y aplicacion de los perfiles (estructura, conformidad, evaluacion) e introduce la taxonomia (catalogo) de los perfiles ISO/IEC 29110. Este documento esta dirigido a autores y revisores de ISP(international standardized profiles), autores de otras  partes y de otros perfiles orientados a VSE. El marco de trabajo y la toxonomia se pueden aplicar a las perfiles identificados segun TR 29110-2
*Especificacion de perfil (TR29110-4). Por cada perfil hay un documento de especificacion de ferfil, identificado como 29110-4.X, donde la X es el numero signado al perfil. Su proposito es proporcionar la composicion definitiva de un perfil, proporcional enlaces normativos al subconjunto notmativo de estadares(por ejemplo< ISO 12207) usados en el perfil y proporcionar enlaces informativos (referencias) a documentos de ''entrada'' (por ejemplo, 90003, SWBOK, de herramientas y otro material de apoyo.
el documento 29110-4.1 "espesificacion de perfil. su propsito es definir una gia de gestion de proyectos y desarrollo  de software para un subconjunto de procesos de ISO/IEC 12207, papropiada para las  caracteristicas y necesidades de una VSE.
La principal razon para incluir la gestion de proyectos es que el corazon del negocio de la VSW es el desarrollo del software, y su exito fincanciero depende de los beneficios de proyecto.

Proceso unificado

PARTE I: EL PROCESO DE DESARROLLO DE SOFTWARE UNIFICADO. El proceso unificado: dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental. Las cuatro “P” en el desarrollo de software: personas, proyecto, producto y proceso. Un proceso dirigido por casos de uso. Un proceso centrado en la arquitectura. Un proceso iterativo e incremental. 
PARTE II:LOS FLUJOS DE TRABAJO FUNDAMENTALES. Captura de requisitos: de la visión a los requisitos. Captura de requisitos como casos de uso. Análisis. Diseño. Implementación. Prueba. 
PARTE III: DESARROLLO ITERATIVO E INCREMENTAL. El flujo de trabajo de iteración genérica. La fase de inicio pone en marcha el proyecto. La fase de elaboración construye la línea base arquitectónica. La construcción lleva a la capacidad operativa inicial. La transición completa la versión del producto. Como hacer que el proceso unificado funcione. Apéndice A: Visión general de UML. Apéndice B: Extensiones de UML específicas del Proceso Unificado. Apéndice C: Glosario general. Índice analítico.

========================================================================

1. Proceso de Desarrollo de Software: Proceso de negocio, o caso de uso de negocio, de un negocio de desarrollo de software. Conjunto total de actividades necesarias para transformar los requisitos de un cliente en un conjunto consistente de artefactos que representan un producto software y en punto posterior en el tiempo para transformar cambiso en dichos requisitos en nuevas versiones del producto.
2. Lenguaje Unificado de Modelado (UML): Lenguaje estandar para el modelado de software lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema con gran cantidad de software. Lenguaje usado por el Proceso Unificado. Lenguaje que permite a los desarrolladores visualizar el producto de su trabajo (Artefactos) en esquemas o diagramas estandarizados.
3. Proceso Unificado de Desarrollo de Software (PUDS): Proceso de desarrollo de software basado en el Lenguaje Unificado de Modelado y que es iterativo, centrado en la arquitectura y dirigido por los casos de uso y los riesgos. Proceso que se organiza en cuatro fases: inicio, elaboracion, construccion y transicion, y que se estructura en torno a cinco flujos de trabajo fundamentales: recopilacion de requisitos, analisis, diseño, implementacion y pruebas. Proceso que se describe en terminos de un modelo de negocio, el cual esta a su vez estructurado en funcion de tres bloques de construccion primordiales trabajadores, actividades y artefactos.
4. Requisitos: Flujo de trabajo fundamental cuyo proposito esencial es orientado al desarrollado hacia el sistema correcto. Esto se lleva a cabo mediante la descripcion de los requisitos del sistema de forma tal que se pueda llegar a un acuerdo entre el cliente(incluyendo los usuarios) y los desarrolladores del sistema, acerca de lo que el sistema debe hacer y lo que no.
5. Analisisis: Flujos de trabajo fundamental cuyo proposito principal es analizar los requisitos descritos en la captura de requisitos, mediante su refinamiento y estructuracion. El objetivo de esto es (1) lograr una comprension mas precisa de los requisitos, y (2) obtener una descripcion de los requisitos que sea facil de mantener y que nos ayude a dar estructura al sistema en su conjunto incluyendo su arquitectura.
6. Diseño: Flujo de trabajo fundamental cuyo proposito principal es la de formular modelos que se centran en los requisitos no funcionales y el dominio de la solucion y que prepara para la implementacion y pruebas del sistema.
7. Implementacion: Flujo de trabajo fundamental cuyo proposito esencial es implementar el sistema en terminos de componentes, es decir codigo fuente guiones, ficheros binarios, ejecutables, et.
8. Prueba: Flujo de trabajo fundamental cuyo proposito esencial es comprobar el resultado de la implementacion mediante las pruebas de cada construccion, incluyendo tanto construcciones internas como intermedias, asi como las versiones finales del sistema que van a ser entregadas a terceras personas.
9. Fase de Inicio: Primera fase del ciclo de vida del software, en la que la idea inicial para el desarrollo es refinada hasta el punto de quedar lo suficientemente bien establecida como para garantizar la entrada en la base de elaboracion.
10. Fase de Elaboracion: Segunda fase del ciclo de vida, en la que se define la arquitectura.
11. Fase de Construccion: Tercera fase del ciclo de vida del software, en la que el software es desarrollado a partir de una linea base de la arquitectura ejecutable, hasta el punto en el que se esta listo para ser transmitido a las comunidades de usuarios.
12. Fase de Transicion: Cuarta fase del ciclo de vida del software es puesto en manos de la comunidad de usuarios.
13. Arquitectura: Conjunto de desiciones significativas, acerca de la organizacion de un sistema software, la seleccion de los elementos estructurales apartir de los cuales se compone el sistema y las interfaces entre ellos, junto con su comportamiento, tal y como se especifica en las colaboraciones entre estos elementos, la composicion de estos elementos estructurales y de comportamiento de subsistemas progresivamente mayores, y el estilo arquitectonico que guia esta organizacion, estos elementos y sus interfaces, sus colaboraciones y su composicion. La arquitectura de software se interesa no solo por la estructura y el comportamiento, sino tambien por las restricciones y compromisos de uso, funcionamiento, flexibilidad al cambio, reutilizacion, comprension, economia y tecnologia, asi como aspectos esteticos.
14. Vista Arquitectonica del Modelo de Casos de Uso: Vista de la arquitectura de un sistema abarcando los casos de uso significativos desde un punto de vista arquitectonico.
15. Vista Arquitectonica del Modelo de Analisis: Vista arquitectonica de un sistema, abarcando las clases, paquetes y realizaciones de casos de uso del analisis, vista que fundamentalmente aborda el refinamiento y estructuracion de los requisitos del sistema. La estrucutra de esta vista se preserva en la medida de lo posible cuando se diseña e implementa la arquitectura del sistema.
16. Vista Arquitectonica del Modelo de Diseño: Vista de la arquitectura de un sistema, abarcando las clases , subsistemas, interfaces y realizaciones de casos de uso del diseño que forman el vocabulario del dominio de la solucion del sistema, vista que abarca tambien los hilos y procesos qeu establecen la concurrencia y mecanismos de sincronizacion del sistema, vista que aborda los requisitos no funcionales, incluyendo los requisitos de rendimiento y capacidad de crecimiento de un sistema.
17. Vista Arquitectonica del Modelo de Despliege: Vista de la arquitectura de un sistema abarcando los nodos que forman la topologia hardware sobre la que se ejecuta el sistema, vista que aborda la distribucion, entrega e instalacion de las partes que constituyen el sistema fisico.
18. Vista Arquitectonica del Modelo de Implementacion: Vista arquitectonica de un sistema, abarcando los componentes usados para el ensamblado y lanzamiento del sistema fisico, vista que aborda la gestion de la configuracion de las versiones del sistema, constituida por componentes independientes que pueden ser ensambladas de varias formas para producir un sistema ejecutable

Fuente Original:
Grady Booch, Ivar Jacobson, James Rumbaugh. El Proceso Unificado de Desarrollo de Software. Addison Wesley, 2000

La metodología OMT

La metodología OMT (Object Modeling Technique) (Técnica de modelado de objetos)fue creada por James Rumbaugh y Michael Blaha en 1991, mientras James dirigía un equipo de investigación de los laboratorios General Electric.

OMT es una de las metodologías de análisis y diseño orientadas a objetos, más maduras y eficientes que existen en la actualidad. La gran virtud que aporta esta metodología es su carácter de abierta (no propietaria), que le permite ser de dominio público y , en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolución para acoplarse a todas las necesidades actuales y futuras de la ingeniería de software.

Las fases que conforman a la metodología OMT son:

• Análisis. El analista construye un modelo del dominio del problema, mostrando sus propiedades más importantes. El modelo de análisis es una abstracción resumida y precisa de lo que debe de hacer el sistema deseado y no de la forma en que se hará. Los elementos del modelo deben ser conceptos del dominio de aplicación y no conceptos informáticos tales como estructuras de datos. Un buen modelo debe poder ser entendido y criticado por expertos en el dominio del problema que no tengan conocimientos informáticos.
• Diseño del sistema. El diseñador del sistema toma decisiones de alto nivel sobre la arquitectura del mismo. Durante esta fase el sistema se organiza en subsistemas basándose tanto en la estructura del análisis como en la arquitectura propuesta. Se selecciona una estrategia para afrontar el problema.
• Diseño de objetos. El diseñador de objetos construye un modelo de diseño basándose en el modelo de análisis, pero incorporando detalles de implementación. El diseño de objetos se centra en las estructuras de datos y algoritmos que son necesarios para implementar cada clase. OMT describe la forma en que el diseño puede ser implementado en distintos lenguajes (orientados y no orientados a objetos, bases de datos, etc.).
• Implementación. Las clases de objetos y relaciones desarrolladas durante el análisis de objetos se traducen finalmente a una implementación concreta. Durante la fase de implementación es importante tener en cuenta los principios de la ingeniería del software de forma que la correspondencia con el diseño sea directa y el sistema implementado sea flexible y extensible. No tiene sentido que utilicemos AOO y DOO de forma que potenciemos la reutilización de código y la correspondencia entre el dominio del problema y el sistema informático, si luego perdemos todas estas ventajas con una implementación de mala calidad.

La metodología OMT emplea tres clases de modelos para describir el sistema:

• Modelo de objetos. Describe la estructura estática de los objetos del sistema (identidad, relaciones con otros objetos, atributos y operaciones). El modelo de objetos proporciona el entorno esencial en el cual se pueden situar el modelo dinámico y el modelo funcional. El objetivo es capturar aquellos conceptos del mundo real que sean importantes para la aplicación. Se representa mediante diagramas de onjetos.
• Modelo dinámico. Describe los aspectos de un sistema que tratan de la temporización y secuencia de operaciones (sucesos que marcan los cambios, secuencias de sucesos, estados que definen el contexto para los sucesos) y la organización de sucesos y estados. Captura el control, aquel aspecto de un sistema que describe las secuencias de operaciones que se producen sin tener en cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en que están implementadas. Se representa gráficamente mediante diagramas de estado.
• Modelo funcional. Describe las transformaciones de valores de datos (funciones, correspondencias, restricciones y dependencias funcionales) que ocurren dentro del sistema. Captura lo que hace el sistema, independientemente de cuando se haga o de la forma en que se haga. Se representa mediante diagramas de flujo de datos

Modelo de Objetos 

Esta es la parte principal de la Técnica para modelado ya que se fundamenta en la teoría de OO. La definición clara de las entidades que intervienen en el sistema es un paso inicial necesario para poder definir qué transformaciones ocurren en ellas y cuándo se producen estas transformaciones. Esta forma de pensar es inherente al paradigma de OO donde las clases y su jerarquía determinan el sistema.

Los diagramas de objetos permiten representar gráficamente los objetos, las clases y sus relaciones mediante dos tipos de diagramas: los diagramas de clases y los diagramas de casos concretos (instancias). Los diagramas de clases describen las clases que componen el sistema y que permitirán la creación de casos concretos, los diagramas de casos concretos describen la manera en que los objetos del sistema se relacionan y los casos concretos que existen en el sistema de cada clase. En los diagramas que componen este modelo se pueden representar los siguientes elementos del sistema: objetos y clases, atributos, operaciones, y relaciones o asociaciones.

Clases y Objetos

 Los objetos y sus componentes se representan gráficamente en OMT de forma que es posible obtener una idea de los elementos que intervienen en el sistema estudiando el modelo. Los elementos y sus características con representación gráfica son los siguientes:

• Objetos. Un objeto es, sencillamente, algo que tiene sentido en el contexto de la aplicación. Se definirá un objeto como un concepto, abstracción o cosa con límites bien definidos y con significado a efectos del problema que se tenga entre manos.
• Clases. Describe un grupo de objetos con propiedades (atributos) similares, con relaciones comunes con otros y con una semántica común.
• Diagramas de objetos. Proporcionan un anotación gráfica formal para el modelado de objetos, clases y sus relaciones entre sí, son útiles, tanto para el modelado abstracto como, para diseñar programas reales. Hay dos tipos de diagramas de objetos

-Diagrama de clases. Esquema, patrón o plantilla para describir muchas instancias de datos posibles.

-Diagrama de instancias. Describe la forma en que un cierto conjunto de objetos se relacionan entre sí.

• Atributos. Los objetos pertenecientes a una clase presentan características que en OMT se denominan atributos. Sin embargo, no se deben de confundir los atributos, que son características que todos los objetos de una clase comparten, con otros objetos que pueden formar parte del objeto que estamos tratando.
• Operaciones y métodos. Del mismo modo que los objetos en OMT se pueden representar las operaciones que se realizan sobre ellos o que éstos realizan sobre otros objetos del sistema. Los objetos realizan acciones sobre otros objetos y definen acciones que se realizan sobre ellos mismos. Los objetos de una misma clase comparten estas operaciones, aunque también pueden añadir otras nuevas que no se definan en su clase a medida que se especializa el objeto en otras subclases. También pueden redefinir las operaciones en estas especializaciones ignorando las definiciones realizadas en las superclases. Las operaciones pueden llevar implícito el objeto sobre el que se realizan o que realiza la acción, de forma que es posible tener una misma operación que se efectúe de manera distinta según el objeto sobre el que se aplique. La implementación de las operaciones para cada uno de los objetos diferentes (o subclases) se denomina método. Los métodos implementan en cada una de las clases de forma específica para los objetos que representa.

Enlaces y Asociaciones

Las relaciones entre clases determinan el comportamiento del sistema y constituyen una parte muy importante del mismo ya que mediante las relaciones definimos la forma en que los objetos se comunican, lo que también se conoce como comportamiento.

Además las relaciones tienen una serie de características que son de interés para el modelado del sistema.

• Relaciones. En OMT se identifican a través de enlaces: conexiones físicas o conceptuales entre casos concretos de objetos. Una asociación en OMT abstrae un conjunto de enlaces con una estructura y un significado comunes. Desde el punto de vista de la implementación, una asociación es un puntero que apunta desde un objeto a otro.
• Multiplicidad. Este término se encuentra relacionado con las asociaciones e indica el número de casos concretos de una clase que puede relacionarse con otro caso concreto. Las relaciones más frecuentes son las binarias, aunque pueden darse de cualquier orden.

Conceptos Avanzados de Enlaces y Asociaciones

• Atributos de los enlaces. Los enlaces así como los objetos pueden tener atributos, que son propiedades de los enlaces de una asociación.
• Modelado de una asociación en forma de clase. A veces resulta conveniente modelar las asociaciones como clases en lugar de cómo relaciones, cuando los enlaces pueden participar en asociaciones con otros objetos o están sometidos a operaciones.
• Clasificación. También podemos encontrar en una asociación de objetos que pertenecen a una clase con multiplicidad "muchos" que deben estar ordenados. Esta característica de los objetos es una restricción, ya que implica una condición que deben cumplir los elementos de la clase.
• Nombre de rol. Las asociaciones conectan clases u objetos que pertenecen a dichas clases, pero en ocasiones necesitamos restringir el conjunto de los objetos que se relacionan dentro de la clase. Mediante estas restricciones podemos especificar qué objetos se relacionan. Podemos conseguir este objetivo mediante los llamados nombres de rol. Un nombre de rol es un atributo derivado de una clase cuyo valor es un conjunto de objetos relacionados. Los nombres de rol se utilizan cuando las asociaciones se producen entre objetos de la misma clase ya que suelen producirse entre subconjuntos de esas clases. Una asociación binaria puede tener dos roles, uno por cada extremo de la asociación que son identificados por sus nombres.
• Cualificación. Las asociaciones muchos a muchos y uno a muchos pueden ser calificadas mediante un elemento calificador que reduce el conjunto de objetos relacionados, indicando un subconjunto de la clase que se califica en la asociación. Las asociaciones que se pueden calificar son las de multiplicidad uno a muchos y muchos a muchos.
• Agregación. Las relaciones de agregación son para OMT formas de asociación del tipo "es parte de", como tales se definen entre una clase agregado y una clase componente y se indican con un rombo en la parte de la clase que actúa como continente. Las relaciones de agregación se establecen en los llamados objetos compuestos que contienen otros objetos y éstos pueden ser de dos tipos: aquellos que tienen existencia física más allá del objeto agregado, y los que no pueden existir sin el objeto agregado.

 Generalización y Herencia

En el paradigma de la orientación a objetos uno de los elementos más importantes es la herencia. La cualidad que permite que los objetos hereden las características (atributos) y las operaciones (métodos) dentro de una estructura jerárquica conlleva una serie de consecuencias de máxima relevancia a la hora de diseñar un sistema informático. Los objetos heredan un comportamiento que puede ser modificado y unas estructuras de datos de forma que se permite y se facilita la reutilización de las clases y del código que implementa sus funcionalidades.

Ambos conceptos van unidos: herencia y estructura jerárquica, de forma que la herencia se produce por la existencia de una estructura entre los componentes del sistema y la estructura se consigue en la implementación del código a través de la herencia en los lenguajes OO.

La herencia está íntimamente relacionada con la forma concreta en que un lenguaje implementa la generalización, que es un término más abstracto.

• La generalización es la relación que existe entre una clase y las subclases que se derivan de la misma. A partir de una versión "en bruto" se generan versiones más especializadas de la misma que añaden características y operaciones. La superclase es la versión general y las subclases son especializaciones de la superclase. Las generalizaciones pueden tener discriminadores que indican qué aspecto de la superclase está siendo utilizado para obtener subclases más concretas.
• Anulación. Al implementar la herencia nos encontramos en numerosas ocasiones que las subclases redefinen operaciones que ya han sido definidas en las superclases. Las razones para esta nueva implementación de operaciones que existen en las superclases son variadas, a veces simplemente se le añaden nuevas acciones que van en consonancia con las nuevas características que añade la subclase; otras, se consigue optimizar las operaciones debido a que las subclases tienen características nuevas que lo permiten, y a veces se produce por una mala práctica de análisis donde no se prevén las operaciones de manera óptima.

Se han propuesto una serie de reglas a la hora de implementar la herencia para minimizar los errores y maximizar la reutilización de código:

2. Las operaciones de consulta, aquellas que no modifican valores de atributos, se heredan por todas las subclases.
3. Las operaciones de actualización, que modifican valores de atributos, se heredan por todas las subclases y se añaden las nuevas operaciones para aquellas que añadan atributos.
4. Las operaciones de actualización que se realizan sobre atributos que tengan algún tipo de restricción o asociación, se bloquean para nuevas subclases.
5. Las operaciones no pueden volver a definirse para hacer que se comporten de distinta manera de cara al exterior, es decir; todos los métodos concretos de una operación deben tener el mismo protocolo.
6. Las operaciones se pueden refinar añadiendo comportamientos en las subclases.

Agrupación de entidades 

Los elementos que hemos estudiado en el Modelo de Objetos se pueden agrupar para construir el modelo completo, así, las clases, las asociaciones y las generalizaciones forman lo que se denomina módulo y varios módulos forman el modelo de objetos. En un módulo no se deben repetir los nombres de las clases y de las asociaciones, aunque se puede hacer referencia a la misma clase dentro de distintos módulos. También se definen las denominadas hojas que se utilizan para descompones un Modelo de Objetos en unidades que podemos manejar. Una hoja es una parte de un módulo que podemos manejar con facilidad, sea en el formato que sea. 

 Modelo Avanzado de Datos

• Clases abstractas. En ocasiones puede ser de utilidad tener clases que definan propiedades y operaciones de forma general, dejando para sucesivos refinamientos la implementación concreta de las mismas. Una clase abstracta es precisamente una clase donde se introducen métodos y datos que se definirán en las subclases de la misma. Las clases abstractas siempre tienen que tener clases  derivadas donde se especificarán las operaciones que no se hayan definido en la clase abstracta, nunca podrán tener objetos, se utilizan como clases bases o superclases de otras clases. La existencia de este tipo de clases facilita aún más la posibilidad de abstracción del modelo, dejando para posteriores refinamientos del problema la definición más exhaustiva de operaciones y datos. La implementación concreta de las clases abstractas depende del lenguaje OO. En OMT una clase abstracta se identifica cuando no tiene casos concretos (instancias) pero una subclase suya sí los tiene. Por ejemplo, una clase abstracta números podría definir una operación multiplicar que no se implementara hasta la definición de las subclases números enteros, números reales y números complejos, teniendo la información precisa en cada una de las subclases de la forma en que se multiplican los números.
• Herencia múltiple. La herencia múltiple es una característica que algunos sistemas OO poseen, mediante la cual es posible que una clase herede de varias superclases al mismo tiempo. Sin embargo, la herencia múltiple aumenta radicalmente la complejidad de los sistemas que la implementan ya que la búsqueda de las operaciones se dificulta cuando no se define en la clase derivada y hay que realizarla en las superclases.
• Clave candidata. No es más que un conjunto mínimo de atributos que define de forma única un objeto o enlace. Es decir, mediante una clave candidata tenemos definido el objeto o el enlace con una serie de atributos de forma que se distingue del resto de objetos o enlaces. Las claves candidatas son restricciones y, por tanto, se representan como tales en OMT. Para encontrar una clave candidata en una asociación donde intervienen más de dos clases, debemos definir qué combinaciones de clases o enlaces en la asociación de los elementos definen la tercera clase o enlace de forma única.
• Restricciones. El modelo de objetos contiene diferentes entidades como son los objetos, las clases, los atributos, los enlaces y las asociaciones. Cada una de estas entidades tiene una serie de características inherentes a su naturaleza dentro del sistema que estamos modelando. Las características definen su significado dentro del sistema y también sus limitaciones. Estas limitaciones se denominan en el Análisis restricciones. Las restricciones pueden ser muy complejas y en este caso no pueden estudiarse en el modelo de objetos, sino que se especificarán en el modelo funcional. Las que  intervienen en el modelo de objetos se representan mediante llaves junto a la entidad a que se refieran. Cuando la restricción implica más de una clase, se indica mediante una flecha discontinua que une los elementos que se vean implicados en la restricción. Las asociaciones también pueden tener restricciones.

Construcción de un modelo de objetos

• Identificar las clases de objetos.
• Iniciar un diccionario de datos que contenga descripciones de clases, atributos y asociaciones.
• Agregar asociaciones entre clases.
• Agregar atributos a objetos y ligas.
• Organizar y simplificar las clases de objetos usando herencia.
• Probar las rutas de acceso usando escenarios e iterar los pasos anteriores según sea necesario.
• Agrupar las clases en módulos, basándose en "acoplamiento cercano" y función relacionada.

Notaciones del modelo de objetos

 Notaciones del modelo avanzado de objetos

SIS2 PERT - CPM

PERT - CPM

La problemática de la planeación de proyectos no ha sido una problemática reciente, si no que desde tiempos pasados nuestros antepasados han enfrentado emprendimientos de gran envergadura que significaron una problemática desde el punto de la planificación.

Actualmente se han logrado perfeccionar herramientas que permiten a los administradores de dichos proyectos, realizar una labor más eficiente permitiendo una óptima aplicación de los recursos en las mismas y logrando una maximización de los mismos.

Admitiendo que la ejecución de un proyecto o elaboración se puede subdividir en planear, programar y controlar, y hablando de manera clásica, podemos considerar las técnicasPERT(Program Evaluation aand review Technique) y el CPM (Critical Path Method,) que son los mas usuales para un primer cometido. En general estas técnicas resultan útiles para una gran variedad de proyectos que contemplen:

·         Investigación y desarrollo de nuevos productos y procesos.

·         Construcción de plantas, edificios, y carreteras.

·         Diseño de equipo grande y complejo.

·         Diseño e instalación de sistemas nuevos.

·         Diseño y control de epidemias,

·         y otras múltiples aplicaciones en las cuales se requiera una planificación adecuada.

En los proyectos como estos, los administradores deben programas, coordinar las diversas tareas o actividades a desarrollar un proyecto, las cuales no necesariamente son secuenciales, y aun en este caso estas actividades son interdependientes. Si bien es cierto que, algunas actividades en paralelo que originan una tercera.

Las preguntas esenciales de la elaboración de un proyecto comprenden:

·         Cuál es el tiempo que se requiere para terminar el proyecto.

·         Cuáles son las fechas programadas de inicio y finalización del proyecto.

·         Que actividades son críticas y deben terminarse exactamente según lo programado parapoder mantener el proyecto según el cronograma.

·         Cuales actividades pueden ser demoradas sin afectar el tiempo de terminación del proyecto.