presione acá abajo ing. chapela
aca le dejo el link para que cheque la documentacion profe.
miércoles, 12 de diciembre de 2018
miércoles, 26 de septiembre de 2018
2.1 La gestión de proyectos usando un marco de calidad
2.1 La gestión de proyectos usando un marco de calidad
La calidad del software es un concepto complejo que no es directamente comparable con la calidad de la manufactura de productos.
En la manufacturación, la noción de calidad viene dada por la similitud entre el producto desarrollado y su especificación. En un mundo ideal, esta definición debería aplicarse a todos los productos, pero, para sistemas de software, existen estos problemas:
1. La especificación se orienta hacia las características del producto que el consumidor quiere. Sin embargo, la organización des arrolladora también tiene requerimientos (como los de mantenimiento) que no se incluyen en la especificación.
2. No se sabe cómo especificar ciertas características de calidad (por ejemplo, mantenimiento) de una forma no ambigua.
3. Es muy difícil redactar especificaciones concretas de software. Por lo tanto, aunque un producto se ajuste a su especificación, los usuarios no lo consideran un producto de alta calidad debido a que no responde a sus expectativas.
4.Se deben reconocer estos problemas con la especificación del software y se tienen que diseñar procedimientos de calidad que no se basen en una especificación perfecta. En concreto,
atributos del software como mantenibilidad, seguridad o eficiencia no pueden ser especificados implícitamente. Sin embargo, tienen un efecto importante en cómo es percibida la calidad del
sistema.
Algunas personas piensan que la calidad puede lograrse definiendo estándares y procedimientos organizacionales de calidad que comprueban si estos estándares son seguidos por el equipo
de desarrollo. Su argumento es que los estándares deben encapsular las buenas prácticas, las cuales nos llevan inevitablemente a productos de alta calidad. En la práctica, sin embargo,
es más importante la gestión de la calidad que los estándares y la burocracia asociada para asegurar el seguimiento de estos estándares.
Los buenos gestores aspiran a desarrollar una «cultura de la calidad» donde todos seamos responsables de que el desarrollo del producto sea llevado a cabo obteniendo un alto nivel de
calidad en éste. Mientras estándares y procedimientos son las bases de la gestión de la calidad, los gestores de calidad experimentados reconocen que hay aspectos intangibles en la
calidad del software (elegancia, legibilidad, etc.) que no puede ser incorporada en los estándares.
Ellos ayudan a la gente interesada en estos aspectos intangibles de calidad y fomentan
comportamientos profesionales en todos los miembros del equipo.
La gestión formal de la calidad es particularmente importante para equipos que desarrollan sistemas grandes y complejos. La documentación de la calidad es un registro de que es hecho por cada subgrupo en el proyecto.
Esto ayuda a la gente a ver qué tareas importantes no deben ser olvidadas o que una parte del equipo no haga suposiciones incorrectas acerca de lo que otros miembros han hecho.
La documentación de calidad es también un medio de comunicación sobre el ciclo de vida de un sistema. Ésta permite al grupo responsabilizarse de la evolución del sistema para saber qué
ha hecho el equipo de desarrollo.
Para sistemas pequeños, la gestión de calidad es importante todavía, pero se debe adoptar una aproximación más informal. No son tan necesarios los documentos porque el grupo puede comunicarse informalmente.
La clave de la calidad en el desarrollo de sistemas pequeños es el establecimiento de cultura de calidad y asegurarse de que todos los miembros del equipo hacen una aproximación positiva
a la calidad del software.
La gestión de calidad del software se estructura en tres actividades principales:
• Garantía de la calidad. El establecimiento de un marco de trabajo de procedimientos y estándares organizacionales que conduce a software de alta calidad.
• Planificación de la calidad. La selección de procedimientos y estándares adecuados a partir de este marco de trabajo y la adaptación de éstos para un proyecto software específico.
• Control de la calidad. La definición y fomento de los procesos que garanticen que los procedimientos y estándares para la calidad del proyecto son seguidos por el equipo de
• desarrollo de software.
La gestión de la calidad provee una comprobación independiente de los procesos de desarrollo software.
Los procesos de gestión de la calidad comprueban las entregas del proyecto para asegurarse que concuerdan con los estándares y metas organizacionales.
El equipo de garantía de calidad debe ser independiente del equipo de desarrollo para que puedan tener una visión objetiva del software. Ellos transmitirán los problemas y las dificultades al gestor principal de la organización.
Un equipo independiente de calidad garantiza que los objetivos organizacionales y la calidad no sean comprometidos por consideraciones de presupuesto o agenda. Una suposición subyacente de la gestión de calidad es que la calidad del proceso de desarrollo afecta directamente a la calidad de los productos.
Hay un vínculo claro entre la calidad del proceso y del producto en producción debido a que el proceso es relativamente fácil de estandarizar y monitorizar.
El software no se manufactura, sino que se diseña. El desarrollo de software es un proceso más creativo que mecánico.
La calidad del producto, también se ve afectada por factores externos, como la novedad de una aplicación o la presión comercial para sacar un producto rápidamente.
La calidad del producto, también se ve afectada por factores externos, como la novedad de una aplicación o la presión comercial para sacar un producto rápidamente.
En el desarrollo software, por lo tanto, la relación entre la calidad del proceso y la calidad del producto es muy compleja.
Es difícil de medir los atributos de la calidad del software, en consecuencia, es difícil explicar cómo influyen las características del proceso en estos atributos. Además debido al papel del diseño y la creatividad en el proceso software, no podremos predecir la influencia de los cambios en el proceso en la calidad del producto.
La calidad del proceso tiene una influencia significativa en la calidad del software. La gestión y mejora de la calidad del proceso debe minimizar los defectos en el software entregado.
• Definir estándares de proceso.
• Supervisar el proceso de desarrollo para asegurar que se sigan los estándares.
• Hacer informes del proceso para el gestor del proyecto y para el comprador del software.
Un problema de la garantía de la calidad basada en el proceso es que el equipo de garantía de la calidad (QA) insista en unos estándares de proceso independientemente del tipo de software a desarrollar.
El gestor principal debe intervenir para asegurar que el proceso de calidad ayude al desarrollo del producto en lugar de impedirlo.
2.2 Estándares y Métricas de calidad en la ingeniería de SW MEDICIÓN Y MÉTRICAS DEL SOFTWARE
Sería posible acelerar el proceso de revisión utilizando herramientas que procesaran el diseño del software o el programa, e hiciesen valoraciones automáticas de la calidad del software.
Estas valoraciones permiten comprobar que el software tiene el umbral de calidad requerido, y destacar las partes en las cuales no se ha alcanzado para revisarlas.
La medición del software se refiere a derivar un valor numérico desde algún atributo del software o del proceso software.
Comparando estos valores entre sí y con los estándares aplicados en la organización, es posible sacar conclusiones de la calidad del software o de los procesos para desarrollarlo.
Las mediciones del software pueden utilizarse para:
• Hacer predicciones generales acerca del sistema.
• Identificar componentes anómalos.
Una métrica de software es cualquier tipo de medida relacionada con un sistema, proceso o documentación de software. Algunos ejemplos son las medidas que se utilizan para calcular el tamaño de un producto en líneas de código; el índice de Fig., que mide la claridad de un párrafo en un texto; el número de fallos encontrados en un producto software entregado; y el número de
personas/día requeridas para desarrollar un componente del sistema.
LAS MÉTRICAS SON DE CONTROL O DE PREDICCIÓN.
Las métricas de control suelen estar asociadas con los procesos, mientras que las métricas de predicción lo están a los productos.
Ejemplos de las métricas de control o de procesos son el esfuerzo y el tiempo promedio requeridos para reparar los defectos encontrados. Ejemplos de métricas de predicción son la complejidad ciclomática de un módulo, la longitud media de los identificadores de un programa, y el número de atributos y operaciones asociadas con los objetos de un diseño.
Frecuentemente, es imposible medir los atributos de calidad del software directamente. Los atributos de calidad como la mantenibilidad, la comprensión y la usabilidad son atributos externos que nos dicen cómo ven el software los desarrolladores y los usuarios.
Éstos se ven afectados por diversos factores y no existe un camino simple para medirlos. Más bien es necesario medir atributos internos del software (como su tamaño) y suponer que existe una relación entre lo que queremos medir y lo que queremos saber.
Para que la medida del atributo interno sea un indicador útil de la característica externa, se deben cumplir tres condiciones:
• El atributo interno debe medirse de forma precisa
• Debe existir una relación entre lo que se puede medir y el atributo de comportamiento externo.
• Esta relación se comprende, ha sido validada y se puede expresar en términos de una fórmula o
modelo.
Las métricas del producto se dividen en dos clases:
• Las métricas dinámicas, que son recogidas por las mediciones hechas en un programa en ejecución.
• Las métricas estáticas, que son recogidas por las mediciones hechas en las representaciones del
sistema como el diseño, el programa o la documentación. Las métricas dinámicas ayudan a valorar la eficiencia y la fiabilidad de un programa y por lo general están relacionadas de forma cercana con los atributos de calidad del software. Las métricas estáticas ayudan avalorar la complejidad, la comprensión y la mantenibilidad de un sistema de software; por lo general están relacionadas de forma cercana con los atributos de calidad del software.
Uno de los problemas con la recogida de datos cuantitativos en el software y en los proyectos de software es comprender lo que significan realmente los datos.
Es fácil malinterpretar los datos y hacer inferencias incorrectas. Las mediciones se deben analizar
cuidadosamente para comprender lo que realmente significan.
Los procesos y productos para medir no están aislados de su entorno y los cambios en ese entorno invalidan las comparaciones de los datos.
Los datos cuantitativos de las actividades humanas no siempre pueden tomar se como valores de entrada.
PUNTOS CLAVE
• La gestión de la calidad del software permite señalar si éste tiene un escaso número de defectos y si alcanza los estándares requeridos de mantenibilidad, fiabilidad, portabilidad, etcétera, las actividades de la gestión de la calidad comprenden la garantía de la calidad que establece los estándares para el desarrollo de software, la planificación de la calidad y el control de la calidad que comprueba el software con respecto a los estándares definidos.
• Un manual de calidad organizacional debe documentar un conjunto de procedimientos de garantía de la calidad. Éste puede basarse en los modelos genéricos sugeridos en los estándares ISO 9000.
• Los estándares de software son importantes para garantizar la calidad puesto que representan una identificación de las «mejores prácticas».
El proceso de control de calidad implica comprobar que el proceso del software y el software a
desarrollar concuerdan con estos estándares.
• Las revisiones de los productos a entregar por el proceso del software incumben a un equipo de personas los cuales comprobarán que se han seguido los estándares de calidad, las revisiones son la técnica más utilizada para valorar la calidad.
2.2.1 PSP y TSP
PSP
Es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la productividad personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para emplearse en organizaciones con modelos de procesos CMMI o ISO 15504. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del libro "An introduction to the Personal Software Process" se dirige ahora a ingenieros juniors.
Se puede considerar como la guía de trabajo personal para ingenieros de software en organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad de procesos que implica la medición cualitativa y mejora de procesos.
Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que tomar. El PSP tiene obsesión por la toma de datos y elaboración de tablas. El PSP se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual.
PSP, es uno de los 3 vértices donde descansa un proceso de mejora que trabaja sobre 3 niveles de la organización, los otros 2 son CMM y TSP.
El PSP amplia el proceso de mejora a la gente que realiza el trabajo de desarrollo de software, concentrándose en las practicas de trabajo de los ingenieros en una forma individual, enseñando como manejar la calidad desde el principio de un producto. PSP son nuestras propias métricas, que permiten estructurar y ordenar nuestro trabajo del día a día (no solo de desarrollo de software, esto lo voy a explicar mas adelante). El resultado de nuestro trabajo, además puede ser llevado a un trabajo en equipo TSP (Team Process Software), el cual es “comandado” por un sistema de gestión de la configuración y por supuesto, un Jefe de Proyecto quien evalúa los resultados y avances de los miembros del equipo.
TSP
Team Software Process (TSP) es un método de establecimiento y mejora del trabajo en equipo para procesos software.
TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que la organización pueda establecer prácticas de ingeniería avanzadas y así obtener productos eficientes, fiables y de calidad.
Está formado por dos componentes primarios que abarcan distintos aspectos del trabajo en equipo:
• Formación del equipo de trabajo.
• Gestión del equipo de trabajo.
Existen diferentes metodologías para la mejora de procesos, la mayoría de ellas se basa en la mejora de los procesos que dan como resultado un servicio o producto. El TSP busca integrar un equipo que tenga como punto de partida la unificación del mismo, para poder llevar a cabo todos aquellos procedimientos que puedan realizar mejora a los procesos que desarrollan.
El Team Software Process (TSP) es un proceso de desarrollo para equipos de ingenieros basado en CMMI, ayuda a conformar equipos para el desarrollo de software de calidad. TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que la organización pueda establecer prácticas de ingeniería avanzadas y así obtener productos eficientes, fiables y de calidad.
TSP es una solución basada en procesos para resolver problemas de negocio, tales como:
• Predictibilidad de costo y tiempo
• Mejora de productividad
• Ciclos de desarrollo y mejora de calidad de productos.
Características de los grupos eficaces:
• Miembros expertos en papeles de liderazgo y pertenencia.
• Relaciones tranquilas y establecidas entre los miembros.
• Los miembros se sienten atraídos por el grupo y son fieles.
• Los valores y metas del grupo son los de sus integrantes
• Los miembros están motivados por hacer lo que puedan por el grupo.
• La interacción y toma de decisiones tiene lugar en el ambiente adecuado.
• El grupo desea ayudar a cada miembro a adquirir su pleno El grupo desea ayudar a cada miembro a adquirir su pleno potencial.
• Cada miembro acepta con gusto y sin resentimiento las metas y normas establecidas.
• Los miembros se prestan ayuda mutua cuando es necesaria o recomendable.
• Existe una atmósfera de creatividad.
• El grupo conoce el “conformismo constructivo” y se sirve de él.
• Existe gran motivación para iniciar y recibir las comunicaciones.
• Los miembros son flexibles y adaptables en sus metas y actitudes.
• Los miembros se sienten seguros al tomar decisiones que les Los miembros se sienten seguros al tomar decisiones que les parecen apropiadas al entender la filosofía de la operación.
Sus orígenes se deben a las limitaciones que el PSP (Personal Software Process, su antecesor) tenía en el ámbito industrial. PSP resultó muy efectivo para que los ingenieros pudiesen tener el control de su proceso personal mediante la mejora de sus habilidades de estimación y la reducción de los defectos introducidos en los productos sin afectar a su productividad, pero PSP sólo se enfocaba en las fases de desarrollo de software (diseño y pruebas unitarias); la aplicación que lo ingenieros hicieron del PSP dentro de las empresas resulto en prácticas no satisfactorias.
Por tal motivo, Watts Humphrey desarrolló el TSP, el cual consideraba como parte importante, además de lo previsto por el PSP, los requisitos, las pruebas de integración, la documentación y otras actividades típicas en todo proyecto de desarrollo, de igual manera incluía actividades como los roles de equipo, interrelaciones dentro de la organización y la definición de un proceso de equipo para ser utilizado dentro de los procesos existentes en la organización.
• Líder del Equipo: Dirige al equipo, se asegura que todos reporten sus datos de los procesos y completen su trabajo tal y como se planeó. Realiza los reportes semanales del avance del equipo.
• Gestor de desarrollo: Guía al equipo en el diseño y desarrollo del producto.
• Gestor de Planificación: Apoya y guía al equipo en la planificación y seguimiento del trabajo.
• Gestor de Calidad/Proceso: Apoya al equipo en definir sus necesidades acerca del proceso y a establecer y administrar el plan de calidad. Genera estándares para obtener un trabajo uniforme. Modera las inspecciones y revisa cada artefacto generado.
• Administrador de Requerimientos/Soporte: Dirige al equipo en el desarrollo de requerimientos de software y ayuda a dar a conocer la tecnología y en las necesidades de apoyo administrativo.
Administra el plan de configuración
Es necesario que los ingenieros que usan TSP estén formados en PSP. Con TSP, los equipos encuentran y reparan defectos en etapas tempranas del proceso de desarrollo, esto reduce de manera importante el tiempo de pruebas. Esto reduce de manera importante el tiempo de pruebas. Con un testing más corto, el ciclo completo se reduce.
A diferencia de otros métodos, TSP mejora el desempeño tanto de equipos como individuos, es disciplinado y ágil, provee beneficios inmediatos y medibles y acelera las iniciativas de mejora de procesos organizacionales.
En las fases del Ciclo TSP se planea el número de ciclos. Dentro de cada ciclo se realiza:
• Estrategia
• Plan
• Requisitos
• Diseño
• Implementación
• Pruebas
• Postmortem
Los objetivos que tiene el TSP son:
• Maximizar calidad software, minimizar costos.
• Integrar equipos independientes de alto rendimiento que planeen su trabajo, establezcan metas y san sueños de sus procesos y planes.
• Mostrar a los gerentes como monitorear y motivar a sus equipos de trabajo y como ayudarlos a alcanzar su máxima productividad.
• Acelerar la mejora continua de monitoreo.
• Proveer de una guía para e mejoramiento en organizaciones maduras
Sus entornos son:
• CMM- Administración.
• TSP- Equipo Ingenieros.
• PSP-Ingeniero.
2.2.2 CMM
Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización.Fue desarrollado inicialmente para los procesos relativos al software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute).
El SEI es un centro de investigación y desarrollo patrocinado por el Departamento de Defensa de los Estados Unidos de América y gestionado por la Universidad Carnegie-Mellon. "CMM" es una marca registrada del SEI.
EL MODELO CMM
A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de América, desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de software, que se publicó en septiembre de 1987. Este trabajo evolucionó al modelo CMM o SW-CMM (CMM for Software), cuya última versión (v1.1) se publicó en febrero de 1993.
Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser:
• Definidas en un procedimiento documentado
• Provistas (la organización) de los medios y formación necesarios
• Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)
• Medidas
• Verificadas
A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.
• Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los proyectos es impredecible.
• Repetible. En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.
• Definido. Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detallada y un nivel más avanzado de métricas en los procesos. Se implementan técnicas de revisión por pares (peer reviews).
• Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad.
• Optimizado. La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.
Así es como el modelo CMM establece una medida del progreso, conforme al avance en niveles de madurez. Cada nivel a su vez cuenta con un número de áreas de proceso que deben lograrse. El alcanzar estas áreas o estadios se detecta mediante la satisfacción o insatisfacción de varias metas claras y cuantificables. Con la excepción del primer nivel, cada uno de los restantes Niveles de Madurez está compuesto por un cierto número de Áreas Claves de Proceso, conocidas a través de la documentación del CMM por su sigla inglesa: KPA.
Cada KPA identifica un conjunto de actividades y prácticas interrelacionadas, las cuales cuando son realizadas en forma colectiva permiten alcanzar las metas fundamentales del proceso. Las KPAs pueden clasificarse en 3 tipos de proceso:
• Organizacional
• Ingeniería.
Las prácticas que deben ser realizadas por cada Area Clave de Proceso están organizadas en 5 Características Comunes, las cuales constituyen propiedades que indican si la implementación y la institucionalización de un proceso clave es efectivo, repetible y duradero.
Estas 5 características son:
• Compromiso de la realización
• La capacidad de realización
• Las actividades realizadas
• Las mediciones y el análisis
• La verificación de la implementación.
Las organizaciones que utilizan CMM para mejorar sus procesos disponen de una guía útil para orientar sus esfuerzos. Además, el SEI proporciona formación a evaluadores certificados (Lead Assesors) capacitados para evaluar y certificar el nivel CMM en el que se encuentra una organización. Esta certificación es requerida por el Departamento de Defensa de los Estados Unidos, pero también es utilizada por multitud de organizaciones de todo el mundo para valorar a sus subcontratistas de software.
Se considera típico que una organización dedique unos 18 meses para progresar un nivel, aunque algunas consiguen mejorarlo. En cualquier caso requiere un amplio esfuerzo y un compromiso intenso de la dirección.
Como consecuencia, muchas organizaciones que realizan funciones de factoría de software o, en general, outsourcing de procesos de software, adoptan el modelo CMM y se certifican en alguno de sus niveles. Esto explica que uno de los países en el que más organizaciones certificadas exista sea India, donde han florecido las factorías de software que trabajan para clientes estadounidenses y europeos.
A partir de 2001, en que se presentó el modelo CMMI, el SEI ha dejado de desarrollar el SW-CMM, cesando la formación de los evaluadores en diciembre de 2003, quienes dispondrán hasta fin de 2005 para reciclarse al CMMI. Las organizaciones que sigan el modelo SW-CMM podrán continuar haciéndolo, pero ya no podrán ser certificadas a partir de fin de 2005.
2.2.3 MOPROSOFT
Modelo de Procesos para la Industria del Software. Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Desarrollado por la Asociación Mexicana para la Calidad en Ingeniería de Software a través de la Facultad de Ciencias de la Universidad Nacional Autónoma de México (UNAM) y a solicitud de la Secretaría de Economía para obtener una norma mexicana que resulte apropiada a las características de tamaño de la gran mayoría de empresas mexicanas de desarrollo y mantenimiento de software. Moprosoft es el nombre del modelo en la comunidad universitaria y profesional, y la norma técnica a la que da contenido es la NMX-059/01-NYCE-2005 que fue declarada Norma Mexicana el 15 de agosto de 2005 con la publicación de su declaratoria en el Diario oficial de la Federació.
Moprosoft considera que los modelos de evaluación y mejora CMMI e ISO/IEC 15504 no resultan apropiados para empresas pequeñas y medianas de desarrollo y mantenimiento de software. Sobre las áreas de procesos de los niveles 2 y 3 del modelo SW-CMM e inspirándose en el marco de ISO/IEC 15504 se ha desarrollado este modelo.
Criterios empleados
Se han aplicado los siguientes criterios para la elaboración de este modelo de procesos:
• La estructura de procesos resultante debe ser acorde a la estructura generalmente empleada por las organizaciones de la industria del software (alta dirección, gestión y operación)
• La alta dirección tiene un papel importante a través de la planificación estratégica. Debe actuar como promotor del buen funcionamiento de la organización a través de su implicación en la revisión y mejora continua del modelo.
• El modelo considera a la gestión como proveedora de recursos, procesos y proyectos; así como responsable de la vigilancia del cumplimiento de los objetivos estratégicos de la organización.
• El modelo considera a la operación como ejecutora de los proyectos de desarrollo y mantenimiento de software.
• El modelo integra con claridad y consistencia los elementos indispensables para la definición de los procesos y las relaciones entre ellos.
• El modelo integra los elementos para realizar la administración de proyectos desde un sólo proceso.
• El modelo integra los elementos para realizar la ingeniería de productos de software en un único marco que incluya los procesos precisos de soporte (verificación, validación, documentación y control de la documentación).
• El modelo destaca la importancia de la gestión de recursos, con especial relevancia en aquellos que componen el conocimiento de la organización: productos generados por proyectos, datos de los proyectos, mediciones, documentación de procesos y datos cosechados a partir del uso y de las lecciones aprendidas.
• Moprosoft se basa en los modelos de procesos ISO 9001:2000, en las áreas de procesos de los niveles 2 y 3 de CMM-SW: CMM-SW v.1.1., en el marco general ISO/IEC15504 y en prácticas y conceptos de PMBOK Y SWEBOK.
• PROSOFT representa un campo diferente de apoyo a los empresarios de las tecnologías de la información, es un sector diverso para hacer negocios y generar fuentes de empleo dignas”
El Plan Nacional de Desarrollo 2001-2006 plantea el fomento a la industria y el mercado De Tecnologías de la Información (TI) como estrategia para aumentar la competitividad del País. Dado el gran potencial con que cuenta México para desarrollar esta industria, la Secretaría de Economía, en coordinación con organismos empresariales y empresas del Sector, diseñó el PROSOFT.
El Moprosoft se estructura en 3 categorías:
• Categoría de Alta Dirección (DIR): Se establecen los lineamientos para los procesos de la Categoría de Gerencia y se retroalimenta con la información generada por ellos en apoyo a la estrategia de la organización.
• Categoría de Gerencia (GER): Se definen los elementos para el funcionamiento de los procesos de la Categoría de Operación en función de la estrategia de Dirección, recibe y evalúa la información generada por éstos y comunica los resultados a la Categoría de Alta Dirección.
• Categoría de Operación (OPE): Se realizan las actividades de acuerdo a los elementos proporcionados por la Categoría de Gerencia y entrega a ésta la información y productos generados.
2.3 Impacto de la calidad en tiempo, costo y alcance del proyecto
La gestión deja de ser una tarea aislada para constituirse en una herramienta que sirve para ejecutar las acciones necesarias que permitan ordenar, disponer y organizar los recursos de un proyecto, utilizando procedimientos específicos y optimizando la relación entre recursos y resultados.
Objetivos de la gestión: Conocer y hacer el mejor uso posible de los recursos disponibles para satisfacer de manera óptima los objetivos perseguidos, teniendo en cuenta las limitaciones que se puedan presentar.
Niveles de gestión
Las labores de gestión abarcan todos los ámbitos de un proyecto, incluyendo los administrativos e incluso financieros, el alcance y la trascendencia de las acciones que se ejecuten. En este ámbito se destacan los siguientes niveles:
• Gestión del alcance: Comprende las actividades orientadas a garantizar el cumplimiento de las tareas necesarias para lograr los objetivos del proyecto.
• Gestión técnica o de proceso: Incluye las actividades necesarias para garantizar que los resultados del proyecto satisfagan las necesidades y requerimientos de los gestores o inversionistas.
• Gestión del Tiempo: Comprende las actividades necesarias para asegurar que el proyecto se ejecute en el plazo estimado y que los resultados (producción de bienes o servicios) estén a disposición de los clientes o consumidores.
• Gestión de costos: Asegura que las tareas se lleven a cabo dentro de los rangos económicos impuestos (presupuesto del proyecto o recursos asignados para la actividad correspondiente).
• Gestión de calidad: Tiene que ver con las actividades que aseguran que el proyecto satisface los requisitos bajo los cuales deben generarse los resultados
.
• Gestión de los recursos: Para que una empresa cumpla su misión, logre sus objetivos y le entregue resultados favorables a los propietarios, es necesario que cuente con recursos suficientes para que contribuyan a una gestión adecuada incrementando la productividad de la empresa.
• Gestión de la comunicación: Permite garantizar que la información formal e informal, se genere, recopile, almacene y utilice de forma adecuada.
• Gestión de compras y adquisiciones: Cuando el proyecto es de cierta complejidad, se hace necesario definir algunos procedimientos que estén orientados a la correcta selección y obtención de bienes y servicios que deben ser llevados de fuera de la empresa o del proyecto.
ALCANCES
El alcance de un proyecto llamado también alcance del trabajo es el trabajo que debe hacerse para que el cliente se convenza de que las entregas (las cosas por hacer), es decir el producto u objetos tangibles que han de suministrarse) cumplan con los requisitos o criterios de aceptación acordados al comenzar el proyecto. Por ejemplo, el alcance podría ser el trabajo de limpiar el suelo, de construir una casa, poner la jardinería ornamental según las especificaciones hechas por el cliente y aceptadas por el contratista.
• Comprende las actividades orientadas a garantizar el cumplimiento de las tareas necesarias para lograr los objetivos del proyecto.
• La gestión del alcance del proyecto se relaciona principalmente con la definición y el control de lo que está y no está incluido en el proyecto.
En el contexto del proyecto, la palabra alcance puede referirse a lo siguiente:
2. Alcance del proyecto. El trabajo que debe realizarse para entregar un producto, servicio o resultado con las funciones y características especificadas.
PLANIFICACIÓN DEL ALCANCE
El plan de gestión del alcance del proyecto es una herramienta de planificación que describe cómo el equipo definirá el alcance del proyecto, desarrollará el enunciado del alcance del proyecto detallado, definirá y desarrollará la estructura de desglose del trabajo, verificará y controlará el alcance del proyecto.
HERRAMIENTAS Y TÉCNICAS
• Análisis del Producto Técnicas como desglose del producto, análisis de sistemas, ingeniería de sistemas, ingeniería del valor, análisis del valor y análisis funcional.
• Identificación de Alternativas Las más comunes son la tormenta de ideas y el pensamiento lateral.
• Juicio de Expertos
• Análisis de los Interesados Identifica la influencia y los intereses de los diversos interesados y documenta sus necesidades, deseos y expectativas.
VERIFICACIÓN DEL ALCANCE
• La verificación del alcance es el proceso de obtener la aceptación formal por parte de los interesados del alcance del proyecto completado y los productos entregables relacionados.
• Verificar el alcance del proyecto incluye revisar los productos entregables para asegurarse de que cada uno se complete satisfactoriamente.
CONTROL DEL ALCANCE
• El control del alcance del proyecto se encarga de influir sobre los factores que crean cambios en el alcance del proyecto y de controlar el impacto de dichos cambios.
• El control del alcance del proyecto también se usa para gestionar los cambios reales cuando se producen, y está integrado con los demás procesos de control. Los cambios no controlados a menudo se denominan corrupción del alcance del proyecto. Los cambios son inevitables, con lo cual se impone algún tipo de proceso de control de cambios.
• Por estructuración se entiende la facilidad con que las funciones pueden ser compartidas y la naturaleza jerárquica de la información a tratar. A medida que el grado de estructuración aumenta, la posibilidad de estimar con precisión mejora y, por consiguiente, el riesgo disminuye.
• Bajo el concepto de la administración de proyectos, se asignan representantes de cada uno de los departamentos funcionales de las divisiones al equipo asignado al proyecto. Cada miembro del equipo deriva una guía funcional experta y control administrativo del gerente de departamento.
El equipo incluye al siguiente personal clave:
1. Gerente de Proyectos
2. Ingeniero de Proyectos
3. Gerente de Construcción del proyecto
4. Coordinador de construcción del proyecto
5. Ingeniero de puesta en marcha del proyecto
6. Ingeniero de aseguramiento de la calidad del proyecto
7. Supervisor de costo y programas del proyecto
8. Administrador del proyecto
9. Gerente de aprovisionamiento del proyecto
10. Asistente del controlador del proyecto
ESPECIFICACIONES
• El concepto en la preparación de planos y especificaciones es que los planos del proyecto definen la geometría incluyendo dimensiones, forma y detalles mientras que las especificaciones complementen esto definiendo aspectos generales, materiales y la ejecución necesaria.
• Muchos profesionales de la construcción confían en que los planos contienen lo necesario para ejecutar su proyecto de infraestructura.
• En el momento en que se requiere más información o cuando surgen discrepancias, entonces buscan más detalles en las especificaciones. Es entonces donde muchas veces aparecen problemas porque las especificaciones no son adecuadas y, en vez de aclarar la intención del diseñador, crean complicaciones adicionales.
TIEMPO, COSTOS Y RECURSOS
La estimación del tiempo forma parte del proceso de Gestión del Tiempo de la Administración de Proyectos.
La Gestión del Tiempo del Proyecto incluye los procesos necesarios para lograr la conclusión del proyecto a tiempo. Los procesos de Gestión del Tiempo del Proyecto incluyen lo siguiente:
• Definición de las Actividades: identifica las actividades específicas del cronograma que deben ser realizadas para producir los diferentes productos entregables del proyecto.
• Establecimiento de la Secuencia de las Actividades: identifica y documenta las dependencias entre las actividades del cronograma.
• Estimación de Recursos de las Actividades: estima el tipo y las cantidades de recursos necesarios para realizar cada actividad del cronograma.
• Estimación de la Duración de las Actividades: estima la cantidad de períodos laborables que serán necesarios para completar cada actividad del cronograma.
• Desarrollo del Cronograma: analiza las secuencias de las actividades, la duración de las actividades, los requisitos de recursos y las restricciones del cronograma para crear el cronograma del proyecto.
• Control del Cronograma: controla los cambios del cronograma del proyecto.
COSTOS
• La estimación de costos de una actividad es una evaluación cuantitativa de los costes probables de los recursos necesarios para completar las actividades del cronograma del proyecto. Este tipo de estimación puede presentarse en forma de resumen o en detalle.
• Los costos se estiman para todos los recursos que se aplican a la estimación de costos de la actividad. Esto incluye, entre otros, la mano de obra, los materiales, los equipos, los servicios, las instalaciones, la tecnología de la información, y categorías especiales como una asignación por inflación o una reserva para contingencias de costo.
RECURSOS
• La estimación de recursos y costes es una actividad importante que debe llevarse a cabo con el mayor detalle posible, porque permite al comprador establecer una aproximación al coste total y plazos del desarrollo del sistema.
• Para ello se requiere experiencia, acceso a una buena información histórica y determinación para confiar en medidas cuantitativas cuando todo lo que existe son datos cualitativos.
1. Factores que afectan a esta estimación:
• La complejidad del proyecto, cuantificando la misma en función de:
• Número de módulos y nivel de interrelación entre los mismos.
• Número y tipo de las interfaces externas con otros sistemas, programas o datos.
• Grado de distribución y heterogeneidad del entorno de implantación.
• Grado de sofisticación de las herramientas de desarrollo.
• Naturaleza de los algoritmos que se deben diseñar y programar.
La siguiente figura muestra una aproximación basada en proceso para conseguir la calidad del producto.
martes, 28 de agosto de 2018
Unidad I GESTIÓN DE PROYECTOS
Unidad I: Introducción a la gestión de proyectos
1.1. Conceptos básicos para la gestión de proyectos ¿Qué es un proyecto?
Esto es, el proyecto tiene un resultado deseado, una fecha límite y un presupuesto (personal, suministros y dinero).
Características de un proyecto:
– Temporal: Debe tener principio y fin.
– Único: Carácter no repetitivo.
– Progresivo: Sigue una serie de etapas en su elaboración.
Podemos comentar 5 características importantes
Un proyecto tiene principio y fin definidos. Los proyectos usan recursos (personas, tiempo, dinero). Los resultados del proyecto tienen metas específicas de calidad y desempeño. Los proyectos siguen una planeación Un proyecto incluye un equipo de personas.
Tipos de proyectos
– Demanda del mercado
– Necesidad del negocio (interno)
– Petición del cliente (externo)
– Avance tecnológico
– Requerimiento legal
– Necesidad social
Programa y subproyecto
• Portfolio: Conjunto de proyectos o programas que se agrupan para facilitar la dirección eficaz para cumplir con los objetivos estratégicos del negocio.
• Programa: Grupo de proyectos relacionados y administrados de forma coordinada para obtener beneficios que no se obtendrían si la gestión fuera individual (sinergia).
• Subproyecto: Componente de un proyecto con suficiente independencia y entidad como para recibir una gestión individualizada.
¿Qué es la gestión de Proyectos?
Es la aplicación de conocimiento, habilidades, herramientas y técnicas a las actividades de un proyecto, con el fin de cumplir sus requerimientos.
Ciclos de vida vs Gestión
Ciclo de vida de un proyecto: Cada una de las fases que hay que desarrollar para obtener el producto o servicio asociado.Gestión del proyecto: Metodología para planificar, ejecutar y controlar las fases de una manera más efectiva (con más probabilidades de éxito).
• Ciclo de vida de un proyecto: Depende de cada tipo de proyecto. Ej.: – Desarrollo SW: Análisis, Diseño, Programación, Prueba, Implementación.
• Gestión del Proyecto: Siempre las mismas etapas: Inicio, Planificación, Ejecución, Control y Cierre.
Etapas de la gestión del Proyecto
Participantes de un proyecto
• Todo individuo u organización que tiene un interés dentro del proyecto:
– Sponsor (Patrocinador).
– Gestores de programas y portfolios, Oficina de proyectos.
– Responsables funcionales y de operaciones.
– Jefe de Proyecto.
– Equipo de Proyecto.
– Clientes (Usuarios).
– Subcontratas.
Gestión de participantes
• La gestión de los participantes es clave para la consecución del proyecto.
• Problemas:
– Participantes con intereses contrapuestos.
– Localización remota.
– Diferencias culturales.
Comprensión del entorno del proyecto
• Entorno cultural y social:
– Cómo el proyecto afectará a la gente
– Cómo la gente afectará al proyecto
– Visión del rol del Director de Proyectos en la organización
• Entorno internacional y político:
– Afecta a la comunicación
– Vital en multinacionales
• Entorno físico:
– Interacción con el medio ambiente
– Fenómenos naturales
1.2. Fases de la gestión de proyectos
1.2.1. Planificación de proyectos
Todo proyecto conlleva la realización de una serie de actividades para su desarrollo.
La distribución en el tiempo de dichas actividades y la consideración de los recursos necesarios son las funciones a desarrollar en la planificación de proyectos.
El objetivo de la planificación de proyectos es obtener una distribución de las actividades en el tiempo y una utilización de los recursos que minimice el coste del proyecto cumpliendo con las condiciones exigidos de: plazo de ejecución, tecnología a utilizar, recursos disponibles, nivel máximo de ocupación de dichos recursos.
Por tanto la planificación de proyectos es una programación de actividades y una gestión de recursos para obtener un objetivo de coste cumpliendo con los condicionantes exigidos por nuestro cliente.
La planificación involucra la especificación de objetivos y metas para un proyecto y las estrategias, políticas, planes y procedimientos para alcanzarlos.
Todo proyecto de ingeniería de software debe partir con un buen plan. La planificación es necesaria por la existencia de incertezas sobre el ambiente del proyecto software y sobre fuentes externas. La planificación enfoca su atención en las metas del proyecto, riesgos potenciales y problemas que puedan interferir con el cumplimiento de esas metas.
Los principales problemas en la planificación de un proyecto de ingeniería de software incluyen los siguientes:
• Requerimientos incorrectos e incompletos.
• Muchas especificaciones de requerimientos son inestables y sujetas a cambios mayores.
• La planificación no se lleva a cabo por la creencia errónea de que es una pérdida de tiempo y los planes cambiarán de todos modos.
• La planificación de costos y plazos no es actualizada y se basa en necesidades de mercadeo y no de los requerimientos del sistema.
• Es difícil estimar el tamaño y complejidad del proyecto de software de modo de realizar una estimación de costos y plazos realista.
• Los costos y plazos no son re estimados cuando los requerimientos del sistema o el ambiente de desarrollo cambia.
• No se manejan factores de riesgo.
• La mayoría de las organizaciones de desarrollo de software no recolectan datos de proyectos pasados.
• Las compañías no establecen políticas o procesos de desarrollo de software.
Actividades que se derivan de la planificación.
• Fijar los objetivos y metas
• Desarrollar estrategias
• Desarrollar políticas
• Anticipar futuras situaciones
• Conducir un establecimiento de riesgos
• Determinar posibles cursos de acción
• Tomar decisiones de planificación
• Fijar procedimientos y reglas
• Desarrollar los planes del proyecto
• Preparar presupuestos • Documentar los planes del proyecto.
"La planificación consiste en determinar qué se debe hacer cómo debe hacerse, quién es el responsable de que se haga y por qué."
1.2.2. Propuesta
La propuesta, memoria u oferta es la respuesta del proveedor externo a la petición que le hace el cliente. Si es un trabajo de un grupo formado dentro de la organización, el contenido es muy similar y puede dominarse memoria del proyecto o de otras maneras. Para la preparación de la propuesta, el grupo que la prepara debe revisar las especificaciones elaboradas por el cliente y celebrar reuniones con representantes de la organización, al menos de tres áreas: la parte administrativa y legal; la parte que encarga o administra el encargado del proyecto, y algunos usuarios clave. La propuesta debe ser dirigida por el jefe de proyecto que es el que asume la dirección del trabajo y que tenga una dotación adecuada de tiempo y recursos.
Selección.- Este servicio se refiere al proceso de elegir al personal que cuente con las competencias laborales y personales necesarias para cubrir vacantes existentes o proyectadas en su empresa dándole énfasis al lado humano de la competitividad.
Evaluación.- Uno de los pasos dentro del proceso de selección de personal son las evaluaciones psicológicas. Las mismas tienen como objetivo describir a la persona en sus diferentes aspectos (intelectuales, cognitivos, emocionales, etc.) y se consideran predictores del desempeño laboral.
El proceso de software lo componen participantes que pueden clasificarse en cinco categorías:
- Gestores superiores: definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto.
- Gestores técnicos del proyecto: deben planificar, organizar y controlar a los profesionales que realizan el trabajo del software.
- Profesionales: proporcionan las capacidades técnicas para la ingeniería de un producto
- Clientes: especifica los requisitos para la ingeniería de software.
- Usuarios finales: interaccionan con el software una vez que se ha entregado para la producción.
La tarea del selector consiste en detectar cuáles son las fortalezas y debilidades del postulante, es decir, cuáles son sus posibilidades y limitaciones para desarrollar las tareas requeridas por el perfil del puesto.
Consiste en todas aquellas actividades que involucran llenar (y mantener llenos) los puestos que fueron establecidos en la estructura organizacional del proyecto. Esto incluye selección de candidatos, entrenamiento y otros.
• Los jefes de proyecto son frecuentemente seleccionados por su habilidad para programar o realizar tareas de ingeniería en vez de su habilidad de gestión (pocos ingenieros son buenos gerentes)
• La productividad de los programadores, analistas e ingenieros de software varía mucho de individuo en individuo.
• Hay grandes cambios en el equipo de un proyecto software, especialmente en aquellos organizados matricialmente.
• Las universidades no están produciendo un número suficiente de ingenieros que entiendan el proceso de la ingeniería de software o gestión de proyectos.
• Los planes de entrenamiento para desarrolladores individuales de software no se desarrollan o mantienen.
La supervisión del proyecto es una actividad continua. El gestor debe tener conocimiento del progreso del proyecto y comparar el progreso con los costes actuales y los planificados. Se debe de tener una imagen clara de lo que pasa llevando a cabo una entrevista informal con el personal del proyecto.
Durante un proyecto es normal tener varias revisiones formales de su gestión. Se hace la revisión completa del progreso y de los desarrollos técnicos del proyecto, y se tiene en cuenta el estado del proyecto junto con los propósitos de la organización que ha encargado el proyecto.
Los gestores del proyecto tienen la necesidad de informar al cliente y contratistas sobre el proyecto. Tiene que redactar documentos concisos y coherentes que resuman la información crítica de los informes detallados del proyecto. Les debe ser posible presentar esta información durante las revisiones del progreso.
El Project Management Institute (PMI) es una organización internacional sin fines de lucro que asocia a profesionales relacionados con la Gestión de Proyectos. Desde principios de 2011, es la más grande del mundo en su rubro, dado que se encuentra integrada por más de 380.000 miembros en cerca de 170 países. La oficina central se encuentra en la localidad de Newtown Square, en la periferia de la ciudad de Filadelfia, en Pennsylvania (Estados Unidos). Sus principales objetivos son:
La Guía del PMBOK, desarrollada por el Project Management Institute, contiene una descripción general de los fundamentos de la Gestión de Proyectos reconocidos como buenas prácticas. Actualmente en su quinta edición, es el único estándar ANSI para la gestión de proyectos. Todos los programas educativos y certificaciones brindadas por el PMI están estrechamente relacionados con el PMBOK.
1.2.3. Selección y Evaluación de personal
Selección.- Este servicio se refiere al proceso de elegir al personal que cuente con las competencias laborales y personales necesarias para cubrir vacantes existentes o proyectadas en su empresa dándole énfasis al lado humano de la competitividad.
Evaluación.- Uno de los pasos dentro del proceso de selección de personal son las evaluaciones psicológicas. Las mismas tienen como objetivo describir a la persona en sus diferentes aspectos (intelectuales, cognitivos, emocionales, etc.) y se consideran predictores del desempeño laboral.
El proceso de software lo componen participantes que pueden clasificarse en cinco categorías:
- Gestores superiores: definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto.
- Gestores técnicos del proyecto: deben planificar, organizar y controlar a los profesionales que realizan el trabajo del software.
- Profesionales: proporcionan las capacidades técnicas para la ingeniería de un producto
- Clientes: especifica los requisitos para la ingeniería de software.
- Usuarios finales: interaccionan con el software una vez que se ha entregado para la producción.
La tarea del selector consiste en detectar cuáles son las fortalezas y debilidades del postulante, es decir, cuáles son sus posibilidades y limitaciones para desarrollar las tareas requeridas por el perfil del puesto.
Consiste en todas aquellas actividades que involucran llenar (y mantener llenos) los puestos que fueron establecidos en la estructura organizacional del proyecto. Esto incluye selección de candidatos, entrenamiento y otros.
Los principales problemas en esta etapa son:
• Los jefes de proyecto son frecuentemente seleccionados por su habilidad para programar o realizar tareas de ingeniería en vez de su habilidad de gestión (pocos ingenieros son buenos gerentes)
• La productividad de los programadores, analistas e ingenieros de software varía mucho de individuo en individuo.
• Hay grandes cambios en el equipo de un proyecto software, especialmente en aquellos organizados matricialmente.
• Las universidades no están produciendo un número suficiente de ingenieros que entiendan el proceso de la ingeniería de software o gestión de proyectos.
• Los planes de entrenamiento para desarrolladores individuales de software no se desarrollan o mantienen.
1.2.4. Supervisión y Revisión del proyecto
La supervisión del proyecto es una actividad continua. El gestor debe tener conocimiento del progreso del proyecto y comparar el progreso con los costes actuales y los planificados. Se debe de tener una imagen clara de lo que pasa llevando a cabo una entrevista informal con el personal del proyecto.
Durante un proyecto es normal tener varias revisiones formales de su gestión. Se hace la revisión completa del progreso y de los desarrollos técnicos del proyecto, y se tiene en cuenta el estado del proyecto junto con los propósitos de la organización que ha encargado el proyecto.
1.2.5. Informes
Los gestores del proyecto tienen la necesidad de informar al cliente y contratistas sobre el proyecto. Tiene que redactar documentos concisos y coherentes que resuman la información crítica de los informes detallados del proyecto. Les debe ser posible presentar esta información durante las revisiones del progreso.
1.3. Fundamentos de P.M.I
El Project Management Institute (PMI) es una organización internacional sin fines de lucro que asocia a profesionales relacionados con la Gestión de Proyectos. Desde principios de 2011, es la más grande del mundo en su rubro, dado que se encuentra integrada por más de 380.000 miembros en cerca de 170 países. La oficina central se encuentra en la localidad de Newtown Square, en la periferia de la ciudad de Filadelfia, en Pennsylvania (Estados Unidos). Sus principales objetivos son:
- Formular estándares profesionales en Gestión de Proyectos.
- Generar conocimiento a través de la investigación.
- Promover la Gestión de Proyectos como profesión a través de sus programas de certificación.
La Guía del PMBOK, desarrollada por el Project Management Institute, contiene una descripción general de los fundamentos de la Gestión de Proyectos reconocidos como buenas prácticas. Actualmente en su quinta edición, es el único estándar ANSI para la gestión de proyectos. Todos los programas educativos y certificaciones brindadas por el PMI están estrechamente relacionados con el PMBOK.
Suscribirse a:
Comentarios (Atom)