Modelo de Desarrollo PROTOTIPADO

PROYECTOS TECNOLOGICOS
Modelo de Desarrollo
PROTOTIPADO
TALLER LLL
Septiembre 2005
Ing. Marcelo Carrera
[email protected]
09-615-8303
Estrategia para el Desarrollo Rápido
1.
2.
3.
4.
Evitar los errores clásicos
Aplicar las bases del desarrollo
Gestionar los riesgos para evitar un retorno catastrófico
Aplicar métodos orientados a planificación
El soporte óptimo para el mejor plan posible es tener los
cuatro pilares colocados en su lugar, y hacer que cada uno de
ellos sea lo más fuerte posible.
Podemos utilizar los métodos más potentes orientados a la
planificación, pero si cometemos el error clásico de descuidar la
calidad del proyecto en sus fases iniciales, desperdiciaremos
tiempo corrigiendo defectos justo cuando es más caro; nuestro
proyecto se retrasará.
Si pasamos por alto el “axioma de desarrollo” de crear un
buen diseño antes de comenzar a codificar, nuestro
programa fallará cuando cambie la concepción del producto
durante el proceso de desarrollo, y el proyecto se
retrasará.
Dimensiones de la Velocidad de Desarrollo
Las personas aprenden y/o trabajan
rápidamente o lentamente.
El proceso
supone una
mejora en la
actividad de las
personas, o
coloca un
obstáculo
detrás.
Personas
Proceso
Producto
Tecnología
Un producto se
define de forma
que casi se
construye solo, o
de forma que pone
obstáculos a los
mejores esfuerzos
de la gente que
está
construyéndolo.
La tecnología ayuda al esfuerzo del
desarrollo u obstaculiza los mejores
intentos de los desarrolladores.
Centrarse en el producto impediría centrarse en el proceso.
Es fundamental centrarse al mismo tiempo en la gente, el
proceso, el producto y la tecnología.
PERSONAS
1. Selección del personal para equipos de proyectos
2. Organización del equipo
3. Motivación
5 principios para la selección de personal:
- Máximo talento... poco y buen personal
- Trabajo adecuado... Asignar tareas según la habilidad y motivación de la gente
disponible.
- Progresión profesional... Ayudar a la gente a actualizarse por sí misma, con una base
inicial de conocimiento formal.
- Equilibrio del equipo... Seleccionar a gente que se complementa y armonice con los
demás.
- Eliminar la inadaptación... Eliminar y reemplazar a los miembros problemáticos del
equipo lo antes posible.
La forma de organizar al personal tiene un gran efecto sobre la eficiencia
con la que trabajen. Es clave establecer la estructura del equipo para que
concuerden con el tamaño del proyecto, las características del producto y
los objetivos de planificación.
Una persona que carece de motivación no va a querer trabajar duro, y prefiere
dejarse llevar. La motivación es potencialmente el aliado más fuerte que tenemos
para el desarrollo rápido de un proyecto.
PROCESO
1.
2.
3.
4.
5.
6.
Evitar la repetición de trabajo
Control de calidad
Bases del desarrollo
Gestión de riesgos
Atención a los recursos
Planificación del ciclo de vida
Una de las mejores formas de ahorro de tiempo en los proyectos tecnológicos es orientar el
proceso de forma que se evite hacer la misma cosa dos veces. Lo que suele suceder cuando
el proceso no es analizado para su optimización (con acciones preliminares de aprendizaje y
adaptación) es que si ha habido problemas en el diseño que no se descubren hasta la prueba,
se debe volver al diseño detallado y la codificación y comenzar de nuevo.
El objetivo principal del control de calidad es detectar los errores en el proceso,
durante la etapa de diseño y prototipado, para corregirlos a tiempo
(no es el de buscar culpables).
La base de desarrollo (metodologías y estándares) es fundamental para minimizar los malos
entendidos que puedan afectar el trabajo de todos los actores. A pesar de que los métodos
estándar en tecnología para el análisis, diseño, construcción, integración y pruebas no van a
acelerar el desarrollo de forma fulgurante, pueden evitar que los proyectos se queden fuera
de control.
Un modelo de ciclo de vida es útil cuando describe un plan de gestión básico, y hace
que sea más fácil identificar y organizar las muchas tareas necesarias en un proyecto,
y así poder realizarlas con la mayor eficacia.
PRODUCTO
1. Orientación del CLIENTE
2. Tamaño del producto
3. Características del producto
Desarrollar el software o hardware a partir de la especificación es solo la mitad del
trabajo. La otra mitad es ayudar al cliente a definir el producto que desea, y la mayoría
de las veces es necesario una aproximación diferente a la tradicional especificación en
papel. Ponerse en su lugar es una de las mejores formas de evitar las vueltas atrás,
pero es fundamental que el cliente participe como actor desde la etapa de diseño
(aprenda y opine).
Podremos reducir drásticamente el tamaño del producto esforzándonos en
desarrollar solo las prestaciones más esenciales, o reducirlo temporalmente
desarrollando el producto en etapas. También es posible reducirlo empleando
herramientas o soluciones previas similares (ya existentes desarrolladas) o que
necesiten menos codificación (prototipos funcionales).
Se empleará más tiempo en desarrollar un producto con objetivos ambiciosos muy
detallados; por tanto se sugiere que en las primeras fases del diseño se establezcan las
prioridades (funciones fundamentales que cubran el objetivo del proyecto) mientras que
las funciones orientadas a la optimización se las dejen para las siguientes fases del
proyecto total.
TECNOLOGIA
1. Síndrome de la panacea
2. Sobreestimación de las ventajas del empleo
de nuevas herramientas o métodos
3. Cambiar herramienta a mitad del proyecto
Se confía demasiado en las ventajas proclamadas de tecnologías que no se habían usado
antes y demasiada poca información sobre lo buenas que serían en este entorno de desarrollo
concreto. Cuando el equipo de desarrollo se aferra sólo a una nueva técnica, una nueva
tecnología o un nuevo proceso rígido, y espera resolver con ello sus problemas de
planificación, está inevitablemente equivocado.
Las organizaciones mejoran raramente su productividad a grandes saltos, sin importar
cuántas nuevas herramientas o métodos empleen o lo buenos que sean. Los beneficios
de las nuevas técnicas son parcialmente desplazados por las curvas de aprendizaje que
llevan asociadas, y aprender a utilizar nuevas técnicas para aprovecharlas al máximo
lleva su tiempo. Las nuevas técnicas también suponen nuevos riesgos, que sólo
descubriremos usándolas, por lo que se requiere una fase piloto de evaluación (como
parte del Prototipado)
Cambiar la herramienta es un viejo recurso que funciona raramente. Cuando estamos a la
mitad de un proyecto (en su fase de desarrollo, peor aún casi ya para ser utilizado por el
usuario final), la curva de aprendizaje, rehacer el trabajo y los inevitables errores cometidos
con una herramienta totalmente nueva, normalmente anulan cualquier posible beneficio.
PLANIFICACION del CICLO DE VIDA
Un ciclo de vida consiste en realizar todas las actividades
(agrupadas) comprendidas entre el momento en el que se
inicia la recopilación de información preliminar (como una
chispa en la imaginación de alguien) y el momento en el que la
versión XXX exhala su último aliento en la máquina del último
usuario final.
Un modelo de ciclo de vida es un modelo descriptivo de lo que
pasaría entre la primera chispa y el último aliento.
Para nuestro propósito, la función principal de un modelo de ciclo de vida es establecer
el orden en el que se especifica,se diseña (prototipado), desarrolla, revisa, prueba,
implementa en producción y se realizan otras actividades en un proyecto; todas ellas
orientadas a cumplir con el o los objetivos del proyecto (establecidos previamente).
El PROTOTIPADO realmente se centra en una parte limitada de todo el ciclo de vida, y
constituye el período que va desde la primera chispa hasta la versión inicial (prototipo
funcional u operativo).
El modelo de ciclo de vida más común para proyectos pequeños es el de cascada,
mientras que para proyectos grandes o complejos se utiliza comúnmente el de espiral.
El modelo del ciclo de vida (planificación) establecido puede orientar su proyecto y
ayudarle a asegurar que cada paso se acerque más a la consecución del objetivo.
Dependiendo del ciclo de vida que se establezca, se podrá aumentar la velocidad de
desarrollo, mejorar la calidad, el control y el seguimiento del proyecto, minimizar gastos
y riesgos, o mejorar las relaciones con los usuarios finales.
PROTOTIPADO por CASCADA
Objetivos y
conceptualización
del producto
Análisis de Productos y
Prototipos
Análisis de
requerimientos
Diseño Global
Diseño
detallado
Codificación y
depuración
Construcción de
Prototipos funcionales
y/o para evaluación
Pruebas
PROTOTIPADO por CASCADA...
En este modelo, un proyecto progresa a través
de una secuencia ordenada de pasos partiendo
del concepto inicial del producto hasta la
prueba para evaluar la efectividad y
características esperadas.
Cuando la revisión determina que el producto no está
listo para pasar a la fase de desarrollo, permanece en
la etapa de construcción hasta que cumpla con lo
prioritariamente establecido.
No proporciona resultados tangibles (software o hardware completo) hasta el
final del ciclo de vida, pero la documentación que se genera proporciona
indicaciones significativas del progreso a lo largo del ciclo de vida.
PLANIFICACION o PROTOTIPADO por ESPIRAL
El modelo espiral esta orientado a riesgos que divide un proyecto grande y
complejo en mini-proyectos (fases).
El concepto de riesgo se refiere a requerimientos poco comprensibles,
arquitecturas poco comprensibles o desconocidas, y problemas de ejecución
por magnitud o dificultades.
Este modelo suele ser utilizado para Planificar un proyecto completo.
En este modelo se comienza con una parte pequeña del proyecto y
luego se va expandiendo. Se amplía el alcance sólo después de
reducir los riesgos a un nivel aceptable para la siguiente fase.
Cada fase lleva consigo los 6 pasos:
1. Determinar objetivos, alternativas y límites.
2. Identificar y resolver riesgos.
3. Evaluar las alternativas.
4. Generar las entregas de esta fase, y
comprobar que son correctas.
5. Planificar la siguiente fase.
6. Establecer un enfoque para la siguiente fase
(si se decide ejecutarla)
PLANIFICACION o PROTOTIPADO por ESPIRAL...
Determinar objetivos, alternativas y
restricciones
Acordar un
enfoque
para la
próxima
fase
REVISION
Identificar y resolver riesgos
Análisis de
riesgos
Análisis de
riesgos
Plan del
ciclo de vida
INICIO
Plan de
requerimientos
Plan de desarrollo
ar
c
i
f
la
ni
Pla
nte
e
i
u
se
sig fa
Plan de Integración y pruebas
Entregar al
usuario
Prototipo
Operativo
Análisis de
Prototipo3
riesgos
Prototipo2
Análisis de
Prototipo1
riesgos
Simulacio
Concepto de
nes
funcionamiento
Validación
de requers.
Requerimi
entos
Validación y
Verificación del Diseño
Prueba de
aceptación
Integración
y prueba
Modelos
Diseño
del
Producto
Evaluar
alternativas
Pruebas
Diseño
Detallado
Prueba de
Codificación
c / unidad
Desarrollar las funciones y
comprobar que son correctas
PLANIFICACION o PROTOTIPADO por ESPIRAL...
En éste modelo, las primeras fases son las menos costosas. Supone menos
gasto desarrollar el concepto de operación que realizar el desarrollo de los
requerimientos, y también es menos costoso desarrollar los requerimientos
que llevar a cabo el desarrollo del diseño, la implementación del producto y
la prueba del mismo.
El significado del diagrama no tiene porqué seguirse de
forma literal. No es importante que la espiral tenga
exactamente cuatro ciclos, y no es importante tampoco
que se realicen exactamente 6 pasos como se indica,
aunque se trata de un orden apropiado a utilizar. Puede
adaptar cada fase de la espiral a las necesidades que
demanda su proyecto.
Este modelo se puede combinar con el de cascada, tal que se puede
comenzar un proyecto con una serie de fases para reducir los
riesgos; después de que se hayan reducido los riesgos a un nivel
aceptable, se puede finalizar el esfuerzo de desarrollo con un ciclo
de vida en cascada.
PLANIFICACION o PROTOTIPADO por ESPIRAL...
Por ejemplo, si uno de los riesgos consiste en que no tiene seguridad de alcanzar
los objetivos de rendimiento, puede incluir una fase de prototipado para investigar
si es posible la consecución de estos objetivos.
El modelo en espiral proporciona control de gestión, ya que se tiene los
puntos de verificación al final de cada fase. Como el modelo está
orientado a riesgos, le proporciona con anterioridad indicaciones de
cualquier riesgo insuperable. Descubrirá si el proyecto o mini-proyecto
no se puede realizar por razones técnicas u otras razones, y eso no
supondrá un costo excesivo, ya que se podrá tomar una decisión
alternativa a tiempo.
La única desventaja de este modelo es que se
trata de un modelo complicado. Requiere de
una gestión concienzuda, atenta y que exige
conocimientos profundos. Puede ser difícil
definir hitos (criterios) de comprobación que
indiquen si está preparado para pasar al
siguiente nivel de la espiral; por tal razón es
recomendable que la validación y decisiones
sean tomadas por un equipo (pequeño) de
responsables.
PROTOTIPADO EVOLUTIVO
Como se puede observar, en el modelo de espiral, se
encuentra establecido un desarrollo de prototipos por
fases, a esto se lo denomina PROTOTIPADO
EVOLUTIVO, en el que se desarrolla el concepto del
sistema (producto tecnológico) a medida que avanza el
proyecto. Normalmente se comienza desarrollando los
aspectos más visibles del sistema. Puede presentar la
parte del sistema al cliente y entonces continuar el
desarrollo del prototipo basándose en la realimentación
que recibe.
En algún punto usted y el usuario se ponen de acuerdo
en que el prototipo es lo suficientemente bueno. En
este punto, se completa cualquier trabajo pendiente en
el sistema y se entrega el prototipo como el producto
final; incluso en muchos casos es OPERATIVO (que
puede ser utilizado por el usuario con información
real).
PROTOTIPADO EVOLUTIVO...
El prototipado evolutivo se utiliza especialmente cuando los requerimientos
cambian con rapidez, cuando el usuario es reacio a especificar el conjunto de
los requerimientos, o cuando ni usted ni el usuario identifican de forma
apropiada el área de aplicación. También es útil cuando los desarrolladores
no están seguros de la arquitectura o los algoritmos adecuados a utilizar.
Con esto se generan signos visibles de progreso, que se pueden utilizar
especialmente cuando existe una gran demanda en la velocidad del
desarrollo (por parte de los financistas y/o usuarios finales).
Un prototipado evolutivo real incluye análisis de
requerimientos real, diseño real, y código
pensado para el mantenimiento real, en niveles
ligeramente inferiores de lo que se utilizan con
las aproximaciones tradicionales o generales.
Las herramientas informáticas a utilizar en la
construcción de prototipos operativos son aquellas
que permitan generar aplicaciones de forma rápida
(aunque no contemplen todo el detalle que uno
aspira), tales como: MS Excel (hojas electrónicas),
MS Access, Front Page.
DESARROLLO ORIENTADO AL USUARIO
En un estudio de más de 8.000 proyectos, el Grupo
Standish encontró que el factor principal para que los
proyectos tengas éxito es la relación con el usuario.
Algunos expertos en desarrollo rápido sostienen que la
buena comunicación con el usuario final es uno de los tres
factores críticos de los proyectos. Se lo puede o debe
entender como AMISTAD CON EL USUARIO, pero antes es
fundamental identificar claramente ¿QUIEN REALMENTE
ES EL USUARIO (intermedio y final)?.
Existen varios aspectos por los que el usuario puede crear riesgos en la planificación,
tales como: los usuarios no saben lo que quieren, los usuarios no quieren
comprometerse a tener un conjunto de requerimientos escritos, los usuarios insisten
en establecer nuevos requerimientos una vez que se han fijado la planificación y el
presupuesto, la comunicación con los usuarios es lenta, los usuarios no participan en
las revisiones o son incapaces de hacerlas, los usuarios no están preparados
técnicamente, los usuarios no dejan realizar el trabajo, los usuarios no entienden el
proceso de desarrollo de tecnología, el usuario nuevo es desconocido y no se saben
cuáles son los riesgos que generaría.
El establecimiento de buenas relaciones con los usuarios le permite identificar mejor
los riesgos y controlarlos durante el desarrollo del proyecto.
DESARROLLO ORIENTADO AL USUARIO...
ETAPAS ORIENTADAS AL USUARIO
• Planificación: Identificar al cliente real y llegar a
conocerlo (fortalezas, debilidades, necesidades,
disponibilidad, responsabilidades); Establecer métodos
para interactuar con los usuarios.
• Análisis de requerimientos: el objetivo es recopilar los
requerimientos reales, para lo cual primero se debe
recopilar todos los requerimientos que los expertos y los
usuarios indican, y después determinar la importancia de
cada uno (su valor frente al objetivo). En esta etapa se
suelen utilizar prototipos documentales (utilizando
herramientas gráficas) de descripción.
• Diseño: Puede que haya hecho un trabajo perfecto de
recopilación de requerimientos, o puede que no. Utilice
métodos y estándares que permitan a los usuarios
cambiar de opinión a tiempo.
• Construcción: En el momento de generar los prototipos
funcionales, e incluso crear el producto mismo, los
usuarios estarán tan involucrados en el proceso de
desarrollo que no tendrá que preocuparse de ellos.
CONTROL DEL CONJUNTO DE FUNCIONES
El problema más serio de “Control de
Conjunto de Funciones” del producto o
productos a desarrollar es el de los
requerimientos tardíos o el cambio de
requerimientos complejos en la mitad del
proyecto.
Varios estudios han encontrado que los
cambios de requerimientos son la más
común o una de las más comunes fuentes
de incrementos de costo y planificación;
también representan un factor importante
en la cancelación de proyectos.
Hay 3 tipos generales de control de conjunto de funciones:
• Control al principio del proyecto
• Control a mitad del proyecto
• Control al final del proyecto
CONTROL DEL CONJUNTO DE FUNCIONES...
Control al principio del proyecto: definir un conjunto de funciones (características
primordiales del producto) consistentes con los objetivos de planificación y presupuesto
del proyecto. Consiste en no introducir funciones innecesarias en el proyecto, para lo
cual se recomienda:
• Especificación mínima... Consiste en colocar la información mínima necesaria para
especificar de forma comprensible cada función o característica del producto, para lo cual
puede realizar: una “Especificación resumida”; una “Especificación del punto de partida”
(especificación aproximada inicial, no pensando en mantenerla sino solo para conseguir un
consenso de los expertos y usuarios); un “Manual de usuario como especificación”; “Prototipos
de interfaz de usuario” (creados con herramientas gráficas documentales); “Cuadernos”; y/o
“Definición del alcance” (describa lo que hay que incluir y lo que no hay que dejar fuera del
producto)... todas alineadas con el objetivo establecido del proyecto.
• Filtrado de requerimientos... Estudie los requerimientos recopilados con cuidado bajo los
siguientes objetivos: Eliminar todos los requerimientos que no son absolutamente necesarios;
Simplificar todos los requerimientos que son más complicados de lo necesario; Sustituir con
opciones menos costosas todos los requerimientos que dispongan de opciones más económicas.
• Desarrollo por versiones... Puede planificar un conjunto de requerimientos para un
proyecto robusto, completo e ideal, pero luego implementar el proyecto por partes. Ponga las
conexiones que necesite para soportar los elementos posteriores, pero no los implemente. Los
métodos de desarrollo de entrega evolutiva y entre por etapas pueden ayudarle en este
enfoque.
• Control a mitad del proyecto: para controlar los cambios de requerimientos (siempre
que sean importantes a favor del objetivo del proyecto, y no requiere rehacer los
productos).
• Control al final del proyecto: recortando funciones para alcanzar un objetivo de
planificación o de costo.
LABORATORIO (1er Día)
En grupos de trabajo, seleccionar un tema de proyecto y
desarrollar lo siguiente en una presentación (en Power Point
y/o Papelógrafo):
1)
2)
3)
4)
5)
6)
Descripción del proyecto (corta)
Identificación y descripción de los usuarios (intermedios y
finales)
Objetivos generales del proyecto
Objetivos específicos del proyecto (ordenados de acuerdo a
prioridades)
Descripción de los productos tecnológicos a desarrollar y/o
implementar
Establecer la planificación del proyecto (solo acciones)
según el modelo en cascada, de espiral, o combinando
ambos.
LABORATORIO (2do Día)
En los mismos grupos de trabajo del 1er Día, completar:
1)
2)
3)
4)
5)
6)
Descripción de las fases (y las formas) en la que los usuarios
estarán involucrados en el proyecto.
Listado de requerimientos globales
Listado de los requerimientos reales (determinados según el
criterio profundo del equipo de trabajo)
Descripción de las funciones de cada uno de los productos
tecnológicos
Graficar un diagrama que explique el prototipado evolutivo
que se aplicará en el proyecto (qué prototipos se crearán y
en qué orden serán creados)
Indicar por proyector o en papelógrafo algunos ejemplos de
prototipos preliminares que se desea obtener