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