Integrantes:Ocampo Pierre KarinaRamírez Díaz Juan ManuelRosete Osorio Marcos Adrián

Una declaración objetiva es más que una simple frase que deben cumplir los siguientes cinco criterios:• Se afirma en lo positivo. • Es medible. • Es posible. • Es pertinente. • Es oportuna.

Estos criterios forman el acrónimo "SMART" en inglés.

Ahora vamos a examinar nuestro ejemplo para ver si cumple los criterios.

Se afirma en lo positivoEs medible. No es seguro si es factible, pero tenemos la información para evaluar eso. Es pertinente. Es oportuna.

Es decir, es un objetivo SMART.

Lo primero que un director de proyecto debe hacer es definir el objetivo del proyecto, el objetivo puede ser cualquier cosa pero que sea clara y concreta.

"Alcance" se limita a una única declaración de lo que el proyecto hará.

Cuanto más tiempo invierten en aclarar el alcance, es menor el número de problemas que puede esperar en el desarrollo del proyecto, es decir, si no desea imprevisto y perdidas innecesarias de tiempo dedique el esfuerzo necesario a dejar bien definido el alcance.

Por ejemplo, los puntos que un alcance puede tomar en cuanta serian:

Qué tipos de productos pueden ordenar los clientes

Si el sistema permitirá disponer de plazos de entrega

Si va a permitir a los clientes a cambiar sus perfiles

Si va a permitir revisar su estado de crédito

Si permitirá modificar los pedidos una vez colocado.

Existen dos tipos de alcance: • Alcance del producto: Llegar a un acuerdo

común de sus principales límites y las funciones de la empresa que abarca. Por ejemplo, un sistema de control de inventario

• Alcance del proyecto: Se refiere a la forma en que el proyecto es preparado y presentado. Por ejemplo, la presentación de los campos “especificaciones del programa”

En algunos proyectos, el alcance es indeterminado, porque el alcance es nuevo o porque el cliente totalmente no ha clarificado el objetivo del proyecto.

Cuando esto sucede usted puede proponer un alcance de proyecto y presentarlo ante el cliente para llegar a un acuerdo.

No importa que tan bien se declare el alcance este puede cambiar, para ellos se necesitan mecanismos que lo controlen.

Uno de estos puede ser, acordar con el cliente que si ocurre un cambio, usted analizara el impacto en costo y en el programa y el cliente solo aprobara o rechazará el cambio.

• El proceso de revisar y aprobar es el lugar donde el proyecto, la sociología y las políticas se plantean. Si no se administran apropiadamente los procesos, puede causar que el esfuerzo sea el doble o el triple de lo estimado.

• Es crucial definir, al inicio del proyecto, el procedimiento por el cual los entregables serán aceptados.

• Es mejor si la revisión y la aprobación se lleva a cabo frente a frente.

• Las excepciones requieren iteraciones más largas.

Los únicos comentarios aceptables son aquellos que Corrigen, Completan o Clarifican el entregable.

La más polémica de las tres Cs es la claridad.

Los revisores deben limitarse solo a una serie de comentarios. Si el documento revisado debe ser presentado para un segundo ciclo de revisión, los comentarios deben limitarse a la parte del documento que ha cambiado. Los nuevos comentarios sobre el material previamente revisado no deberían permitirse, o el proceso nunca acabará.

El mejor enfoque es conducir una junta frente a frente. Los revisores podrán colocar sus comentarios en un contexto que el autor entenderá mejor, y la mayoría de los revisores limitaran sus reacciones.

Una junta permite acuerdos generales en las revisiones, así habrá un menor seguimiento de los comentarios.

Los revisores deben ser las mismas personas que participan en la preparación del documento.

Los clientes se niegan a aceptar un proceso limitado de revisión y aprobación. • Determinar por qué tu cliente rechaza un

proceso formal y como el cliente puede hacer frente a los entregables que tú presentes.

• El cliente ignora el proceso de revisión y aprobación e insiste en revisiones adicionales.

• Advierta que las estimaciones estaban basadas en un acuerdo sobre el procedimiento de revisión y aprobación y que si este procedimiento es cambiado, las estimaciones también cambiarán.

El uso de cualquier enfoque de ciclo de vida de desarrollo de sistemas (SDLC) es independiente de la administración.

Un SDLC describe un conjunto de procesos para mover un sistema de su concepto inicial hasta su implementación.

Este es el abuelo de las SDLCs. Fue el primer enfoque formal y, hasta hoy, es ampliamente usado en el desarrollo de aplicaciones.

El ciclo de vida en cascada define una serie de pasos, cada uno de los cuales debe ser completado antes de iniciar el siguiente paso. Los pasos son normalmente definición, diseño, desarrollo e implementación.

Algunas criticas: Monolítico e Inflexible.

Está basado en la idea que a través de una serie de fases, cada una de las cuales agregan alguna funcionalidad y permiten al cliente refinar los requerimientos, un equipo puede entregar un producto final.

El peligro con el desarrollo iterativo es que es visto como una serie de actividades que, a través de pruebas y errores, finalmente logran un producto terminado.

Necesita tres características: un objetivo global de proyecto, una visión general de iteración y un plan de iteración.

El ciclo de vida en espiral es una clase de SDLC iterativa, que pasa a través de cuatro grandes pasos muchas veces antes de que se produzca el resultado final.

Determinar los objetivos, alternativas y limitaciones. Identificar y resolver los riesgos. Desarrollar los entregables y verificarlos. Planear la siguiente iteración.

Cada iteración sigue el ciclo de vida en cascada, determinar los objetivos (definición), resolución de riesgos (diseño), desarrollo (desarrollo) y planeación de la siguiente iteración (implementación).

RAD se planteó a raíz de la percepción de que el ciclo de vida en cascada es demasiado inflexible, largo y rígido para satisfacer el rápido ritmo de las necesidades de las empresas modernas.

RAD hace hincapié en la participación de los usuarios finales.

RAD es también un proceso iterativo, en el cual cada iteración produce un prototipo, el conjunto de estos refina los requerimientos, y por ultimo produce un producto valioso y valido.

Hace hincapié en un ritmo más rápido y un equipo pequeño de colaboración, para la construcción de sistemas.

También se hace hincapié en las pruebas, planes de prueba que se crean en el inicio del desarrollo, en lugar de al final, justo antes de su ejecución.

Como director de proyecto de un proyecto de programación extrema, se tiene que aprender el vocabulario del ciclo de vida y los procesos particulares que incluye, pero también tendrá que asegurarse de que el equipo sigue las medidas convencionales del ciclo de vida en cascada.