Sie sind auf Seite 1von 55
PARTIDA ACTIVIDADES NO PLANIFICADAS QUE CASUALMENTE LLEGAN A DESTINO A MUY ALTO COSTO LLEGADA PLANIFICACION Y
PARTIDA
PARTIDA
PARTIDA ACTIVIDADES NO PLANIFICADAS QUE CASUALMENTE LLEGAN A DESTINO A MUY ALTO COSTO LLEGADA PLANIFICACION Y

ACTIVIDADES NO PLANIFICADAS QUE CASUALMENTE LLEGAN A DESTINO A MUY ALTO COSTO

PARTIDA ACTIVIDADES NO PLANIFICADAS QUE CASUALMENTE LLEGAN A DESTINO A MUY ALTO COSTO LLEGADA PLANIFICACION Y
LLEGADA
LLEGADA
PLANIFICACION Y CONTROL DE ACTIVIDADES
PLANIFICACION Y CONTROL DE
ACTIVIDADES

ACTIVIDADES NO PLANI-

FICADAS QUE NO LLEVAN A NINGUN LUGAR

El desarrollo de Sistemas de Información es una actividad estrechamente relacio- nada con las personas de
El desarrollo de Sistemas de Información es una actividad estrechamente relacio- nada con las personas de

El desarrollo de Sistemas de Información es una actividad estrechamente relacio-

nada con las personas de la Empresa.

Por cada grupo de personas obtenemos:

  • Actitud Positiva/Negativa en la cola- boración con el equipo de Desarrollo

  • Perspectivas diferentes de la aprecia- ción del problema

  • Sugerencias, soluciones según la con- veniencia de cada grupo.

  • Falta de capacitación profesional en el Grupo de Desarrollo.

  • Etc.

Usuarios Finales Empleados

El desarrollo de Sistemas de Información es una actividad estrechamente relacio- nada con las personas de
El desarrollo de Sistemas de Información es una actividad estrechamente relacio- nada con las personas de

Comité Directivo, Jefes

El desarrollo de Sistemas de Información es una actividad estrechamente relacio- nada con las personas de
El desarrollo de Sistemas de Información es una actividad estrechamente relacio- nada con las personas de

Jefe de Proyecto

El desarrollo de Sistemas de Información es una actividad estrechamente relacio- nada con las personas de
El desarrollo de Sistemas de Información es una actividad estrechamente relacio- nada con las personas de

Equipo de

Desarrolladores

 La Perspectiva del Usuario Final.  ¿Qué sistema? Yo no he visto un nuevo sistema
  • La Perspectiva del Usuario Final.

 La Perspectiva del Usuario Final.  ¿Qué sistema? Yo no he visto un nuevo sistema
  • ¿Qué sistema? Yo no he visto un nuevo sistema

  • Es muy bonito pero, ¿hace algo que sea de utilidad?

  • !Puede funcionar, pero su empleo resulta espantoso!

  • La Perspectiva del Cliente

 La Perspectiva del Usuario Final.  ¿Qué sistema? Yo no he visto un nuevo sistema
  • ¡Si hubiera sabido el precio real nunca hubiese llegado a un acuerdo!

  • ¡De que sirve que lo entregue hoy si lo necesitábamos el mes pasado!

  • De acuerdo funciona, pero su instalación ha sido tan difícil que mi personal técnico nunca confiará en el nuevo programa

  • No lo quise desde un principio

  • Todo ha cambiado ahora. Necesitamos un sistema completamente distinto

  • La Perspectiva del Diseñador

 La Perspectiva del Usuario Final.  ¿Qué sistema? Yo no he visto un nuevo sistema
  • Hemos construido lo que dijeron que querían ...

  • No tuvimos el tiempo necesario para hacerlo mejor

  • No me culpes nunca antes he realizado un análisis orientado a objetos

  • ¿Cómo puedo resolverlo? No se como se supone que debe funcionar

  • !Dijimos que eso era imposible, pero nadie nos escucho!

  • El sistema esta bien, el problema son los Usuarios

 La Perspectiva del Usuario Final. ¿Qué sistema? Yo no he visto un nuevo sistema Cuando
  • La Perspectiva del Usuario Final.

 La Perspectiva del Usuario Final. ¿Qué sistema? Yo no he visto un nuevo sistema Cuando

¿Qué sistema? Yo no he visto un nuevo sistema

Cuando un proyecto no se culmina en los tiempos

establecidos o se anula, los afectados son los usuarios

finales que ven truncos los beneficios que esperaban.

Es muy bonito pero, ¿hace algo que sea de utilidad?

Un sistema que no tiene en cuenta las sugerencias de mejora de sus usuarios finales

tiende a entorpecer su trabajo, y por lo general el sistema no es aceptado. Los peores casos ocurren cuando del sistema creado depende la vida de usuarios.

!Puede funcionar, pero su empleo resulta espantoso!

Uso desagradable de sistemas que no cumplen criterios mínimos de calidad:

  • Pobre diseño de interfaz

  • Es difícil de usar por los procesos engorrosos que hay que hacer

  • Secuencias inapropiadas/ilogicas de entrada de datos

  • Un sistema de ayuda inexistente/ineficaz, mensajes de error incomprensibles

  • Tiempos de respuesta pobres y poca confiabilidad en su funcionamiento.

 La Perspectiva del Cliente. Generalmente el Cliente (Comité Directivo, dueños, Jefes) tiene una participación tangencial
  • La Perspectiva del Cliente.

 La Perspectiva del Cliente. Generalmente el Cliente (Comité Directivo, dueños, Jefes) tiene una participación tangencial

Generalmente el Cliente (Comité Directivo, dueños, Jefes) tiene una

participación tangencial respecto a los procedimientos y detalles de los procesos, les interesa los resultados finales y solo aquellos que directamente les ayuda a tomar decisiones. Son pocos los Clientes que se involucran directamente en los procesos y son a su vez Usuarios, a menos de que la empresa sea de menor envergadura y amerita de que el cliente sea el usuario final del sistema.

¡Si hubiera sabido el precio real nunca hubiese llegado a un acuerdo!

Cuando un proyecto no se culmina en los tiempos establecidos encarece su costo de desarrollo, por lo que resulta a veces que los costos de terminación superan a los beneficios proyectados.

Es necesario planificar adecuadamente los plazos de entrega y tomar un control sobre los costos incurridos. Si se preveé que los costos que se incurrirán en el sistema no justifican los beneficios esperados, es mejor replantear los costos o en su defecto desestimar el proyecto.

 La Perspectiva del Cliente. ¡De que sirve que lo entregue hoy si lo necesitábamos el
  • La Perspectiva del Cliente.

 La Perspectiva del Cliente. ¡De que sirve que lo entregue hoy si lo necesitábamos el

¡De que sirve que lo entregue hoy si lo necesitábamos el mes pasado!

Un sistema que no se entregue a tiempo puede amenazar la exis- tencia jurídica de una empresa, es por ello que los equipos de

proyectos de desarrollo de sistemas se consideran como engra-

najes en las actividades de cualquier empresa, no entregar un producto a tiempo retrasa actividades en la empresa, puede ge- nerar perdidas y hasta sacarla del medio competitivo empresarial.

De acuerdo funciona, pero su instalación ha sido tan difícil que mi personal técnico nunca confiará en el nuevo programa

Cuando se instalan sistemas mal concebidos la imagen y confianza que se depositaba en el

sistema y en el equipo de desarrollo desaparece. Por ejemplo un equipo de desarrolladores instaló un servidor de datos en red para que los usuarios de toda la empresa deje de usar sus discos locales y compartan información en esta unidad, la intensión era buena, compartir información y evitar costos en el uso de Cds,

Usb. El sistema llego a instalarse pero al cabo de 6 semanas colapsa y se pierde

irreversiblemente la información almacenada, a pesar de ser superado y corregido el problema, el servidor de datos dejo de ser usado por la mayoría, pues los usuarios regresaron a la actividad de sus copias personales.

 La Perspectiva del Cliente. No lo quise desde un principio Las relaciones en la empresa
  • La Perspectiva del Cliente.

 La Perspectiva del Cliente. No lo quise desde un principio Las relaciones en la empresa

No lo quise desde un principio

Las relaciones en la empresa entre sus componentes: Comité

Directivo, Jefaturas, Usuarios finales, pueden ser complejas y

hasta contraproducentes, a tal punto de rechazar la implementación parcial o total de un sistema. Es necesario en estos casos concertar reuniones con los involucrados a fin de planificar predisposiciones, acuerdos y respecto a las actividades del proyecto.

Todo ha cambiado ahora. Necesitamos un sistema completamente distinto

Un proyecto que se planifica por tiempos largos (más de un año) debe tener en consideración que el sistema en su concepción de necesidades al cabo de un año puede cambiar de requisitos, lo que invalidaría el esfuerzo de nuestro equipo técnico. A medida de que el usuario/cliente conoce mas de las bondades del tener un sistema

informático, crece la tendencia a pedir mas del sistema en desarrollo

También los sucesos externos pueden tener un impacto drástico en la concepcion de los requerimientos/procesos iniciales del Sistema.

 La Perspectiva del Diseñador Hemos construido lo que dijeron que querían ... Es necesario dejar
  • La Perspectiva del Diseñador

 La Perspectiva del Diseñador Hemos construido lo que dijeron que querían ... Es necesario dejar

Hemos construido lo que dijeron que querían ...

Es necesario dejar Actas de Conformidad

respecto

a

los

requerimientos de los usuarios antes de pasar a cualquier otra

etapa del proyecto, porque una vez finalizado, estas Actas nos

sirven

de respaldo para

verificar que se

requerimientos solicitados.

ha

cumplido

con

los

Puede que los usuarios reclamen al presentárseles el producto final y es porque no se les ha dado a conocer que no pueden cambiar de opinión después de un tiempo porque va en contra de los objetivos de la empresa planteados en su debida oportunidad, y que ejecutar sus nuevas necesidades es asumir nuevamente otro ciclo de desarrollo, es por ello que se debe establecer lo mas claramente posible los requerimientos antes de iniciar el proceso de diseño y desarrollo.

 La Perspectiva del Diseñador No tuvimos el tiempo necesario para hacerlo mejor El presupuesto asignado
  • La Perspectiva del Diseñador

 La Perspectiva del Diseñador No tuvimos el tiempo necesario para hacerlo mejor El presupuesto asignado

No tuvimos el tiempo necesario para hacerlo mejor

El presupuesto asignado a un proyecto de trabajo siempre

determina el tiempo general del proyecto y los plazos de entrega en cada etapa del proyecto, los cuales deben ser respetados.

Si bien es cierto que es angustiosa la presión por culminar bien cada etapa del proyecto,

es peor si sesgamos tiempo del análisis para empezar a diseñar construir cualquier cosa con tal de satisfacer al usuario/cliente, esto por lo general tira por los suelos las actividades programadas y el producto final, porque se esta entregando un sistema que adolece de requisitos que no se tuvieron en cuenta, procesos que no están debidamente consistenciados, en general un mal producto que no satisface las las necesidades para las que fue planificado.

 La Perspectiva del Diseñador No me culpes nunca antes he realizado un análisis orientado a
  • La Perspectiva del Diseñador

 La Perspectiva del Diseñador No me culpes nunca antes he realizado un análisis orientado a

No me culpes nunca antes he realizado un análisis orientado a objetos

El equipo de proyecto debe contener personal homogéneo

en habilidades a fin de conversar un mismo idioma y desarrollar los trabajos sin retrasos o incompatibilidades.

  • Nuestros analistas de sistemas deben dominar una metodología en común, por ejemplo Orientado a Objetos, mal haríamos en considerar análisis parciales unos orientados a objetos y otros en un análisis estructurado porque tendría dificultades insalvables en la integración de las bases diseñadas.

  • Nuestros programadores deben trabajar en un lenguaje de programación común o por lo menos compatibles, de preferencia todos en java o C++

  • Nuestro equipo de especialistas en redes igualmente deben conocer a detalle la metodología a usar a fin de coordinar la implementación física de las líneas en las que circulara nuestro sistema, soporte técnico y mantenimiento de los equipos.

 La Perspectiva del Diseñador ¿Cómo puedo resolverlo? No se como se supone que debe funcionar
  • La Perspectiva del Diseñador

 La Perspectiva del Diseñador ¿Cómo puedo resolverlo? No se como se supone que debe funcionar

¿Cómo puedo resolverlo? No se como se supone que debe funcionar

Esto sucede cuando a nuestros programadores se les solicita

mejorar o modificar un sistema anterior en el cual no ha tenido participación. Lo principal aquí es solicitar los manuales de diseño, programación y los documentos relacionados a dicho sistema. No debemos caer en este error documentando adecuadamente todos nuestros procesos en cada una de las etapas de desarrollo del proyecto

!Dijimos que eso era imposible, pero nadie nos escucho!

Es necesaria la confianza entre el equipo de desarrollo y el Jefe del Proyecto a fin de poder

sincerar sus habilidades, muchas veces son muy exigentes las metas propuestas por el cliente y al ser tratadas con el equipo de desarrollo, el jefe de proyecto se compromete a realizar las metas exigentes en el tiempo solicitado, pero no sabe si su equipo tendrá los conocimientos y habilidades necesarias para cubrir las expectativas solicitadas. Pueda que no esten debidamente capacitados para las exigencias del software solicitado, o sientan que el tiempo es demasiado poco para alcanzar a entregar un producto de calidad.

 La Perspectiva del Diseñador El sistema esta bien, el problema son los Usuarios Sres. antes
  • La Perspectiva del Diseñador

 La Perspectiva del Diseñador El sistema esta bien, el problema son los Usuarios Sres. antes

El sistema esta bien, el problema son los Usuarios

Sres. antes de formar juicios de esta índole, es necesario hacer

una investigación del porque el sistema no esta siendo usado por los usuarios en forma adecuada, las situaciones mas probables son:

  • No se ha capacitado al usuario final en el uso del sistema, es subsanable.

  • No se ha hecho un correcto análisis de los requerimientos. Esto ultimo es un indicativo de que el producto no es lo esperado por el usuario y/o cliente y que no se ha hecho un adecuado desarrollo en el equipo de trabajo, esto es critico.

Flynn (1998) Clasificación de fallas en un proyecto Tipo de Motivo del Fallo Comentarios fallo Problemas

Flynn (1998) Clasificación de fallas en un proyecto

Tipo de

Motivo del Fallo

Comentarios

fallo

Problemas

Se aborda el problema inadecuado

Conflictos del sistema con la estrategia

de Calidad

empresarial

Se ignoran las influencias más amplias

Se puede ignorar la cultura empresarial

El análisis, diseño o implementación se

El equipo carece de los conocimientos

realiza incorrectamente

necesarios o de los recursos apropiados

Se emprende un proyecto por un motivo equivocado

Empuje tecnológico o tirón empresarial

Problemas

Los usuarios cambian de idea

 

de

   

productivid

Sucesos externos cambian el entorno

Nueva legislación

ad

La implementación no es factible

Puede que no se haya conocido hasta que el proyecto haya comenzado

Control pobre del proyecto

Gestor del proyecto inexperto

 Problemas de Calidad Un sistema es de calidad por lo general cuando cumple dos objetivos

Problemas de Calidad

Un sistema es de calidad por lo general cuando cumple dos objetivos primordiales:

Cumple con el propósito para el cual fue diseñado.

Si al medir sus resultados estos son los esperados.

El problema equivocado

Pueda que el Cliente no tenga bien definido las metas que desea alcanzar e incluso que no tenga planificado estrategia alguna como empresa, entonces allí estamos ante un

problema, es necesario concertar con nuestro cliente y definir claramente cuales son sus metas empresariales a fin de acoplar a ellas las metas del proyecto. En caso de que equipo de desarrollo no tenga una buena comunicación con el cliente podría caer el problema de desarrollar un excelente sistema que no satisface las metas u objetivos de la empresa, el error genera perdida de tiempo y recursos ante lo cual debería corregirse desde un principio.

Se ignora el contexto Sres. Los prejuicios de formar en nuestra mente la idea de «yo

Se ignora el contexto

Sres. Los prejuicios de formar en nuestra mente la idea de «yo se como hacerlo» sin

hacer las consultas tanto a USUARIOS como ha CLIENTES hay que desterrarlas, este tipo de pensamiento genera que tengamos sistemas con procedimientos engorrosos y que hicieron oídos sordos a las sugerencias de los involucrados. Es necesario oír a ambas partes en la etapa de requerimiento y análisis, puesto que podemos encontrar puntos de

vistas antagónicos en el desarrollo de las actividades de la empresa de ambas partes, y

las cuales debemos exponer, aclarar y determinar con los involucrados a fin de tener claro que es lo que se va a desarrollar.

Análisis, Diseño e Implementación incorrecto de los requisitos

Debemos poner énfasis en los requerimientos solicitados por los tres grupos involucrados. Por Ejemplo El Cliente podría estar inconforme con los objetivos propuestos por el

equipo de desarrollo si no se han conciliado las necesidades empresariales por lo que es contratado el equipo. Los Usuarios finales podrían estar inconformes con el funcionamiento del diseño de las interfaces. Los desarrolladores podrían estar

inconformes con las herramientas

atendidos.

disponibles

y

sus

solicitudes

de

recursos

mal

Se emprende el proyecto por un motivo equivocado Sres. hacemos énfasis en los objetivos por los

Se emprende el proyecto por un motivo equivocado

Sres. hacemos énfasis en los objetivos por los que debe ser creado un sistema y

que debe estar acorde a las estrategias empresariales. No es posible que la moda se imponga al raciocinio y se desarrolle sistemas que a la larga solo

generan gastos o el fracasos de la empresa. Por ejemplo se tiene el caso de Internet, todas la empresas creen que hacer negocios en internet (e-comerce)

es ser competitivo y estar al día con las tecnologías, muchas empresas que

empezaron vendiendo productos en internet, cerraron; el motivo fue que realmente no analizaron las ventajas y desventajas de usar internet aplicado a la

naturaleza de su empresa. Siempre es necesario sustentar bien las bases en las que se desarrollará el proyecto, beneficios y costos proyectados ante el cliente a

fin de no cometer errores.

 Problemas de Productividad Los requisitos cambian El cambio de requisittos en un proyecto pueden retrasar

Problemas de Productividad

Los requisitos cambian

El cambio de requisittos en un proyecto pueden retrasar las actividades de la misma y

hacer sentir la sombra del fracaso, es más cuando mas demore el proyecto mas cambios solicitara el cliente, cosa que podría atascar el proceso y degenerar en un aborto del proyecto. Los cambios siempre se darán pero es preferible minimizar los mismos vía acuerdos con el cliente y usuarios, luego de hacer un exhaustivo análisis de requerimientos.

Sucesos externos

Todo proyecto siempre se vera amenazado por sucesos externos sobre los cuales no podemos tener control, es necesario que se haga un análisis del entorno y de los sucesos

que podrían afectar el funcionamiento del sistema a fin de minimizar riesgos.

 Problemas de Productividad Gestión Inadecuada del proyecto El Director/Jefe del proyecto es el responsable del

Problemas de Productividad

Gestión Inadecuada del proyecto

El Director/Jefe del proyecto es el responsable del éxito del sistema, el fracaso siempre

se debe a una mala planificación y uso de los recursos asignados.

Implementación no factible

A veces proyectos muy ambiciosos resultan inoperables, por ejemplo el querer unir diversos sistemas o bases de datos requiere de hacer “parches” implementaciones que solucionan temporalmente los problemas, hasta que los requerimientos hacia el sistema crece y con ello los “parches” que cada vez se hacen imposibles de solucionar, a la larga la unión de estos sistemas resulta incompatibles y se tiende a iniciar con uno nuevo que involucre a todos los sistemas relacionados.

 Costos asociados a los fallos Aspecto del Diseño Ejemplo Efectos Inmediatos Otras consecuencias Interfaz de

Costos asociados a los fallos

Aspecto del Diseño

Ejemplo

Efectos Inmediatos

Otras consecuencias

Interfaz de

Organización ilógica

Tiempo perdido

Pérdida de confianza en el

Usuario

de la pantalla

sistema

Pantallas de difícil lectura

Aumento de la frustración

Aumento las bajas temporales

Mensajes de ayuda de poca utilidad

Aumento de la tasa de errores

Aumento de la rotación del personal

Ejecución del Programa

La respuesta del sistema es lenta

Igual o peor que antes

Aumento de los costes de funcionamiento

Almacenamie

Pérdida de datos

Trabajo extra para

Disminución de los ingresos

nto de Datos

volver a introducir los

datos

Salidas no fiables

Trabajo extra al verificar los datos

Pérdida de la confianza de los clientes, Pérdida de ventas

• Todo producto de software realiza tareas entre la idea inicial y el producto final. •

Todo producto de software realiza tareas entre la idea inicial y el producto final. Un Modelo de Desarrollo establece el orden en el que se harán las tareas en el proyecto, provee recursos de entrada y salida para cada una de las tareas. Es necesario destacar el ciclo de vida del proyecto y el modelo de desarrollo. El ciclo de vida del proyecto ayuda a controlar las actividades del proyecto desde el inicio al fin del mismo. El modelo de desarrollo es una guía para construir el producto. Ambos se complementan para generar el producto desde el punto de vista técnico y administrativo.

 El Modelo de Cascada.  El Modelo en V.  En Flor.  Prototipos 
  • El Modelo de Cascada.

  • El Modelo en V.

  • En Flor.

  • Prototipos

  • El Modelo de Espiral.

  • El Modelo de Procesos.

  • Desarrollo Incremental.

SECUENCIA PURA  Cumple con el ciclo de desarrollo de software.  Este modelo tiene una
SECUENCIA PURA
SECUENCIA
PURA
  • Cumple con el ciclo de desarrollo de software.

  • Este modelo tiene una

secuencia ordenada.

  • El trabajo de una etapa previa es la entrada del siguiente proceso.

SECUENCIA RETROALIMENTADA
SECUENCIA
RETROALIMENTADA
  • Provee de un gran control

sobre las fechas de entrega y entregables.

  • Establece criterios de entrada

y salida en cada fase

claramente definidos.

 Excelente cuando se tiene un producto estable y se conoce la tecnología  Es un
  • Excelente cuando se tiene un

producto estable y se conoce la tecnología

  • Es un método muy estructurado que funciona bien con gente de mucha experiencia.

  • Provee estabilidad en los requerimientos

  • La Planeación se puede hacer en forma anticipada

  • Para proyectos grandes

  • Tiene poca flexibilidad

  • Los proyectos en la practica raramente siguen un flujo secuencial.

  • Siempre es difícil para el cliente mostrar todos los requerimientos explícitamente y con mucha anticipación

  • El Cliente debe tener paciencia

  • No es factible de cambios una vez terminada una etapa

  • Poco apropiado para aplicaciones para la toma de decisiones

  • Los Usuarios tienen una participación limitada

   Se hace una reexaminación del modelo de ciclo de vida a fin de
  

Se hace una reexaminación del

modelo de ciclo de vida a fin de asegurar la calidad del producto

Cuando cada proceso termina su producto, las especificaciones de prueba deben estar listo para probar el producto

Se valida cada uno de los procesos una vez terminada cada etapa.

 Se basa en la estructura de una flor en la cual cada pétalo será una
  • Se basa en la estructura de una flor en la cual cada pétalo será una etapa a realizar.

REQUE- ANA- RIMIEN LISIS -TOS PRUE- DISEÑO BAS IMPLE- CODI- MENTA FICA- -CION CION
REQUE-
ANA-
RIMIEN
LISIS
-TOS
PRUE-
DISEÑO
BAS
IMPLE-
CODI-
MENTA
FICA-
-CION
CION
  • Sin embargo todas las etapas se deben de desarrollar al mismo tiempo para asi lograr que el procedimiento llegue a obtener un producto final.

  • modelo

Este

puede contemplar las sgtes

etapas:

REQUERIMIENTOS

ANÁLISIS DISEÑO CÓDIFICACION IMPLEMENTACIÓN PRUEBAS

Un prototipo es una versión preliminar de un sistema de información con fines de demostración o

Un prototipo es una versión preliminar de un sistema de información con fines de

demostración o evaluación. (Una versión rápida)

Es usado para definir los requerimientos del sistema de manera directa con el usuario a fin de retroalimentar al proyecto con requerimientos omitidos o procedimientos innecesarios. Puede ser usado para determinar requerimientos justo antes de la fase de requerimientos.

Un prototipo es una versión preliminar de un sistema de información con fines de demostración o

En otro caso, el prototipado puede ser util inmediatamente antes de algún/todo el desarrollo incremental en modelos incrementales o evolutivos.

 Es un método menos formal de  desarrollo. No se conoce cuando se tendrá un
Es
un
método
menos
formal
de
desarrollo.
No se conoce cuando se tendrá un
producto aceptable.
  • El prototipeo es una técnica para comprender las especificaciones.

  • Un prototipo puede ser eliminado.

  • Un prototipo puede llegar a ser parte del producto final.

  • Útiles cuando los requerimientos son cambiantes.

  • Cuando no se conoce bien la aplicación.

  • Cuando el usuario no se quiere comprometer con los requerimientos.

  • Cuando se quiere probar una arquitectura o tecnología.

  • Cuando se requiere rapidez en el desarrollo.

  • No se sabe cuantas iteraciones serán necesarias.

  • Da una falsa ilusión al usuario sobre la velocidad del desarrollo.

  • Se puede volver el producto aún y cuando no este con los estándares.

 Los productos de software son creados a través de múltiples repeticiones del proceso del ciclo
 Los productos de software son creados a través de múltiples repeticiones del proceso del ciclo
  • Los productos de software son creados a través de múltiples repeticiones del proceso del ciclo de vida. Se rompen un mini-proyectos.

  • Estos modelos han sido aplicados al desarrollo de software.

  • Aun no han madurado al punto de ser aplicados como modelos de desarrollo con tiempos y limitaciones de costos.

 El producto avanza a pasos firmes solucionado riesgos en cada iteración.  El producto termina
  • El producto avanza a pasos firmes solucionado riesgos en cada iteración.

  • El producto termina con todos los riesgos resueltos.

  • Se pueden incluir otros métodos de desarrollo en las iteraciones.

  • A medida que el costo aumenta, los

riesgos se reducen.

  • Se tienen puntos de control en cada interacción.

  • Es complicado.

  • Requiere de mucha administración.

  • Difícil de definir los objetivos, metas que indiquen que podemos avanzar al siguiente ciclo.

  • Se puede caer en un desarrollo de nunca acabar.

 Impulsa un proceso iterativo de desarrollo.  Cada ciclo es una versión del producto. 
 Impulsa un proceso iterativo de desarrollo.  Cada ciclo es una versión del producto. 
  • Impulsa un proceso iterativo de desarrollo.

  • Cada ciclo es una versión del producto.

  • Utiliza metas definidas para marcar la transición entre las distintas etapas.

  • Ofrece mayor poder de decisión a los usuarios.

  • Busca mejorar la calidad y creatividad.

 Etapas claramente definidas con metas, entregables y responsables.  Se establecen roles asociados al modelo
  • Etapas claramente definidas con metas, entregables y responsables.

  • Se establecen roles asociados al modelo que promueven la participación de todos.

  • Involucra muy de cerca al usuario.

  • Dado que la mayoría de las decisiones son en consenso por el equipo en su conjunto, en ocasiones toman más tiempo de lo debido.

  • Para proyectos pequeños puede resultar poco practico.

  • El considerar versiones hace que se dejen de lado algunas decisiones.

 Permite construir el proyecto en etapas incrementales en donde cada etapa agrega funcionalidad.  Cada
  • Permite construir el proyecto en etapas incrementales en donde cada etapa agrega funcionalidad.

  • Cada etapa consiste de requerimientos, diseño, codificación, pruebas, y entrega.

  • Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.

Reduce los riesgos ya que:  Permite ver el progreso a través de sus nuevas versiones.

Reduce los riesgos ya que:

  • Permite ver el progreso a través de sus nuevas versiones.

  • Provee retroalimentación a través de la funcionalidad mostrada.

  • Permite atacar los mayores riesgos desde el inicio.

    • Requiere de mucha planeación, tanto administrativa como técnica.

    • Requiere de metas claras

  • Se pueden hacer implementaciones parciales si se cuenta con la suficiente funcionalidad.

  • Las pruebas y la integración es constante.

para conocer el estado del proyecto.

  • El progreso se puede medir en periodos cortos de tiempo.

  • Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

  • Se puede planear en base a la funcionalidad que se quiere entregar primero.

  • La solución se va mejorando en forma progresiva a

través de las múltiples iteraciones.

  • Incrementa el entendimiento del problema y de la solución por medio de los refinamientos sucesivos.

Un Proyecto ... Un proyecto es una organización transitoria de individuos dedicados a alcanzar un objetivo

Un Proyecto ...

Un proyecto es una organización transitoria de individuos dedicados a alcanzar un

objetivo especifico dentro de un periodo de tiempo, un presupuesto, y un objetivo

técnico.

En consecuencia...

Un proyecto:

Tiene un principio y un fin. Debe de tener un objetivo (debe de ser medible). Requiere de un líder y de un equipo.

Lo que nos indica que es:

Temporal y Unico, ya que involucra hacer algo que no se ha hecho antes.

¿ Que Modelo ? • Dado que cada proyecto es único, no existe un modelo que

¿ Que Modelo ?

Dado que cada proyecto es único, no existe un modelo que se aplique al 100% a

todos los proyectos de una organización. Una organización puede contar con uno o más modelos de desarrollo para ser utilizados dependiendo del tipo de proyecto.

El modelo seleccionado tendrá influencia en el éxito del proyecto y en el tipo de

decisiones que se deberán hacer.

¿ Cual seguir?

Para seleccionar el modelo a adoptar habrá que hacerse una serie de cuestionamientos:

¿Qué tantos son los riesgos del proyecto?

¿Qué tan claros están los requerimientos?

¿Se conoce bien la tecnología ha utilizar?

¿Visibilidad que requiere el proyecto?

¿Qué tanta planeación hacia adelante es requerida? ¿Qué restricciones se tienen?

Criterios de Éxito • Contar con un modelo debidamente documentado. (entradas, salidas, • entregables, aprobaciones) Los

Criterios de Éxito

Contar con un modelo debidamente documentado. (entradas, salidas,

entregables, aprobaciones) Los documentos deben de estar actualizados.

La gente que participa en el proyecto debe estar capacitada en su uso.

Se debe de reforzar el uso del modelo mediante supervisiones y

revisiones programadas. La alta gerencia debe soportar la utilización de un modelo.

Cualquier desviación al modelo debe ser documentada y aprobada.

Se debe de medir la eficiencia del modelo.

Retroalimentar y ajustar.

Se muestra un cuadro comparativo considerando algunos criterios básicos, la medida utilizada indica el nivel de

Se muestra un cuadro comparativo considerando algunos criterios básicos, la

medida utilizada indica el nivel de efectividad del modelo de acuerdo al criterio

Se muestra un cuadro comparativo considerando algunos criterios básicos, la medida utilizada indica el nivel de
Desarrollo Iterativo: Ventajas • Tolerable a cambios en los requerimientos • Los elementos son integrados progresivamente

Desarrollo Iterativo: Ventajas

Desarrollo Iterativo: Ventajas • Tolerable a cambios en los requerimientos • Los elementos son integrados progresivamente

Tolerable a cambios en los requerimientos Los elementos son integrados progresivamente Los riesgos son mitigados en etapas tempranas Permite a la organización aprender e improvisar Facilita el reúso, porque es fácil identificar partes comunes diseñadas o implementadas Resulta un producto más robusto ya que los errores se van corrigiendo en cada iteración El proceso puede ser improvisado y refinado en el desarrollo

• Si no existe una disciplina de control, el proceso de desarrollo rápi- damente degenera en
• Si no existe una disciplina de control, el proceso de desarrollo rápi- damente degenera en

Si no existe una disciplina de control, el proceso de desarrollo rápi- damente degenera en caos La coordinación de las actividades y artefactos de los desarrollado-

res y equipos, involucra establecer flujos repetibles para la adminis-

tración de cambios de software. Esta coordinación permite una me-

jor identificación de los recursos básicos en las prioridades y riesgos del proyecto.

El control de cambios es más

que revisar entradas y salidas en los archivos. Esto incluye administrar los flujos, el desa-

rrollo paralelo, la integración

y la construcción del software.

Un Modelo es una simplificación de la realidad que describe completamente un sistema desde una perspectiva

Un Modelo es una simplificación de la realidad que describe

completamente un sistema desde una perspectiva particular

Un Modelo es una simplificación de la realidad que describe completamente un sistema desde una perspectiva

El modelado es importante porque

ayuda al equipo a

visualizar, especificar,

construir y documentar la estructura y el comportamiento de la arquitectura del sistema

Un modelo correctamente diseñado usando tecnología de objetos es: • Fácil de entender: Claramente corresponde a

Un modelo correctamente diseñado usando tecnología de objetos es:

Fácil de entender: Claramente corresponde a la realidad. Fácil de modificar: Cambios en un aspecto en particular concierne únicamente al objeto

que representa ese

aspecto Se implementa a través de UML

UML “Lenguaje de Modelamiento Unificado” es un
UML
“Lenguaje de Modelamiento Unificado” es un

compendio de los principales métodos de análisis y diseño

orientado a objetos

CARACTERISTICAS:

CARACTERISTICAS:

CARACTERISTICAS: