Carrera:

 INGENIERÍA DE SISTEMAS COMPUTACIONALES

Tema:

 El CMMI, PMBOK, SWEBOK, SUS RELACIONES

SIMILITUDES Y DIFERENCIAS.

Curso:

 ADMINISTRACIÓN DE PROYECTOS DE SOFTWARE

Grupo:

 QUISPE CHILQUILLO, RICARDO DAVID - N00128211

 VICTOR FLORES- N00082234
 CESAR RIVERA OYHUA - N00133740
 HENRY FERNANDO EVANGELISTA BONILLA- N00189462

Profesor:
ALFREDO CESAR LARIOS FRANCO

LIMA - PERÚ

2021

Administración de Proyectos de Software

[1]
 PMBOK

“La Guía de los Fundamentos para la Dirección de Proyecto, Guía del PMBOK o
simplemente el PMBOK, es una norma reconocida en la profesión de proyectos. Por
norma se hace referencia un documento formal que describe normas, métodos,
procesos y practicas establecidos. Al igual que otras profesiones tales como la
abogacía, la medicina y las ciencias económicas, el conocimiento contenido en esta
norma evolucionó a partir de buenas prácticas reconocidas por profesionales
dedicados de la dirección de proyectos, quienes contribuyeron a su desarrollo.”

La Guía del PMBOK®, contiene el cuerpo de conocimiento (Body of Knowlwedge)

indispensable para la profesión de la gerencia de proyectos (Project management).
Dicho cuerpo del conocimiento disciplinar involucra y afecta a los profesionales y
académicos que aplican ese conocimiento y lo avanzan. El PMBOK® incluye
conocimiento probado y prácticas tradicionales que se aplican ampliamente, además
del conocimiento e innovaciones de prácticas avanzadas que han visto un uso más
limitado.

El PMBOK® como la norma más reconocida para la gerencia de proyectos en los USA
ha sido aceptada dentro del conjunto de normas de la American National Standard con
la designación ANSI/PMI 99-001-2004.

FINALIDAD DE LA GUÍA DEL PMBOK

“La finalidad principal de la Guía del PMBOK® es identificar el subconjunto de

fundamentos de la dirección de proyectos generalmente reconocido como buenas
prácticas”. PMBOK® 4ª Edición, 2008.

Identificar significa proporcionar una descripción general en contraposición a una

descripción exhaustiva.

“Generalmente reconocido significa que los conocimientos y las prácticas descritos

son aplicables a la mayoría de los proyectos, la mayor parte del tiempo, y que existe
un amplio consenso sobre su valor y utilidad”.

Buenas prácticas significan que se está de acuerdo, en general, en que la aplicación

de estas habilidades, herramientas y técnicas puede aumentar las posibilidades de

Administración de Proyectos de Software

[2]
éxito de una amplia variedad de proyectos diferentes. Buenas prácticas no quieren
decir que los conocimientos descritos deban aplicarse siempre de forma uniforme en
todos los proyectos; el equipo de dirección del proyecto es responsable de determinar
lo que es apropiado para cada proyecto determinado”.

“La Guía del PMBOK® también proporciona y promueve un vocabulario común para
analizar, escribir y aplicar la dirección de proyectos. Un vocabulario estándar es un
elemento esencial de cualquier profesión.”

Las normas sobre dirección de proyectos no abordan la totalidad de los detalles de

cada tema. No se debe considerar que los temas que no se mencionan no sean
importantes.

El PMBOK no debe entenderse como una metodología per se, sino como una guía de
estándares internacionales para que los profesionales puedan adaptar a cada caso y
contexto particular los procesos, reconocidos como buenas practicas por el PMI que
se pueden aplicar a la mayoría de los proyectos en la mayoría de los casos.

El PMBOK, como cuerpo de conocimiento es una guía de métodos, herramientas y

técnicas agrupadas en áreas de conocimiento que en conjunto minimizan el riesgo de
que un proyecto no alcance sus objetivos. Pero no es un método ni es una
metodología. El método o metodología para cada proyecto lo debe definir cada
organización de acuerdo con diferentes intereses, productos, servicios, estructura,
misión y objetivos organizacionales.

IMPORTANCIA DE LA GUÍA DEL PMBOK

La importancia de la Guía del PMBOK es que provee un marco de referencia formal

para desarrollar proyectos, guiando y orientando a los gerentes de proyectos sobre la
forma de avanzar en los procesos y pasos necesarios para la construcción de
resultados y alcanzar los objetivos. Esto, por supuesto, requiere la adaptación de los
contenidos del PMBOK al dominio técnico y la especificidad de cada proyecto en
particular.

El PMBOK® compite con otros modelos de gerencia de proyectos como el de la

Association for Project Management (APM) y Prince (en Reino Unido); sin embargo, se
ha posicionado a nivel mundial como estándar de gerencia de proyectos y las
certificaciones otorgadas sobre este, como Certificate Associate in Project

Administración de Proyectos de Software

[3]
Management (CAPM®) y Project Management Professional (PMP®) son las más
reconocidas por las empresas y las más buscadas por los practicantes.

El PMBOK® es un compendio de mejores prácticas, agrupadas de cierta manera,

heredadas de diversas industrias y disciplinas que conforman un modelo
metodológico. El PMBOK® en sí no es una metodología que “deba” ser seguida al pie
de la letra; de hecho, el mismo documento, indica que los procesos y sus relaciones
deben ser personalizados a las necesidades del proyecto y de la empresa. El
PMBOK® es sólo una guía, muy completa y elaborada, de lo que normalmente un
gerente de proyectos debe llevar a cabo, explicado en un buen nivel de detalle y
separando procesos que normalmente se llevan a cabo de forma simultánea.

AUDIENCIA DE LA GUÍA DEL PMBOK

Esta norma proporciona una referencia fundamental para cualquiera que esté
interesado en la profesión de la dirección de proyectos. Entre ellos se pueden
mencionar:

 Altos ejecutivos responsables por la planificación, aprobación y control de proyectos en

sus organizaciones.

 Gerentes de programa y gerentes de directores del proyecto

 Directores del proyecto y otros miembros del equipo del proyecto

 Miembros de una oficina de gestión de proyectos

 Clientes y otros interesados

 Gerentes funcionales con empleados asignados a equipos del proyecto

 Educadores de dirección de proyectos y materias relacionadas

 Consultores y otros especialistas en dirección de proyectos y áreas afines

 Instructores que desarrollan programas de educación en dirección de proyectos

 Investigadores que analizan la dirección de proyectos.

Administración de Proyectos de Software

[4]
 COMPARACION ENTRE PMBOK Y CMMI

Como modelo, el PMBOK® no nos indica cómo se hacen las cosas, al igual que
CMMi® pero es más explícito que éste en la definición de los procesos o prácticas a
llevar a cabo, estableciendo una serie de entradas, técnicas y salidas para cada uno.

PMBOK es una norma que solamente aborda proyectos individuales y procesos de

dirección de proyectos generalmente reconocidos como buenas prácticas. Mientras
que el CMMI aborda normas sobre madurez de la dirección de proyectos de la
organización.

Administración de Proyectos de Software

[5]
 CMMI
CMMI es un modelo que contiene las mejores prácticas y que provee a las
organizaciones de aquellos elementos que son esenciales para que los procesos de
negocio de las mismas sean efectivos.
El modelo CMMI fue inicialmente desarrollado para los procesos relativos al desarrollo
e implementación de Software por la Carnegie-Mellon University. Este vio la luz por
primera vez en el año 1987 como Capability Maturity Model CMM. Dicho nombre, tanto
como los cinco niveles de la representación por etapas, están inspirados en el modelo
de madurez Manufacturing Maturity Model de Crosby.
Estas capacidades críticas abordan los principales retos a los que se enfrentan las
organizaciones como, por ejemplo:

 Asegurar la calidad
 Diseñar y desarrollar productos
 Entregar y gestionar servicios
 Seleccionar y gestionar proveedores
 Planificar y gestionar el trabajo
 Gestionar la resiliencia (capacidad de superar los momentos críticos)
 Gestionar el personal
 Mejorar el rendimiento de la organización

CMMI está formado por cientos de prácticas agrupadas en 22 áreas de proceso. Por
ejemplo, el área de proceso de Measurement and Analysis (MA) recoge las prácticas
relacionadas con la definición, gestión, análisis y mejora de métricas en la
organización para la medición del rendimiento y optimización de los procesos.
¿Qué es Madurez?
CMMI establece cinco niveles de ‘madurez’ de las organizaciones en función de si
tienen o no una serie de características específicas. Las organizaciones pueden ser
evaluadas y en función de dicha evaluación, se les puede otorgar un nivel de madurez;
ésta se califica en una escala del 1 al 5, es decir, a través de CMMI podemos saber el
grado de ‘madurez’ de los procesos que tiene una organización, de acuerdo a un
modelo de buenas prácticas.

Niveles de madurez por etapas.

 Nivel 1 (Inicial): El proceso es impredecible, es reactivo y pobremente

controlado.

 Nivel 2 (Administrado): En este nivel, el proceso es reactivo y se caracteriza

por su aplicación a proyectos.

 Nivel 3 (Definido): En este nivel, el proceso se vuelve proactivo y se ve a nivel

de organización.

Administración de Proyectos de Software

[6]
  Nivel 4 (Administrado Cuantitativamente): Este proceso es medido y
controlado.

 Nivel 5 (Optimizado): El Proceso se enfoca a una mejora continua.

Niveles de madurez Continuo.

 Nivel 0 (Incompleto): El proceso no se ejecuta o se hace de una manera

parcial.

 Nivel 1 (Ejecutado): El proceso se ejecuta y se producen productos basados en

entradas identificadas.

 Nivel 2 (administrado): El proceso es reactivo y se caracteriza por su aplicación

en proyectos.

 Nivel 3 (Definido): El proceso es proactivo y se visualiza a nivel de la

organización.

 Nivel 4 (Administrado Cuantitativamente): Este proceso es medido y

controlado.

 Nivel 5 (Optimizado): El Proceso se enfoca a una mejora continua.

¿Por qué es importante usar un modelo para el desarrollo de software?

La importancia del uso de un modelo radica principalmente en el hecho de que es

precisamente lo que permite comprender cuáles son los elementos específicos de una
organización, a la vez que ayuda a formular y hablar de qué es lo que se debe mejorar
dentro de la misma y de cómo se pueden lograr dichas mejoras.  Dicho esto, algunas
de las ventajas del uso de un modelo que valen la pena mencionar son las siguientes:

 Proporciona un marco y un lenguaje común, lo que se traduce en la ruptura de

las barreras de la comunicación en el interior de las organizaciones.

 Permite que los usuarios puedan enfocarse específicamente en la mejora, ya

que ayudan a que no pierdan la idea global.

 Aporta años de experiencia.

 Ayudan a mejorar la satisfacción del cliente.

 Permiten producir productos y servicios de alta calidad.

 
Algunos beneficios de CMMI

Hacer uso del modelo CMMI para el desarrollo de software, no solo permite optimizar
procesos de negocios, sino que también trae consigo una serie de beneficios, entre
ellos los siguientes:

Administración de Proyectos de Software

[7]
  La gestión y la ingeniería de las actividades se encuentran entrelazadas de una
manera explícita, tan es así que facilita el reconocimiento de los objetivos del
negocio.

 Permite hacer la incorporación de la experiencia adquirida en otras zonas de

las mejores prácticas. Algunos ejemplos serían la medición, gestión de riesgos
y de proveedores.

 Poder aplicar prácticas de alta madurez mucho más robustas.

 Cumplir de forma mucho más completa con las normas ISO.

 
Estos son solo algunos de los aspectos básicos del modelo CMMI que nos permiten
tener un acercamiento al por qué es ideal para el proceso de desarrollo de software,
muy importante considerarlo en cada entorno país.

SWEBOK
Introducción

El Software Engineering Body of Knowledge (SWEBOK) ha sido promovido y realizado

por el Institute of Electrical and Electronics Engineers (IEEE) Computer Society siendo
publicado su última versión (V3) en 2014 [5]. Es un estándar internacional, ISO/IECTR
19759:2005. Los editores de SWEBOK recibieron y contestaron a comentarios de
aproximadamente 150 colaboradores de 33 países. La versión 2 data de 2004 y la
versión1 de 2001. Los hitos más relevantes del IEEE Computer Society relacionados
para lograr realizar el SWEBOK se resumen en este listado cronológico.
1976. Se funda el comité por la IEEE Computer Society para el desarrollo de normas
de Ing. de Software.
1979. Se publica el estándar IEEE730 para el aseguramiento de la calidad. Es la
primera visión integral de la disciplina en emerger del IEEE Computer Society siendo
influyente para posteriores normas de gestión de la configuración, requisitos software,
diseño software, testeo software, etc.
1986. Se publica el IEEEStd.1002, Taxonomy of Software Engineering Standards que
proporcionó una nueva visión holística de la disciplina describiendo la forma y el
contenido de la taxonomía de estándares de Ing. de Software.
1993. El IEEE Computer Society en conjunto con la Association for Computing
Machinery (ACM) crearon un comité para “Establecer los conjuntos necesarios de
criterios y normas para la práctica profesional de la Ing. de Software en los que las
decisiones industriales, la certificación profesional y los programas de estudio puedan
estar basado.” Este fue el comité encargado de trabajar hasta que se
liberóSWEBOKV1 en 2001.
1996. Se publica el ISO/IEC12207, Standard for Software Life Cycle Process es
proporcionado un importante punto de partida para el conjunto de conocimientos
capturados en el SWEBOK.

Estructura

El SWEBOK, como su propio nombre indica, es un cuerpo del conocimiento1de la Ing.

de Software. Por tanto, no es sólo una metodología de gestión de proyectos en

Administración de Proyectos de Software

[8]
general como las de los apartados anteriores sino que abarca 15 áreas de
conocimiento que influyen en esta disciplina.

Requisitos del Software.

Se ocupa de la obtención, análisis, especificación y validación de requisitos del

software, así como la gestión de los requisitos durante todo el ciclo de vida del
producto de software. Los requisitos expresan las necesidades y limitaciones
impuestas a un producto software que contribuye a la solución de algún problema en
el mundo real.

Diseño del Software.

Cubre el proceso de diseño y el producto resultante. El proceso de diseño es la

actividad del ciclo de vida de Ing. de Software en el que se analizan los requisitos de
software con el fin de producir una descripción de la estructura interna del software y
sus funcionalidades, que servirán como base para su construcción. Un diseño describe
la arquitectura de software, es decir, cómo el software se descompone y es organizado
en componentes así como las interfaces entre esos componentes con un nivel de
detalle que permita su construcción.

Construcción (desarrollo) del Software.

Se refiere a la creación del software a través de una combinación de diseño detallado,

codificación, pruebas unitarias, pruebas de integración, depuración y verificación. Se
estudian los fundamentos del desarrollo de software, la gestión del desarrollo,
tecnologías de construcción, consideraciones prácticas y herramientas de desarrollo.

Pruebas del Software.

Es una actividad realizada para evaluar la calidad del producto y mejorarlo mediante
la identificación de defectos. Las pruebas implican la verificación dinámica del
comportamiento de un programa contra el comportamiento que se espera de un
conjunto finito de casos de prueba. Se estudian los fundamentos de las pruebas de
software, técnicas, pruebas de interfaz de usuario, medidas relacionadas con las
pruebas y consideraciones prácticas.

Mantenimiento del Software.

Implica mejorar las capacidades existentes, adaptando el software para funcionar en

entornos operativos nuevos y modificados, así como la corrección de defectos. Se
estudian los fundamentos de mantenimiento del software, cuestiones clave (técnicas,
gestión, estimación de costes, métricas de mantenimiento), el proceso de
mantenimiento, técnicas (reingeniería, ingeniería inversa, refactorización, retirada de
software en producción), técnicas de recuperación ante desastres y las herramientas
de mantenimiento.

Gestión de la configuración del Software.

Administración de Proyectos de Software

[9]
 Se encarga de la identificación de la configuración de un sistema en distintos puntos
temporales para controlar sistemáticamente cambios en la configuración, así como
mantener la integridad y la trazabilidad de la configuración en todo el ciclo de vida. Se
estudia la gestión del proceso de la configuración, identificación del software de
configuración, control, contabilidad de estados, auditoría, gestión de versiones y
entregas de software y herramientas de gestión de configuración.

Gestión de la Ing. de Software.

Consiste en la planificación, coordinación, medición, presentación de entregables y el

control de un proyecto para asegurar que el desarrollo y mantenimiento del software
es sistemático, disciplinado y cuantificado. Se estudian la iniciación y el alcance del
proyecto, su planificación, su ejecución, la aceptación del producto, la revisión y
análisis de los resultados del proyecto, su cierre y las herramientas de gestión.
Procesos de la Ing. de Software.

Se ocupa de la definición, implementación, evaluación, medición, gestión y mejora de

los procesos del ciclo de vida. Los temas cubiertos son la implementación de procesos
y el cambio (infraestructura y gestión de procesos, modelos de implementación de
procesos y el cambio), definición de procesos (modelos y procesos del ciclo de vida,
notaciones para la definición de procesos y la adaptación y automatización de
procesos), proceso de modelos y métodos de evaluación, medición (de procesos, de
productos, técnicas de medición y la calidad de los resultados) y herramientas de
proceso de software.

Modelos y métodos de la Ing. de Software.

Imponen una estructura en la ingeniería con el objetivo de hacer que la actividad sea
sistemática y repetible y, en última instancia, más orientada al éxito. Se estudia el
modelado (principios y propiedades, sintaxis vs. semántica vs. invariantes,
precondiciones, postcondiciones e invariantes), tipos de modelos (información y
modelos de comportamiento estructural), análisis (de exactitud, integridad,
consistencia, calidad, interacciones y trazabilidad) y los métodos de desarrollo
(heurísticos, formales, prototipos y ágiles).

Calidad del Software.

Es una preocupación omnipresente abordándose en muchas áreas de esta guía. Se

estudia los fundamentos (características y cultura de la calidad, el valor, el coste y la
mejora), procesos de gestión de la calidad (software de garantía de calidad,
verificación y validación, revisiones y auditorías) y consideraciones prácticas
(caracterización de defectos, medición y herramientas de calidad).

Práctica Profesional de la Ing. de Software.

Es el conocimiento, habilidades y actitudes que los ing. de software deben poseer

para ejercer su trabajo de una manera profesional, responsable y ética. Se estudia la
profesionalidad (conducta profesional, asociaciones profesionales, normas, contratos
de trabajo y asuntos legales), códigos de ética, dinámicas de grupo (trabajo en equipo,
la complejidad del problema cognitivo, interactuar con los involucrados, gestionar la
incertidumbre y la ambigüedad y también gestionar los entornos multiculturales) y
habilidades de comunicación.

Administración de Proyectos de Software

[10]
Economía de la Ing. de Software.

Tiene que ver con la toma de decisiones dentro del negocio para alinear las decisiones
técnicas con los objetivos empresariales. Se estudia los fundamentos (propuestas,
flujos de caja, valor temporal del dinero, horizontes de planificación, inflación y
depreciación, decisiones de reemplazo y retiro),toma de decisiones sin ánimo de lucro
(análisis de coste-beneficio y de optimización), estimación, el riesgo económico y la
incertidumbre (técnicas de estimación, decisiones relativas al riesgo y la incertidumbre)
y la toma de decisiones de atributos múltiples (escalas de medidas, técnicas
compensatorias y no compensatorias).

Fundamentos de Computación.

Es la base de las ciencias de computación necesaria para la práctica de la disciplina.

Se estudia las técnicas de resolución de problemas, abstracción, algoritmos y
complejidad, fundamentos de programación, computación paralela y distribuida,
fundamentos de computadores, sistemas operativos y comunicaciones de red.

Fundamentos Matemáticos.
Es la base matemática necesaria para la práctica de la disciplina. Se estudia los
conjuntos, relaciones y funciones, la lógica proposicional y de predicados; técnicas de
demostraciones, gráficos y árboles, probabilidad discreta, gramáticas y máquinas de
estados finitos y teoría de números.

Fundamentos de la Ingeniería.

Es la base en ingeniería necesaria para la práctica de la disciplina. Se estudia los

métodos empíricos y técnicas experimentales, el análisis estadístico, mediciones y
métricas, diseño de ingeniería, simulación y modelado y análisis de la causalidad.

Administración de Proyectos de Software

[11]