PROYECTO SEGÚN EL R.A.E : proyecto, ta. (Del lat. proiectus). adj. Geom. Representado en perspectiva. 2. m. Planta y disposición que se forma para la realización de un tratado, o para la ejecución de algo de importancia. 3. m. Designio o pensamiento de ejecutar algo. 4. m. Conjunto de escritos, cálculos y dibujos que se hacen para dar idea de cómo ha de ser y lo que ha de costar una obra de arquitectura o de ingeniería. 5. m. Primer esquema o plan de cualquier trabajo que se hace a veces como prueba antes de darle la forma definitiva.

Proyecto Informático El proyecto representa el enunciado de una intervención concreta de la que se espera tener resultados que contribuyan al logro de los efectos específicos que un programa define. Como tal, expresa el nivel operativo del proceso de planificación, por lo que sus metodologías y técnicas serán de uso habitual para los profesionales de la Intervención social.   La informática, aun los grandes sistemas, era considerada mas como una labor artesana, muy próxima al programador, que como una técnica con necesidad de una planificación efectiva. Este notable aumento de la complejidad de la informática ha sido la que ha hecho necesario su consideración como proyecto, asociándose las técnicas y procedimientos de diseño, planificación y gestión del proyecto tradicional.

Gestión de Proyectos

Gestión La Gestión de Proyectos implica la planificación, supervisión, y control del personal, del proceso y de los eventos que ocurren mientras evoluciona el software desde la fase preliminar a la implementación operacional. Se concentra en las 4P: Personal Producto Proceso Proyecto

Personal Es la parte más importante A veces se da por descontado que es así y se actúa en contra Los participantes son: Gestores superiores (definen los aspectos del negocio) Gestores técnicos del proyecto (planifican, motivan, organizan y controlan) Profesionales (Proporcionan las capacidades técnicas para hacer un producto o aplicación ) Clientes (Especifican los requisitos del proyecto o aplicación) Usuarios finales (Harán uso del software cuando haya sido entregado)

Miembros del equipo de desarrollo

Organización del equipo de desarrollo Jerárquico. Propuesta por primera vez por Harlan Mills y descrita en 1972. También se le conoce como equipo programador jefe El núcleo se compone de: Programador o ingeniero en jefe. Planifica, coordina y revisa todas las actividades técnicas del equipo. Personal técnico. Llevan a cabo las actividades de análisis y desarrollo. Ingeniero de apoyo. Ayuda al ingeniero en jefe y puede sustituirle sin perdida de continuidad del proyecto. Además existen especialistas que ayudan al ingeniero en jefe. Por ejemplo, expertos en bases de datos, comunicaciones, etc. Y un bibliotecario de software (librarian), que puede colaborar con varios equipos a la vez y se encarga de la documentación, listados fuente, ayuda a recopilar datos de productividad y cataloga e indexa los módulos u objetos reutilizables.

Organización de equipos según Mantei Descentralizado democrático (DD). No tiene un jefe permanente. Se nombran coordinadores de tareas a corto plazo y se sustituyen por otros para diferentes tareas. Las decisiones y los enfoques se hacen por consenso. La comunicación entre los miembros del equipo es horizontal. Descentralizado controlado (DC). Tiene un jefe definido que coordina tareas específicas y jefes secundarios que tienen responsabilidades sobre subtareas. La solución de problemas es una actividad del grupo, pero la implementación de soluciones se reparte entre los subgrupos por el jefe de equipo. La comunicación entre subgrupos e individuos es horizontal. También hay comunicación vertical a lo largo de la jerarquía de control. Centralizado controlado (CC). El jefe de equipo se encarga de la solución de problemas a alto nivel y la coordinación interna del equipo. La comunicación entre el jefe y los miembros del equipo es vertical.

Existen siete factores de un proyecto que deben considerarse al planificar el organigrama de equipos. Dificultad del problema. Tamaño del programa en líneas de código o puntos de función. Tiempo de vida del equipo. Grado en que el problema puede ser modularizado. Calidad requerida y fiabilidad del sistema que se va a construir. Rigidez de la fecha de entrega. Grado de comunicación requerido para el proyecto.

Tipo de Equipo DD DC CC Dificultad Alta x   Pequeña Tamaño Grande Pequeño Duración del equipo Corto Largo

Modularidad Alta   x Baja Fiabilidad Fecha de entrega Estricta Flexible Comunicación Pequeña

Paradigmas de organización de equipos según Constantine Paradigma cerrado. Tiene jerarquía tradicional de autoridad similar al equipo CC. Trabajan bien cuando producen software similar a otros anteriores, pero son menos innovadores. Paradigma aleatorio. El equipo se estructura libremente y depende de la iniciativa individual de los miembros. Son buenos cuando se requiere innovación o avances tecnológicos. Tienen problemas cuando se requiere un rendimiento ordenado. Paradigma abierto. Estructura el equipo de forma que consiga algunos de los controles asociados con el paradigma cerrado y mucha de la innovación del paradigma aleatorio. El trabajo se desarrolla en colaboración, con mucha comunicación y toma de decisiones consensuadas. Son adecuados para resolver problemas complejos, pero pueden no ser tan eficientes como otros equipos. Paradigma sincronizado. Se basa en la partición natural de un problema y organiza los miembros del equipo para trabajar en partes del problema con poca comunicación activa entre ellos.

Actividades del equipo de desarrollo Comunicación con el cliente. Planeación. Análisis de riesgos. Ingeniería. Construcción y liberación. Evaluación del cliente.

Toxicidad de un equipo Atmósfera de trabajo frenética. Se gasta mucha energía y se descentran los objetivos Alta frustración por motivos tecnológicos o personales Procedimientos coordinados pobremente Definición confusa de los roles Continua y repetida exposición al fallo

Para pensar Cuanto antes se empieza a programar: más se demora Ley de Brooks: Añade más gente a un proyecto retrasado y harás que se retrase más

Producto Ámbito del software Descomposición del problema Contexto. ¿Cómo encaja el software en el sistema? Objetivos. ¿Qué datos son visibles al cliente? ¿Qué objetos de entrada son requeridos? Función y rendimiento. ¿Cómo transforma los datos de entrada en salida? ¿Qué más hay que saber? Descomposición del problema “Divide y triunfarás” Top Down

Proceso Modelo: Secuencial Lineal Cascada(*) Espiral Concurrente Forma 4ta Generación

METODOLÓGIAS DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN METODO ESPIRAL

INTRODUCCIÓN Son métodos que indican cómo hacer más eficiente el desarrollo de sistemas de información. Para ello suelen estructurar en fases la vida de dichos sistemas con el fin de facilitar su planificación, desarrollo y mantenimiento. Las metodologías de desarrollo de sistemas deben definir: objetivos, fases, tareas, productos y responsables, necesarios para la correcta realización del proceso y su seguimiento.

Los principales objetivos de una metodología de desarrollo son: Asegurar la uniformidad y calidad tanto del desarrollo como del sistema en sí. Satisfacer las necesidades de los usuarios del sistema. Conseguir un mayor nivel de rendimiento y eficiencia del personal asignado al desarrollo. Ajustarse a los plazos y costes previstos en la planificación. Generar de forma adecuada la documentación asociada a los sistemas. Facilitar el mantenimiento posterior de los sistemas.

METODO ESPIRAL Es un modelo de ciclo de vida orientado a riesgos que divide un proyecto software en mini-proyectos. Cada mini proyecto se centra en uno o más riesgos importantes hasta que todos estén controlados. Después de controlar todos los riesgos más importantes, el modelo en espiral finaliza del mismo modo que el ciclo de vida en cascada.(1) 1 .Nota:Cada fase tiene como resultado documentos que deben ser aprobados por el usuario. Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la corrección de los problemas encontrados en fases previas.

Método Desarrollo en Espiral Funcionamiento: Se parte de una escala pequeña en medio de la espiral, se localizan los riesgos, se genera un plan para manejar los riesgos, y a continuación se establece una aproximación a la siguiente interacción. Cada iteración supone que el proyecto pasa a una escala superior. Se avanza un nivel en el Espiral, se comprueba que se tiene lo que se desea, y después se comienza a trabajar en el siguiente nivel:

Método Desarrollo en Espiral Con cada iteración a través del espiral se construye sucesivas versiones de software cada vez más completas. En cada bucle alrededor del espiral, la culminación del análisis de riesgo resulta una decisión de “seguir” o “no seguir”. Cada interacción en el método espiral lleva consigo los seis pasos : determinar los objetivos, las alternativas, los límites, la identificación de riesgos, resolución de riesgos y evaluación de alternativas.

Federratas: Debemos de considerar la generación de entregas de la iteración en el modelo espiral, comprobando que son correctas. En el modelo en espiral, las primeras iteraciones son las menos costosas. Supone menos gastos, desarrollar el concepto de operación que realiza el desarrollo de los requerimientos y también es menos costoso desarrollar los requerimientos que se llevarán acabo el desarrollo del diseño, la implementación del producto y la prueba del mismo.

En cada Cuadrante del Método espiral se realiza las siguientes actividades: Planificación: Determinación de objetivos, alternativas, restricciones, y elaboración del plan de desarrollo para el ciclo actual. Análisis de Riesgos: Evaluación de las alternativas, identificación y resolución de riesgos. Se decide si se sigue o no con el proyecto Ingeniería: Desarrollo del producto siguiendo un modelo de ciclo de vida : cascada, prototipo, etc. Evaluación por el cliente, valoración de resultados, etc.

Aplicación del desarrollo en espiral al proyecto En esta figura se aprecia que el desarrollo en espiral esta formado por ciclos divididos en cuatro fases: Análisis de requisitos, diseño e implementación, pruebas y planificación del próximo ciclo de desarrollo.

Maduración del Proceso Comunicación con el cliente Planificación Análisis de riesgo Ingeniería Construcción y entrega Construir Probar Instalar Asistencia (Documentación y Formación) Evaluación del cliente

Proyecto Para gestionar un proyecto de software con éxito, debemos comprender que puede ir mal y cómo hacerlo bien Diez señales de peligro (7 indican fallo) La gente del software no comprende las necesidades del cliente El ámbito del producto está definido pobremente Los cambios están mal realizados La tecnología elegida cambia Las necesidades del negocio cambian Las fechas de entrega no son realistas Los usuarios se resisten Se pierden los patrocinadores No hay personal con las habilidades necesarias Los gestores evitan prácticas y sabias lecciones

Cómo actúa un Gestor Empieza con el pie derecho Mantenerse Seguimiento Comprende bien el problema Objetivos y expectativas realistas Mantenerse Seguimiento Tomar decisiones inteligentes Análisis Post Mortem

Ejercicio Hacer una planilla en Excel con el grupo de proyecto Colocar personas y tareas en columnas y filas Definir : ¿Quién dirige? ¿Quién hace cada tarea? ¿Por qué la hace? Aclarar en la celda correspondiente