admon-proyectos-tenologicos-proceso
•Download as PPS, PDF•
0 likes•1,028 views
admon-proyectos-tenologicos-proceso
![Por: Adolfo José Araujo Jaimes [email_address] www.ingwebsu.wordpress.com www.linkedin.com/in/ajaraujo Administración de Proyectos Tecnológicos](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (8)
Similar to admon-proyectos-tenologicos-proceso
Similar to admon-proyectos-tenologicos-proceso (20)
More from Adolfo J. Araujo J. ajaraujo
More from Adolfo J. Araujo J. ajaraujo (20)
Recently uploaded
Recently uploaded (20)
admon-proyectos-tenologicos-proceso
- 1. Administración de proyectos Tecnológicos Introducción Administración de Proyectos Tecnológicos
- 2. Por: Adolfo José Araujo Jaimes [email_address] www.ingwebsu.wordpress.com www.linkedin.com/in/ajaraujo Administración de Proyectos Tecnológicos
- 9. Objetivo de la administración de Proyectos Objetivo y Expectativa Alcance Tiempo Coste Administración de Proyectos Tecnológicos
- 10. ¿Proyectos Web? Aplicar una única herramienta Codificar 36 horas de un tirón Prototipos Emplear Métodos Ágiles Cualquier método recomendado por la revista Business Week
- 14. DIMENSIONES DE LA ADMINISTRACIÓN DE PROYECTOS Administración de Proyectos Tecnológicos Personas Producto Proceso Tecnología
- 20. Niveles de Madurez Suficiente para una empresa Inicial Repetible Definido Gestionado Optimiza n do El proceso es informal y ad hoc Se institucionalizan las prácticas de administración del proyecto Las prácticas técnicas de Ing. se integran con las practicas de administración y se institucionalizan El producto y el proceso se controlan cuantitativamente Se institucionaliza la mejora del proceso Nivel Características Proceso Procesos administración del Cambio del Proceso administración del Cambio de Tecnología Prevención de Defectos administración de Calidad administración Cuantitativa del Proceso Enfoque en el Proceso -Definición del Proceso Programa de Entrenamiento - Ingeniería del Producto de Software - Revisiones por Iguales (compañero) Coordinación entre Grupos - administración Integrada del Software (Project server) administración de Requisitos - Planificación del Proyecto - administración de Configuración - Garantía de Calidad-Seguimiento y Control del Proyecto - administración de Subcontratación
- 21. Niveles de Madurez Predicción Más Realistas No ahorra tiempo Reducen el tiempo Inicial Repetible Definido Gestionado Optimizando El proceso es informal y ad hoc Se institucionalizan las prácticas de administración del proyecto Las prácticas técnicas se integran con las prácticas de administración y se institucionalizan El producto y el proceso se controlan cuantitativamente Se institucionaliza la mejora del proceso Nivel Características Proceso Realización prevista Probabilidad Meta Tiempo/$ Probabilidad Tiempo/$ Meta Probabilidad Tiempo/$ Meta Probabilidad Tiempo/$ Meta Probabilidad Tiempo/$ Meta
- 22. Niveles de Madurez Visión de Administración Cajas negras Cajas blancas Cambio tecnologìa Inicial Repetible Definido Gestionado Optimizando El proceso es informal y ad hoc Las prácticas técnicas se integran con las prácticas de administración y se institucionalizan El producto y el proceso se controlan cuantitativamente Se institucionaliza la mejora del proceso Nivel Características Proceso Visibilidad de Administración Entrada Salida Entrada Salida Salida Salida Entrada Entrada Entrada Salida Se institucionalizan las prácticas de administración del proyecto
- 24. Niveles de Madurez Visión de la Tecnología Inicial Repetible Definido Gestionado Optimizando El proceso es informal y ad hoc Se institucionalizan las prácticas de administración del proyecto Las prácticas técnicas se integran con las prácticas de administración y se institucionalizan El producto y el proceso se controlan cuantitativamente Se institucionaliza la mejora del proceso Nivel Características Proceso Implicaciones de la Tecnología La tecnología causa un cambio del proceso, que a su vez origina una nueva búsqueda de tecnología complementaria La organización tiene bases cuantitativas para aplicar la tecnología La organización tiene un fundamento cualitativo para aplicar la tecnología La tecnología puede ayudar en las tareas establecidas La introducción de tecnología nueva es arriesgada
- 29. Niveles de Madurez Visión de las Personas Inicial Repetible Definido Gestionado Optimizando El proceso es informal y ad hoc Se institucionalizan las prácticas de administración del proceso Las prácticas técnicas se integran con las prácticas de administración y se institucionalizan El producto y el proceso se controlan cuantitativamente Se institucionaliza la mejora del proceso Nivel Características Proceso Implicaciones de personas Enfoque en "prevención de fuego"; mejora anticipada y deseada e impactos valorados Sentido de equipo de trabajo e interdependencias Confianza en los procesos definidos; inversión en gente y proceso como valores corporativos Confianza en la experiencia de los buenos profesionales - si ellos funcionan, el proceso también Enfoque de "apaga fuego" eficacia baja- frustración alta
- 31. Principales determinantes del coste, del tiempo, y de la calidad del PRODUCTO PERSONAS PROCESO TECNOLOGIA
- 32. Niveles de Madurez Visión de resultados Inicial Repetible Definido Gestionado Optimizando El proceso es informal y ad hoc Se institucionalizan las prácticas de administración del proyecto Las prácticas técnicas se integran con las prácticas de administración y se institucionalizan El producto y el proceso se controlan cuantitativamente Se institucionaliza la mejora del proceso Nivel Características Proceso R I E S G O C A L I D A D P R O D U C T I V I D A D Resultados
- 33. ESTADO DE LA PRÁCTICA DE LA ADMINISTRACIÓN DE PROYECTOS Administración de Proyectos Tecnológicos
- 35. CICLO DE VIDA DE LA ADMINISTRACIÓN DE PROYECTOS Administración de Proyectos Tecnológicos
- 39. Concept o Especificación Proyecto Estudio Viabilidad Lista de Tareas Plan detallado Estima ciones Análisis de precedencias Plan en red Alisamiento de Cargas Implementación Cierre del Proyecto ¿es aceptable?
- 40. Idea de Proyecto Inicio Proyecto Implementa c i ó n Cierre ¿es aceptable?
- 41. 1.0- Administración de Proyectos ¿es mejor? 1.1 Project Formulation 1.5 Project Closeout Replanning 1.3 Project Startup 1.2 Project Planning 1.4 Project Monitoring & Control GSFC S P I
- 42. 1.1- Proceso Planeación Proyectos Le ayuda a formular su enfoque hacia la administración y a dirigir su esfuerzo en desarrollo de software o mantenimiento. Replanning http://software.gsfc.nasa.gov/isdpaindx.cfm Asset 1.2 Project Formulation Project Closeout Project Startup Project Monitoring & Control Project Planning GSFC S P I
- 43. 1.2- Actividades Planeación de Proyectos Tareas ejecutadas secuencialmente, iterativamente, o en paralelo * * Asegúrese planificar administración de datos e involucración de socios. Revise la consistencia de los planes asociados. http://software.gsfc.nasa.gov/isdpaindx.cfm Asset 1.2 Modify the Software Management Plan/ Product Plan Identify deliverables and dependencies Identify development/acquisition strategy Estimate software project effort, schedule, and cost Identify risks and mitigation strategies Identify personnel and other resources Select and tailor the life-cycle model Produce a Work Breakdown Structure and build/release plan Produce a Software Management Plan/Product Plan GSFC S P I
- 44. 1.4- Proceso Monitoreo y Control de Proyectos Replanning http://software.gsfc.nasa.gov/isdpaindx.cfm Asset 1.4 Muestra como puede valorar el progreso de su proyecto de forma que pueda tomar acciones correctivas cuando la realización se desvía de su plan. Project Formulation Project Closeout Project Planning Project Startup Project Monitoring & Control GSFC S P I
- 45. 1.4- Actividades Monitoreo y Control Tareas ejecutadas cuando es necesario Tareas ejecutadas continuamente * * Monitorizar la administración de datos, involucración de socios, y elementos de riesgo del proyecto software durante la ejecución del proyecto. http://software.gsfc.nasa.gov/isdpaindx.cfm Asset 1.4 Generate management reports and reviews Manage corrective actions Conduct milestone reviews Document lessons learned Monitor software project activities and resources Monitor work products and project data Monitor software acquisition Monitor commitments GSFC S P I
- 46. 2.0- Proceso Administración del Riesgo Le ayuda a minimizar el impacto de los riesgos en coste, calendario, y calidad de los productos de su proyecto software. Replanning Project Monitoring & Control http://software.gsfc.nasa.gov/isdpaindx.cfm Assets 1.2.3 and 1.4.4 Project Formulation Project Closeout Project Startup Project Planning Risk Monitoring & Control Risk Identification GSFC S P I
- 47. 2.0- Actividades Identificación del Riesgo * cuando inicia la identificación de riesgos, establece una estrategia de riesgos e identifica las fuentes y categorías de estos. Tareas ejecutadas secuencialmente o iterativamente* http://software.gsfc.nasa.gov/isdpaindx.cfm Asset 1.2.3 Get Risk Management Plan approval Record risks in Risk Management Database Report risks or enter into Project-level risk tool Identify risks Classify risks Develop mitigation & contingency strategies Create Risk Management Plan
- 48. 3.0- Flujo de Proceso Soporte Organizacional Project Management Product Development Acquisition 3.3 Training 3.4 Measurement & Analysis 3.5 Process Engineering 3.1 Configuration Management 3.2 Software Assurance GSFC S P I
- 49. 4.0- Proceso Administración de la Configuración Ayuda a mantener la integridad de los productos de trabajo. http://software.gsfc.nasa.gov/isdpaindx.cfm Asset 3.1 Work products; change requests Controlled work products; approved change requests Status reports; audit results CM Plan Project Management Processes Project Planning Project Monitoring & Control Project Startup Project Closeout Project Formulation Product Development Processes Requirements Engineering Product Release Sustaining Engineering & Maintenance Design Implementation Testing Systems Engineering Configuration Management Process Planning Data GSFC S P I
Editor's Notes
- Si se pregunta a algunas personas, ¿ qué es el desarrollo informático ? Dirán que aplicar una única herramienta o método. Si se le pregunta a un hacker (dice el libro), bueno creo que a cualquier persona que se dedique sólo a codificar “podrá decir” que es codificar 36 horas de un tirón. (eso además de desarrollar rápido y sin descanso debe ser agotador. Debe salir uno como un zombi). Para un ingeniero de sistemas de información dirá que es RAD. El RAD, según el libro, es una combinación de heramienta CASE, la participación intensiva del usuario y ventanas estrictas. Si lo hacemos con un programador de mercado, dirá que es usar prototipado rápido con la última versión de Microsoft Visual Basic o Delphi. Y finalmente para un directivo desesperado por acortar la planificación será cualquier método recomendado en el último número de Business Week . (o en la Actualidad Económica para decir una revista española). Sin embargo, todos estos métodos no constituyen el desarrollo informático, únicamente ayudarán a incrementar la velocidad de desarrollo, aunque para llevar a cabo un desarrollo rápido realmente necesitaremos que todo esté coordinado por una estrategia global. Otro asunto que hay que comentar es que ninguna de estas técnicas o métodos se podrán aplicar en todos los casos y por tanto no podremos compararlas y decir cuál es mejor o peor, ni compararlas con otras técnicas que no suelen considerarse como de desarrollo rápido, pero que influyen en la velocidad.
- Cuando uno desarrolla un producto software, el responsable del producto puede decirle: “Quiero desarrollar un producto preparado para un cambio”. Le preocupa la Calidad, quiere evitar el crecimiento de las prestaciones, controlar la planificación y tener una fecha de entrega predecible. Todo muy bonito. Pero cuando llega la hora de desarrollar...... ¿Qué es lo único que le importa? ¡Entregar el producto a tiempo! ¿Qué ha pasado con la usabilidad? ¡No hay tiempo! ¿Y el rendimiento? ¡Eso puede esperar! ¿Y realizaremos una verificación para comprobar que cumple con los requisitos? ¡ A los usuarios sólo les importa que el producto esté a tiempo! Todos esos buenos deseos y prediposiciones se han ido, se las ha llevado el viento. Pero esta situación no es de un responsable de un producto en particular, puede ser de cualquiera; ya que este comportamiento se repite todos dos días y en todos los países. El tiempo de desarrollo les ha cegado. ¡Es una obsesión! Es como tener una venda que impide tener en cuenta otros aspectos que algunas al final podrán afectar al tiempo de desarrollo.
- Alguna persona podría decir de la anterior transparencia, “esas son direcciones y no dimensiones”. Tendrá razón, pero hasta ahora y a no ser que alguien me enseñe cómo, ¿algún voluntario? , es imposible dibujar en cuatro dimensiones. Y este es el problema, los libros de desarrollo software suelen enfatizar que estas dimensiones son en realidad direcciones y es necesario centrarse en una y renunciar a las demás. Esa no es la respuesta. Puesto que son dimensiones es posible centrarse en las cuatro. Las organizaciones software suelen a ver las dimensiones que no usan como valores fijo y ésta es una de las razones por la que la planificación temporal puede resultar tan frustrante. Si uno se centra en una sola dimensión no puede satisfacer a todo el mundo. El aprender cada una de las cuatro dimensiones anteriormente mencionadas puede suponernos una gran ventaja para la planificación del software llegándose a ser ésta más creativa, completa, efectiva y satisfactoria. En las siguientes transparencias se tratarán cada una de las cuatro dimensiones. **Anterior comentario es del libro McConnel Rapid Development.**
- El Proceso es lo que se hace (los pasos que siguen las personas, los proyectos o las organizaciones) para desarrollar y mantener software. Un acuerdo y entendimiento general acerca del proceso actual permite a los grupos de profesionales y técnicos trabajar en equipo . Los procesos escritos deben contener como mínimo lo siguiente: Criterio Inicial: ¿Cuáles son las condiciones previas para empezar el proceso?. Descripción del Trabajo: ¿Cuáles son los pasos a seguir para completar el trabajo?. Tenga en cuenta que alguno de esos pasos serán descritos en definiciones de procesos diferentes. Criterio de Validación: ¿Cómo se va a determinar la validz del trabajo?. Normalmente en este apartado se citan los estándares a aplicar, la adherencia anormas operativas, etc. Criterio Final: ¿Cuáles son las condiciones finales para el proceso?. ¿Qué debe ser cierto para considerar que el trabajo está completol?. ¿Cómo ha cambiado el “mundo” como resultado de completar el proceso con éxito?. En cada nivel jerárquico cada definición de proceso (ejemplo, a nivel Organizativo o del Proyecto) debe tener en cuenta a las PERSONAS, las HERRAMIENTAS y a los PROCEDIMIENTOS.
- El proceso incluye tantas metodologías de administración como metodologías técnicas. El efecto del proceso en el plan de desarrollo es más fácil de calcular que el que tiene la gente, y el Software Engineering Institute y otras organizaciones han realizado muchos estudios para documentar y publicar los procesos de software efectivos. Hace diez años era razonable debatir la importancia de centrarse en el proceso , pero hoy en día como pasa con el personal existen un gran numero de evidencias que apoyan la idea de prestar atención al proceso. Algunas grandes empresas como Motorola, NASA o Xerox que durante diez años se han dedicado a mejorar sus procesos de desarrollo han logrado reducir sus plazos de salida de mercado a la mitad y sus costes y errores en un factor de 3 a 10. Para algunas personas piensan que ocuparse en el proceso puede resultar agobiante. Es cierto que algunos procesos son tan rígidos y burocráticos que producen este efecto. Las personas suelen hacer esto para sentirse más poderosos. Las consecuencias aquí nombradas son sólo consecuencia de ese abuso de poder. Sin embargo esto no debe ocultarnos los beneficios que puede traer el centrarse en los procesos.
- En una organización software inmadura, los procesos software son generalmente improvisados por los profesionales y su directiva durante el curso del proyecto. Incluso si un proceso software ha sido especificado, éste no suele exigirse ni ponerse en práctica de forma rigurosa. La organización software inmadura es reaccionaria, y los directores están concetrados en resolver las crisis inmediatas (o como suele denominarse, a “apagar fuegos”). Los calendarios y los presupuestos se exceden normalmente porque no etán basados en estimaciones realistas. Cuando se imponen plazos estrictos, la calidad y funcionalidad del producto se comprometen para así cumplir el calendario. En una organización inmadura, no existe una base objetiva para juzgar la calidad del producto o para resolver los problemas del proceso o del producto. Más aún, la calidad del producto es difícil de predecir. Cuando los proyectos no cumplen el calendario previsto, las actividades deedicadas a mejorar la calidad, tales como las revisiones y las pruebas, suelen, a menudo, recortarse o eliminarse. El proceso cambia a menudo -frecuentemente los procesos seguidos por los froyectos no están documentados. Si existen unas definiciones del proceso a nivel del proyecto, éstas no son normalmente seguidas rigurosamente si son obligatorias. La personalidad y fuerza de los JP determina el nivel del proceso que se va a seguir. La entrega del producto depende normalmente de los profesionales. Organizaciones poco maduras entregan productos con calidad pero con gasto de personal enorme y difícil de predecir al no existir un proceso definido. Problemas con el coste y calendario son normales. Funcionalidad y calidad del producto están normalmente en entredicho hasta el último momento para cumplir los plazos de entrega. Esto normalmente no se negocia. La tecnología está presente en todos los niveles, pero si ésta no cumple con las expectativas de los profesionales puede contribuir a generar más errores.
- Comprendido - se consigue una formación efectiva en toda la organización. Se utiliza - el parte del trabajo diario de los desarrolladores. Vivo - surgen ideas para su mejora al tiempo que se usa. Medido - se conocen las efectividades de los procesos. La tecnología complementa el proceso y aumenta la capacidad de los desarrolladores de software. Una organización software madura posee una capacidad, a nivel de organización, para gestionar los procesos de desarrollo y mantenimiento del software. El proceso software se comunica de una forma precisa, tanto a los empleados actuales como a los nuevos, y las actividades de trabajo se llevan a cabo de acuerdo con el proceso planificado. Los procesos asignados están listos para su utilización y son consistentes con la forma en que se está realizando realmente el trabajo. Estos procesos definidos se actualizan cada vez que es necesario, y se desarrollan lasmejoras a través de pruebas piloto controladas y/o análisis coste/beneficio. Los papeles y responsabilidades dentro del proceso definido son claros a lo largo de todo el proyecto y de toda la organización. En una organización madura, los directores controlan la calidad de los productos software y la satisfacción del cliente. Existe una base objetiva y cuantitativa para juzgar la calidad del producto y para analizar los problemas inherentes al producto y al proceso. Los calendarios y los presupuestos se basan en resultados históricos y son realistas; los resultados esperados en costes, calendario, funcionalidad y calidad del producto normalmente se alcanzan. En general, un proceso disciplinado implica un seguimiento continuo, porque todos los participantes comprenden el valor que supone hacerlo así, y porque existe la infraestructura necesaria para soportar el proceso.
- NIVEL 1: El proceso software se caracteriza como ad hoc, y ocasionalmente hasta caótico. Hay pocos procesos definidos y el éxito depende del esfuerzo individual. NIVEL 2: Se han establecido unos procesos básicos de administración del proyecto para efectuar unos seguimientos de los costes, del calendario y de la funcionalidad. Se dispone de la disciplina de proceso necesaria para repetir éxitos anteriores en proyectos con aplicaciones similares. RM: acuerdo con el cliente sobre los requisitos; PP: planes razonables; PTO: seguimiento; SQA: dar visión del proceso software utilizado en los proyectos; GCS: mantener la integridad del proceso y de los productos. NIVEL 3: El proceso software, tanto en lo que se refiere a las actividades de administración como a las de ingeriría, está documentado, normalizado e integrado, constituyendo el proceso software estándar de la organización. Todos los proyectos utilizan una versión aprobada y adaptada del proceso software estándar de la organización para el desarrollo y mantenimiento del software. PF: SEPG; PD: establecer el proceso estándar de la organización; IPS: establece la ingeniería del ciclo de vida (marcando las restricciones técnicas); PR: revisiones pares; IMS: administración integrada del software - Adaptar el proceso de la organización, escoger ciclos de vida, métodos y herramientas para definir el proceso a nivel proyecto. Además los criterios de administración a la ingeniería elegida. IGC: planificar el proyecto coordinando todos los grupos de ingeniería tales como ingeniería de sistemas; TP: Programa de entrenamiento. NIVEL 4: Se recopilan las medidas detalladas del proceso software y de la calidad del producto. Tanto el pr4oceso software como los productos se comprenden y controlan cuantitativamente. QM: administración de calidad. Definir objetivos de calidad y planes para alcanzarlos; QMP : administración cuantitativa del proceso. Establecer objetivos de rendimiento y medirlo. Analizar las medidas y hacer ajustes para mantener el rendimiento dentro de límites aceptables. Predecir actividades posteriores del ciclo de vida. NIVEL 5: Es posible una mejora continua del proceso mediante la realimentación cuantitativa del propio proceso y mediante la experimentación de ideas y tecnologías innovadoras. DP: Prevención de defectos (estadística). administración del cambio en todos los afectados; administración de la innovación tecnológica.
- La madurez del proceso software de una organización ayuda a predecir la capacidad de un proyecto para satisfacer sus objetivos. Los proyectos de las organizaciones del Nivel 1 experimentan amplias variaciones para lograr los objetivos de costes, plazo, funcionalidad y calidad. Como se puede ver en la Figura se observan tres mejoras a la hora de cumplir los objetivos previstos, a medida que el proceso software de la organización madura. Primero, a medida que la madurez aumenta, la diferencia entre los resultados previstos y los resultados reales de los proyectos disminuye. Por ejemplo, si se ha previsto entregar diez proyecto del mismo tamaño el 1 de Mayo, entonces la fecha medida de su entrega se acercaría más al 1 de Mayo a medida que la organización madura. Las organizaciones del Nivel 1 suelen no cumplir sus fechas de entrega previstas originalmente en un amplio margen, mientras las organizaciones del Nivel 5 deberían ser capaces de cumplir con las fechas previstas con una considerable exactitud. Esto se debe a que las organizaciones del Nivel 5 utilizan un proceso software construido cuidadosamente que funciona con parámetros conocidos, y la selección de la fecha prevista se basa en la amplica cantidad de datos que poseen sobre su proceso y en su rendimiento cuando se aplican a dichos datos. (Esto se ilustra en la Figura en función de la superficie situado bajo la curva que queda a la derecha de la línea que representa los objetivos previstos). Segundo, a medida que la madurez aumenta, la variabilidad de los resultados reales sobre los resultados previstos disminuye. Por ejemplo, en las organizaciones del Nivel 1 las fechas de entrega para proyectos de tamaño similar son impredecibles y varían ampliamente. Proyectos similares en una organización del Nivel 5, se entregarán, sin embargo, en un rango temporal mucho menor. Esta reducción de la variación aparece en los niveles de madurez más altos, porque virtualmente todos los proyectos se están realizando con parámetros controlados que combinan la capacidad del proceso de la organización en relación con los costes, plazos, funcionalidad y calidad. (Esto se ilustra en la Figura mediante la cantidad de superficie situada bajo la curva que se concentra cerca de la línea del objetivo).
- En el Nivel 3, la estructura interna de las cajas, es decir, las tareas del proceso software definido para el proyecto, es visible. La estructura interna representa la forma en que ha sido aplicado el proceso software estándar de la organización a proyectos específicos. Tanto los directores como los ingenieros comprenden sus respectivos papeles y responsabilidades en el proceso y cómo interactúan sus actividades al nivel de detalle apropiado. La dirección se prepara de forma activa ante los riesgos que puedan aparecer. Los individuos externos al proyecto pueden obtener actualizaciones del estado precisas y rápidas porque los procesos definidos permiten una gran visibilidad de las actividdes del proyecto. En el Nivel 4, los procesos software definidos están instrumentados y controlados cuantitativamente. Los directores son capaces de medir el progreso y los problemas. Tienen una base objetiva y cuantitativa para la toma de decisiones. Su capacidad para predecir resultados crece de una forma más precisa, a medida que la variabilidd en el proceso es menor. En el Nivel 5, se intentan continuamente nuevas y mejoradas formas de construir software, de una forma controlada, para mejorar la productividad y la calidad. El cambio disciplinado es una forma de vida, a medida que las actividades ineficaces o con tendencia al defecto se identifican y se reemplezan o revisan. La visión se extiende más allá de los procesos existentes hacia los efectos de los cambios potenciales de los procesos. Los directores son capaces de estimar y seguir cuantitativamente el impacto y la eficacia del cambio.
- En la historia del desarrollo software uno de los cambios con mayor influencia fue el paso de lenguajes de bajo nivel como el ensamblador a lenguajes de alto nivel como el C o el PASCAL. En la actualidad la tendencia hacia componentes VBX y OCX puede producir el mismo efecto.
- Las investigaciones sobre la influencia del personal han sido numerosas (peopleware). Es posible que alguien conozca la tesis de que la diferencia de productividad entre diferentes informáticos es de 10 a 1. O la influencia de la motivación. Pero en lo que puede que no estén familiarizados es que estas investigaciones han demostrado, como dice la primera línea, es que los temas relacionados con el personal tienen un mayor impacto que el pensado sobre la productividad y sobre la calidad del producto . (diferencia en la productividad de 10 a 1 para programadores con similar grado de experiencia). En general la variabilidad de la productividad (conocida con seguridad) a partir de la experiencia es: Mayores de 10 a 1 entre individuos con diferencias en la diversidad y profundidad de su experiencia. De 10 a 1 entre individuos con los mismos niveles de experiencia. De 5 a 1 entre grupos con diferentes niveles de experiencia. De 2,5 a 1 entre grupos con niveles de experiencia similares. Otros estudios han descubierto variaciones en la eficiencia de 3, 4 ó 5 a 1. Incluso los investigadores de la NASA (con la tecnología tan avanzada que dispone este organismo) se han dado cuenta, como dice la segunda línea, que la tecnología no es lo importante , los métodos más efectivos son los que sacan el mejor provecho al potencial humano. Una vez que ha quedado claro la influencia del personal en la productividad es necesario destacar los factores de la primera línea como factores a tener en cuenta en una organización si está interesada en el buen desarrollo de proyectos informáticos. Estos resultados anteriormente mencionados son contundentes, pero no deben tomarse como base para una iniciativa sobre personal. Estos resultados sólo indican que los temas relacionados con el personal influyen en la productividad, pero no son los únicos (repartir refrescos gratis, camisetas u oficinas exteriores no es la solución a los problemas).
- Barry Boehm en su libro “Software Engineering Economics” presenta cinco principios para la selección del personal. Máximo talento significa usar poco y buen personal. Trabajo adecuado significa asignar tareas según la habilidad y motivación de la gente disponible. Progresión profesional significa ayudar a la gente a actualizarse por si misma en vez de obligarles a trabajar donde más experiencia tengan o donde sean más necesarios. Equilibrado del equipo significa seleccionar a gente que se complemente y amortice con los demás. Y eliminar la inadaptación significa eliminar y reemplazar a los miembros problemáticos del equipo lo antes posible. Estos principios expuestos por Barry Boehm no son los únicos. Otros factores que pueden influir en la selección son la habilidad de diseño, la habilidad de programar, la experiencia en el entorno y en la máquina y la experiencia en el área de aplicación.
- Las empresas de software sacan partido a la estructura de sus equipos para que concuerden con el tamaño del proyecto, las características del producto y los objetivos de planificación. Como dice en la segunda línea un proyecto software específico también puede sacar partido de la especialización apropiada . Como ya puede ser conocido la motivación es un factor muy importante en la productividad.La motivación es el único factor que provocará que una persona renuncie a las tardes y los fines de semana sin que se le pida. En general existen pocos factores que puedan aplicarse a tantas personas dentro de tantos equipos en tantas empresas, siendo la motivación el aliado más fuerte para la empresa. Dedicaremos una Unidad Didáctica a la administración de Equipos
- Es obvio que la dimensión más tangible en el cuarteto de dimensiones es el producto, por lo que ocuparnos del tamaño y características nos proporcionará enormes oportunidades para reducir la planificación. Cuanto más consigamos reducir el número de prestaciones que debe tener el producto más conseguiremos reducir el plan de desarrollo. Por lo que como dice la transparencia si conseguimos que las prestaciones relativas al aspecto, rendimiento o de calidad sean flexibles conseguiremos reducir el tiempo de desarrollo. Pero no siempre es posible reducir todo lo que uno quiere, todo depende de lo que podamos convencer al cliente y de la creatividad del equipo para reutilizar componentes ya desarrollados.
- Actualmente se enfatiza mucho en la Mejora de Procesos. En la década anterior, el énfasis estaba en las herramientas y en la tecnología. La focalización en el proceso no quiere decir que las herramientas y la tecnología no sean importantes o que con un buen proceso y buenas herramientas no se necesitan buenos profesionales. El mensaje es que el énfasis adecuado debe ponerse en las tres áreas: de personas, del proceso y de la tecnología. Este concepto se puede representar con unos pocos ejemplos: Un taburete de tres patas - si se corta por la mita una de las tres patas, el taburete dejará de ser estable para poderse sentar. Si se ve la figura superior como un triángulo unido por alfileres - entonces si se quita la estructura se colapsa. Si se somete a mucha presión a uno de los alfileres la estructura se puede deformar o se vuelve inestable. Se debe esperar que un cambio a cualquiera de los tres requiera cambios apropiados en los otros para mantener el equilibrio deseado. Viendo la estructura como un triángulo, se debe observar que la base del triángulo está compuesta por el proceso y la tecnología, base que sostiene el vértice del triángulo que son las personas. El proceso y la tecnología utilizados por una organización debe apoyar al activo más importante que posee la propia organización - Las Personas - de tal manera que sean lo más creativas y productivas que se pueda. Para cualquier empresa, se precisan tres elementos: PERSONAS, PROCESO Y TECNOLOGÍA. Sin personas para llevar a cabo los pasos del proceso y para utilizar las herramientas y tecnología, no habrá ningún resultado, ya sea un producto software o un partido de fútbol. (Para un proceso manufacturado también necesitaríamos materiales). El CMM se centra en el aspecto de proceso de la tríada. La tecnología y las personas son igualmente importantes (no existe ningún producto sin ellos). Pero la tecnología cambia a su propio ritmo a lo largo del tiempo y el factor humano se ha tratado por disciplinas como el desarrollo organizativo y la administración de la Calidad Total (TQM) y por un modelo de madurez de los recursos humanos que está desarrollando el SEI. En cuanto al tercer elemento de la tríada, los problemas principales presentados por los productos software (que se entregan tarde, son demasiado costosos, imperfectos, prometidos pero nunca entregados, no fiables, etc.) parecen ser, en gran parte, debidos a cuestiones del proceso. La resolución de los problemas del proceso parece ser el punto de mayor influencia en el triángulo, al menos así ha sido en las décadas de los ochenta y los noventa.
- Pero todas herramientas o métodos de planificación anteriormente mencionados no son el desarrollo rápido. Como dice la transparencia ayudarán a incrementar la velocidad de desarrollo. Pero realmente y como ya veremos más adelante para conseguir un desarrollo rápido necesitaremos que todo esté coordinado por una estrategia global. Otro asunto que ha que comentar es que ninguna de estas técnicas o métodos se podrán aplicar en todos los casos y por tanto no podremos compararlas y decir cuál es mejor o peor, ni compararlas con otras técnicas que no suelen considerarse como de desarrollo rápido, pero que influyen en la velocidad Pero el desarrollo rápido no es más que una frase descriptiva. Como dice la transparencia, lo opuesto a un desarrollo lento. El desarrollo rápido no es ninguna frase o palabra mágica. Tampoco una metodología de desarrollo rápido Braze-O-Matic o Gung-HO-OO. Como se dice desarrollo rápido es un término genérico que significa desarrollo veloz, es decir, desarrollar software a una velocidad superior a la alcanzada en este momento . Por lo que un proyecto de desarrollo rápido es cualquier proyecto en el que se necesite mejorar la velocidad de desarrollo. .
- Como aparece en esta transparencia, en el desarrollo rápido existe dos caminos o rutas. Una, como en las películas, es la más concurrida que conlleva todos los problemas que aparecen. La otra, la menos transitada, ya que parece la más arriesgada (como en las películas) es la que propone todas esas ventajas que se observan en la transparencia. ¿Entonces por qué las empresas eligen la que les trae más problemas en lugar de elegir la que les trae más ventajas ? Como siempre la solución es sencilla. El camino propuesto requiere tiempo y esfuerzo. No produce una mejora instantánea y no basta con coger una única y nueva herramienta o método de la estantería. El camino no es fácil. Los problemas fáciles se resuelven con soluciones fáciles, y el desarrollo de software no es un problema fácil. “ Para todo problema complejo hay una respuesta corta, simple y errónea”. H.L. Mencken A mi me gustaría ganar cinco millones de pesetas fácilmente, pero no conozco el camino (de una manera honrada). Si alguien conoce el camino que me lo diga ...
- Por encima y de una manera general, el éxito en el desarrollo de un proyecto informático requiere, como dice la transparencia, dos cosas: - Seleccionar métodos eficaces . Cosa que no es fácil ya que el conjunto de todos los métodos disponibles para el desarrollo software es inmenso. - Seleccionar los métodos orientados a la planificación que sirvan para el proyecto que se esté desarrollando. Puede que esto resulte obvio, pero no lo es y las empresas suelen elegir siempre los métodos ineficaces o que fallan más de la cuenta. Por ejemplo, cuando necesitan certeza en los plazos eligen prácticas de alto riesgo que reducen la posibilidad de cumplir con la fecha fijada, cuando es necesario reducir costes, eligen métodos orientados a la velocidad que aumentan los costes, es decir, todo al revés. El primer paso en estas empresas, como cuando uno comete un error, es admitir que se ha elegido mal y a partir de ahí empezar a elegir los métodos más eficaces. Por tanto, uniendo métodos efectivos orientados a planificación con un plan para usarlos se conseguirá obtener mejoras drásticas y reales en la velocidad de desarrollo, siendo esta “receta” mejor que usar un software “elixir” Habichuelas-Mágicas, que no funciona. Los métodos que mejoran la velocidad de desarrollo ayudarán a entregar antes el software. Deberá seleccionarlos si el problema es la velocidad desarrollo eligiendo los mejor se adapten según los problemas que se tengan. Si la velocidad de desarrollo es correcta, y el problema radica en el cumplimiento de los plazos, los métodos a elegir son los que reducen el riesgo en la planificación. Finalmente, si la velocidad de desarrollo es correcta y el problema es la impresión del cliente de que el proyecto va lento, el tipo de métodos a elegir son los que hacen visible el progreso.
- During first 6 tasks you are building the WBS. Then document it. Management data is all that process, management and project stuff. Consistency must be across plans (Mission Project, your CM Plan, your Risk Plan, your schedules, etc.)
- In managing corrective actions, ask Why? Impact? Actions? Get better? Manage corrective actions until no issues remain In management reporting, refer to Branch Bimonthly Status Report This is a good source of lessons learned
- Risk Strategy – How you’ll manage risk … frequency of review, who is responsible, how you’ll categorize risks, etc Example risk categories: Application, Management, Technology, Process, Productivity Example risk sources: cost and schedule constraints, staffing, complexity, interfaces, vendors and subcontractors Classify risks – Estimate impact and likelihood. Use those to compute exposure In last box, Project-level risk tool is Mission Project tool, if applicable
- Uses Configuration Identification Configuration control Status acting Configuration Audits
- Implementation – The SAP Solution Manager gives you access to the tools, content, and methodology you need to implement and optimize your SAP solutions - from both a functional perspective and a technical perspective. Monitoring – The SAP Solution Manager helps you meet the performance and availability expectations with solution monitoring which monitors the entire business process across multiple components. The following monitoring functions are available: SAP EarlyWatch Alert, system monitoring, interface monitoring and business process monitoring, service level reporting. Operations – The operations area of the SAP Solution Manager is access to SAP Support Services, including remote services, on-site services, self-services, and best practice documents. Based on your solution configuration, recommendations for these services are triggered dynamically. Support – The support area of the SAP Solution Manager offers a complete infrastructure for organizing and operating a solution-wide support organization at your site. This promotes effective user support in your SAP solution landscape every step of the way - from the end-users to your internal support organization and, when necessary, to SAP. Project Administration/Project Definition supports you initially in setting-up your project during project preparation and enables you to carry out major administrative tasks such as the definition of project standards during the entire project. In the SAP Solution Manager, you can centrally define and manage your System Landscape centrally relevant for your implementation or template projects which allows the interaction and navigation into a related system landscape, for example during configuration and testing. The definition and documentation of your project scope in Business Blueprint is accelerated through the Business Process Repository providing latest available implementation content and the integrated use of the underlying SAP Knowledge Warehouse. The purpose of the Business Blueprint is to document in detail the scope of business scenarios, business processes and process steps of your implementation project from a business and technical perspective. During Configuration , you have to configure the business requirements specified in the Business Blueprint phase in the related system landscape. The SAP Solution Manager as central platform for your project team provides the access to the related Project Implementation Guides (IMGs) and integrated use of other customizing technologies such as Business Configuration Sets (BC Sets) and customizing distribution. The Customizing Distribution used with the SAP Solution Manager helps to centrally control customizing changes across the related system landscape of your implementation project. Testing functions support test coordinators to centrally create test cases and test plans reflecting sequence and integration tests. Testers can centrally execute their test packages, also leveraging existing test technologies for automated testing such as CATT and eCATT. The latest available Roadmaps representing the standard SAP implementation methodologies are provided through the SAP Solution Manager. With the SAP Solution Manager, you can track status, issues and/or upload your project-specific accelerators along the work packages and tasks of your implementation project.