CONTROL DE CALIDAD DE

SOFTWARE

FACULTAD INGENIERIA DE SISTEMAS

 Universidad Nacional
“San Luis Gonzaga” de
Ica
Facultad
Ingeniería De Sistemas

- CURSO : Control de Calidad de Software

TEMA : Modelos de Proceso de Software
-

- DOCENTE : Alonso Morales

- ALUMNOS :
- Pacheco Pariona Víctor
- Lara Gavilán Luis
- Ñaupas Yanqui David
- Vilcatoma Caquiamarca José

- CICLO : VIII
- AULA : “B”

ICA-PERU
2018
 DEDICATORIA

Este presente trabajo está

dedicado primeramente a
Dios, a todas las personas
interesadas en este trabajo y
a nuestra familia por darnos
su apoyo incondicional.
 ÍNDICE
INTRODUCCION …………………………………………….……………..…………..... ... 6

MODELOS DE PROCESO DE SOFTWARE …………………..……………….…….…….7

PROCESO………………………………………………………………………………...…...7

PROCESO BÁSICO DEL CICLO DE VIDA DE UN

SISTEMA…………………….…….….…………………………………………………........10

PARADIGMAS DE LOS MODELOS DEL CICLO DE VIDA DEL

SOFTWARE…………………………………………………………………………....…..…11

CICLO DE VIDA DEL SOFTWARE EN LAS DISTINTAS

METODOLOGÍAS……………………...……………………………………..…………….. 13

MODELO ITERATIVO O POR PROTOTIPOS…………………………………..………....15

MODELOS DEL CICLO DE VIDA DEL DESARROLLO

ÁGILES…………………………………………………………………………….……..…..15

EVALUACIÓN Y MEJORAMIENTO DE LOS PROCESOS DE SOFTWARE …………..18

CONCLUSIONES ………………………………..………………………………………… 21

NORMA ISO/IEC 12207 ………………………………..…………...………………………22

DEFINICIONES IMPORTANTES……………………..……….………………………..… 23

ESTRUCTURA DE LOS PROCESOS DEL CICLO DE VIDA DEL SOFTWARE…….… 28

CMMI………………………………..…………….………………………………………… 29

NIVELES DE CAPACIDAD:………………………………………………..……………… 31

MOPROSOFT……………………………………………………………………….…….…. 33

CARACTERÍSTICAS…………………………………………...…………………………….34

BENEFICIOS…….………………………………………………………………...…………. 34

MODELOS DE EVALUACIÓN ISO/IEC 15504 ¿EN QUÉ CONSISTEN?…………....……35

EVALUACION POR NIVELES DE CAPACIDAD…………………………………………..36

INSTITUCIONALIZACIÓN DEL PROCESO EN ISO 15504………...................……….….37

MODELO DE EVALUACION POR NIVELES DE MADUREZ..……………….……….….38

QUÉ ES EVALPROSOFT………..........……………………………………………………... 42

USOS DEL MÉTODO DE EVALUACIÓN……………………………….……………..……44

DESCRIPCIÓN GENERAL DEL MÉTODO DE EVALUACIÓN…………..………..………45

MODELO DE CAPACIDADES DE PROCESOS……………………………………..………46

CALIFICACIÓN DE LOS PROCESOS……………………………………………………….54

PROCESO DE EVALUACIÓN…. .. ………………………………………………………….57

RESULTADOS DE LA EVALUACIÓN……………………………………………………..61

BIBLIOGRAFÍA…………………………………………………………………………...….. 65

INTRODUCCION
En un mundo de cambios constantes y competencia global, las organizaciones de
desarrollo de software son presionadas a alcanzar mayor eficiencia con menores
costos. Para poder lograr este objetivo, es necesario adoptar una forma de trabajo que
permita entender, controlar, comunicar, mejorar, predecir y certificar el trabajo realizado.

Actualmente existe una gran diversidad de opciones relacionadas con procesos de

desarrollo. Constantemente se escuchan diferentes acrónimos como CMM, CMMI,
RUP, ISO, PSP, TSP, etc., que causan confusión, principalmente debido a la mala
interpretación de los mismos.

Revisemos entonces los principales procesos de desarrollo y modelos más utilizados al

momento, así como los estándares relacionados.
 MODELOS DE PROCESO DE SOFTWARE
Proceso

Antes de definir lo que es un proceso de desarrollo de software, entendamos lo que es

un proceso. Una definición sencilla de proceso es “serie de acciones que conducen a
un final”. Esta definición parece coincidir con las ideas generales de la gente sobre
procesos, pero deja muchas preguntas abiertas. ¿El proceso es la forma en que la
organización opera —desde mercadotecnia hasta recursos humanos— o es la forma en
que un desarrollador diseña, produce código, o prueba el software? ¿El proceso se
refiere a administración, ingeniería, o ambas? ¿El proceso implica demasiada
documentación y nos abstiene de desarrollar el producto objetivo?
La respuesta a éstas puede variar dependiendo de la perspectiva. Sin embargo, siempre
que para alcanzar algún fin deseado necesitemos ejecutar una serie de acciones, y
estas acciones tengan cierto orden, dependencias, roles responsables, resultados,
tiempos de ejecución y herramientas de apoyo, estaremos hablando de procesos, que
pueden ser predefinidos y personalizados.

Proceso de software

La meta de la ingeniería de software es construir productos de software, o mejorar los

existentes; en ingeniería de procesos, la meta es desarrollar o mejorar procesos.

Un proceso de desarrollo de software es un conjunto de personas, estructuras de

organización, reglas, políticas, actividades y sus procedimientos, componentes de
software, metodologías, y herramientas utilizadas o creadas específicamente para
definir, desarrollar, ofrecer un servicio, innovar y extender un producto de software.

Un proceso de software efectivo habilita a la organización a incrementar su

productividad al desarrollar software:

• Permite estandarizar esfuerzos, promover reúso, repetición y consistencia entre

proyectos.
• Provee la oportunidad de introducir mejores prácticas de la industria.
• Permite entender que las herramientas deben ser utilizadas para soportar un
proceso.
• Establece la base para una mayor consistencia y mejoras futuras.

Un proceso de software mejora los esfuerzos de mantenimiento y soporte:

• Define cómo manejar los cambios y liberaciones a sistemas de software

existentes.
• Define cómo lograr la transición del software a la operación, y cómo ejecutar los
esfuerzos de operación y soporte.
Necesitamos un proceso de software cuya funcionalidad esté probada en la práctica, y
personalizado para que cumpla con nuestras necesidades específicas.

Imagen 1

Elementos Típicos del Proceso de Software:

• Actividad: Define las acciones que se llevan a cabo en un momento dado del
desarrollo del software.

• Flujo de trabajo: Colección estructurada de actividades y elementos asociados

(artefactos o roles), que producen un resultado de valor.

• Rol: Son responsables por llevar a cabo las actividades, pueden ser de diferentes
tipos, como documentos, modelos, componentes, planes, reportes.

• Producto o Artefacto: Son las entradas y salidas de las actividades, pueden ser
de diferentes tipos, como documentos, modelos, componentes, planes, reportes.

• Disciplina: Conjunto integrado por actividades relativas a una rama particular de

conocimiento. Análisis y Diseño.

¿Por qué contar con un proceso de software?

Hasta hace poco tiempo, la producción de software era realizada con un enfoque
artístico, a diferencia de un enfoque industrial. Ante la constante presencia de proyectos
fallidos, y con el objetivo de mejorar la calidad de los productos, en los últimos años las
organizaciones introdujeron los métodos de ingeniería de software.
A partir de estos, se formalizó el enfoque de ingeniería de producto para desarrollar
software. Factores como la globalización han obligado a las organizaciones a contar con
marcos de trabajo que las ayuden hacer las cosas de la manera más eficiente. Fue
entonces que se incorporó la ingeniería de procesos al desarrollo de software.
Diversidad en Modelos
Actualmente existe una gran variedad de modelos para procesos de software. Podemos
entenderlos más fácilmente si los clasificamos en dos tipos: genéricos y específicos.
Imagen 2
Proceso Básico del Ciclo de Vida de un Sistema

Si bien, es cierto que existen diversas metodologías y formas de desarrollar software, la

realidad es que hay modelos tan antiguos que ya son como básicos al momento del ciclo de
vida de un software. Un ejemplo de esto es el modelo en cascada para el proceso de
desarrollo de un sistema, con el cuál veremos a ciencia cierta el proceso básico, del cual
muchos modelos más se empezarán a desarrollar.

• Planificación. El primer punto importante en el ciclo de vida de software es analizar

brevemente los requerimientos que el cliente pide para la elaboración del sistema que
necesita. Esta etapa requiere se cierto conocimiento para poder entender la idea que el
cliente propone, además de que regularmente debes tomar nota con cada uno de los
puntos importantes que se te solicitan, de este modo puedes hacer una planificación al
momento y llegar incluso a determinar los tiempos de desarrollo que te llevará, antes
de proceder a entregar el producto final. Un punto importante por el cual la
planificación siempre debe estar en los ciclos de vida del software. Es porque el cliente
se imagina su producto final de una forma tan abstracta, que necesitas hacer que
ponga los pies en el suelo para obtener resultados que se acerquen más a la realidad.

• Implementación. Una vez que hemos platicado con el cliente y tenemos lo que es un
análisis de requerimientos, necesidades y funcionalidades por parte de una aceptación
en ambas partes, entonces procedemos con lo que es el ciclo de vida de desarrollo de
software. Para este punto, existen una infinidad de metodologías de desarrollo de
software, que nos ofrecen la posibilidad de trabajar de distintas formas. Más adelante
hablaremos más específicamente de ellas, sin embargo, la implementación, es
básicamente la parte donde los programadores empiezan a codificar o desarrollar el
sistema que se necesita, básicamente se trata del ciclo de vida del desarrollo de
sistemas, sin importar el lenguaje de programación mediante el cual se vayan a
elaborar.

• Pruebas. Una vez que el sistema se va desarrollando, es importante para el ciclo de

vida del desarrollo del software, que se realicen ciertas pruebas conforme se vaya
avanzando. La idea es que no se termine el desarrollo para poder hacer pruebas, si no
que mucho antes, durante el proceso de creación, estas ya se puedan ir ejecutando.
Las pruebas nos van a permitir ver si el sistema que se está desarrollando es
funcional, si tiene algunos errores, si le faltan ciertas cosas para funcionar
correctamente, pues básicamente para avanzar al siguiente punto del ciclo de
desarrollo de software, será necesario haber pasado las pruebas correctamente.

• Documentación. Muchas metodologías de lo que es el ciclo de vida software, van

creando documentación, conforme se va avanzando en el desarrollo del sistema. Sin
embargo, algunas otras prefieren no hacer la documentación hasta el final. Ahora sí
que sea cual sea la metodología que elijas, la documentación siempre será importante,
pues considera que no siempre vas a estar tú y tu equipo disponibles y cuando otro
equipo llegue a programar lo que ustedes hicieron, será indispensable que haya una
documentación de la cual se puedan basar, para poder empezar a desarrollar
nuevamente el sistema incompleto.
 • Despliegue. Ya casi llegando a lo que son las últimas etapas del desarrollo de
software, nos encontramos con el Despliegue. Este no es otra cosa, más que el
momento en que el sistema ya está terminado y ha sido aprobado para que se elabore
el producto final. Ahora será el momento de distribuirlo y celebrar, pues gracias al
equipo de trabajo es Como se habrá llegado a esta fase. Lamentablemente, de las
etapas de desarrollo de software, esta es a la cual muchos nunca llegan. Pues una
gran cantidad de software incompleto se queda en el camino debido a distintos puntos
o motivos. Puede ser que el equipo no se unió, el cliente declinó, el proyecto no fue
funcional, etc. Así que, de Haber llegado a esta fase de desarrollo de software, tu como
tu equipo deberán sentirse orgullosos y es momento de volver a desarrollar un
proyecto más.

• Mantenimiento. La última de las fases del desarrollo de software, es el mantenimiento.

Que creías, que nunca más verías al software que hicieron, terminaron y distribuyeron.
Pues claro que si lo volverías a ver, pues es momento de darle mantenimiento. Acá
además se pueden agregar lo que son las actualizaciones, dependiendo del tipo de
desarrollo. Si el equipo siguió trabajando con el software desarrollado y encontraron
formas de hacerle mejoras, entonces parte del mantenimiento será actualizarlo a la
versión final en todo momento.

Paradigmas de los Modelos del Ciclo de Vida del Software

Una de las cosas principales, que se deben elegir al momento de empezar un proyecto de
desarrollo de software, son precisamente las etapas del desarrollo de software. Si bien, nos
queda claro que no todos tenemos las mismas ideas y no todos pensamos de la misma
manera, afortunadamente ya existen modelos preestablecidos bajo los cuales podemos
elaborar nuestro proyecto. Es por eso que a continuación les mostraré cuales son algunos de
los paradigmas de los Modelos del ciclo de vida de desarrollo de sistemas. Bajo los cuales
podemos encontrar una gran cantidad de modelos distintos para desarrollar software, veamos.

• Paradigma Tradicional. Existen algunas metodologías del ciclo de vida de desarrollo

de sistemas, que se manejan a la antigua, a estas también se le conocen como
paradigmas tradicionales. Si bien, es verdad que las metodologías actuales están
basadas con fundamentos de lo que fueron los paradigmas tradicionales, hoy en día ya
hemos evolucionado, sin embargo, los paradigmas tradicionales ahí se mantienen.
Estos paradigmas, se caracterizan principalmente por ser lineales sin vuelta atrás, es
decir, se trataba de completar cada proceso de principio a fin, hasta que quedara listo
para avanzar a la segunda fase del ciclo del software. Esto generaba grandes
dificultades y pérdidas de tiempo si se encontraba algún error en una fase avanzada,
pues el proceso a realizarse era, volver atrás y volver a pasar nuevamente por las
fases que ya se habían hecho y reestructurar de acuerdo a las modificaciones, pero
todo con un proceso lineal, lento y tardado.
• Paradigma Orientado a Objetos. Una de las genialidades más exquisitas, es el
desarrollo de software mediante programación orientada a objetos. Con esta forma del
ciclo de vida de los sistemas, lo que se pretende es que el código fuente sea
reutilizable para otros proyectos o mini proyectos alternos relacionados con el
programa base, pues se utilizan Clases. Básicamente la etapa de desarrollo de
software en el paradigma orientado a objetos se conforma principalmente lo que es la
creación de clases, seguido del análisis de requisitos, un paso fundamental para
determinar no solamente la duración del desarrollo, sino también los costos al final del
proyecto. Y por supuesto el diseño, pues ya con el paradigma orientado a objetos, el
diseño es mucho mejor que con un paradigma tradicional.

• Paradigma de Desarrollo Ágil. Los modelos de ciclo de vida ágiles son de los más
utilizados hoy en día. El objetivo de este paradigma es el desarrollo de proyectos en
poco tiempo. Para lo cual, se hace una eliminación de procesos tediosos, se agilizan
las fases de desarrollo, las iteraciones se hacen en un corto periodo de tiempo, los
riesgos se desechan y se evitan para no tener que lidiar con ellos y siempre se da
solución a los problemas de forma rápida. Si algo demora mucho en dar solución, lo
mejor es dejarlo de lado y seguir avanzando. Una de las principales diferencias del
paradigma de desarrollo ágil con los paradigmas anteriores, es que el cliente se ve
involucrado en el proyecto durante el desarrollo de este. A diferencia del paradigma
tradicional donde el cliente solo está al principio, de igual forma en el paradigma
orientado a objetos sucede lo mismo. Acá el cliente interfiere, da mejoras, propone
ideas y se mantiene al tanto del desarrollo del producto. Lo que ayuda aún más, pues
el producto final se realiza de forma satisfactoria en un menor lapso de tiempo.

Imagen 3
Ciclo de Vida del Software en las distintas Metodologías

El ciclo de vida de un proyecto se software, empieza cuando se da la recolección de

requerimientos para el programa a desarrollar y termina cuando el producto ha quedado
completado y es entregado al cliente que lo pidió. Sin embargo, en el intermedio, hay una gran
cantidad de fases por las cuales se tiene que pasar y cada metodología tiene fases distintas
en su ciclo de desarrollo de programas, es por eso que a continuación, veremos cómo están
compuestas cada uno de los modelos de ciclo de vida del software, sin entrar a escenarios
profundos, pues son tantas metodologías por mencionar que nos podríamos llevar todo el día.

Modelo en Cascada

Una de las metodologías más antiguas en lo que es el ciclo de vida de un modelo informático,
es el modelo de cascada. Esta metodología es lineal y consta de algunas fases que hay que
seguir y completar para poder avanzar a la fase siguiente. No es precisamente la mejor
metodología, pero si se utiliza de forma correcta los resultados pueden ser muy buenos. Está
compuesta por las siguientes fases:
1. Requerimientos
2. Diseño
3. Implementación y Desarrollo
4. Integración
5. Pruebas o Validación
6. Despliegue o Instalación
7. Mantenimiento
Como puedes ver, el ciclo de vida de un programa realizado bajo la metodología en cascada
es extenso pero muy bien estructurado. El detalle aquí es que no puedes saltarte fases ni
volver a repetirlas, por ejemplo.
Si se realiza un análisis de requerimientos, avanzamos a diseñar el programa y ya estamos en
el desarrollo y de momento el cliente nos dice que desea modificar los requerimientos,
digamos que, por tratarse del modelo en cascada, no es posible volver atrás. Por lo tanto, se
tendría que reiniciar el proyecto o bien concluirlo y ver cómo queda el software al final.
Como te mencionaba, es una metodología lineal en cascada y si no se completa cada una de
las fases al 100%, no es posible avanzar a la fase que sigue, así es como funciona y se debe
seguir al pie de la letra, por muy exagerado que esta parezca.

Modelo en el Espiral

El modelo espiral en ingeniería del software tiene un enfoque muy distinto al modelo de
cascada, principalmente porque su enfoque va dirigido hacia el análisis de riesgos. El modelo
de ciclo de vida en espiral consiste en realizar diversas iteraciones, pasando por cada una de
sus fases una y otra vez. A diferencia de la modelo cascada que no tiene vuelta atrás, en el
modelo en espiral se pueden hacer las iteraciones que se consideren necesarias y estas son
sus fases principales:
1. Determinación de Objetivos
2. Análisis de riesgos
3. Desarrollo y Pruebas
4. Planificación
Entre las principales ventajas de desarrollar un proyecto con el modelo espiral, es que
los riesgos se van disminuyendo conforme avanzan los ciclos o iteraciones, de hecho,
no puedes avanzar a un ciclo nuevo, si no se ha dado solución a todos los riesgos latentes.
Lamentablemente el modelo es realmente costoso y para que puedas tener un alto nivel de
eficacia en la evaluación final de tu proyecto con este ciclo de vida, necesitas que tu equipo
tenga un gran nivel de conocimientos y si es posible buena experiencia para superar cualquier
riesgo al cual se puedan enfrentar.

Imagen 4
Modelo Iterativo o por Prototipos

Uno de mis modelos de ciclo de vida de antaño que realmente es de mis favoritos, es el
modelo iterativo. ¿La razón?, se maneja a base de prototipos, es decir. Es uno de los primeros
ciclos de vida que permitían que el código fuente fuera reutilizable, sin embargo, con el
modelo iterativo no solo es utilizable, si no que, para muchos, estos prototipos pueden llegar a
ser el producto final que siempre quisieron, lo cual lo hace realmente relevante y destacable,
por encima del resto de los modelos de antaño que puedas encontrar.
Básicamente, las fases del ciclo de vida del sistema son las siguientes:
1. Inicialización
2. Iteración
3. Lista de Control
Una de las principales ventajas del modelo iterativo, es que la retroalimentación a los usuarios
se proporciona desde muy temprano, haciendo que adentrarse en el proyecto sea demasiado
sencillo. Por supuesto que el hecho de contar con iteraciones nos da ciertas ventajas, pues
con cada iteración realizada, se van separando las partes complejas de él, permitiendo más el
acceso al software. Y por supuesto, un sistema creado mediante el ciclo de vida iterativo
tiende a no fallar casi, lo cual es garantía de satisfacción para el cliente en este caso o para la
empresa que está implementando esta metodología.

Modelos del Ciclo de Vida del Desarrollo Ágiles

Las tendencias, con el paso del tiempo suelen cambiar para bien y en el caso de las
metodologías del ciclo de vida desarrollo de software no es la excepción. Y un claro ejemplo
de esto, son los modelos de desarrollo ágil. Estos procesos se caracterizan por estar basados
en las etapas del ciclo de vida del software tradicionales, pero combinándolas con algunas
técnicas y siendo aún más solapadoras en cuando al orden que se deben ejecutar. Bueno no
les diré más, mejor vamos a ver brevemente cuales son algunas de ellas, las más conocidas y
populares, claro y la mejor de todas.

Modelo Scrum

El ciclo de vida del sistema puede agilarse si se utiliza la metodología Scrum, uno de los
modelos del ciclo de vida del desarrollo del software más populares y más recientes, bueno no
tanto, pero si más que los de antaño. El modelo Scrum, se encuentra basado en lo que es el
desarrollo incremental, es decir, conforme pasen las fases y las iteraciones, mayor va a ser el
tamaño del proyecto que se esté desarrollando, es por eso que uno de los principales
requisitos para llevarlo a cabo, es que tu equipo de desarrollo sea de calidad. Teniendo una
alta calidad en el equipo, tendremos garantizado un excelente funcionamiento.
Como te mencionaba al principio, el modelo Scrum, deja de seguir metodologías lineales,
podemos despedirnos del modelo cascada y secuencial, pues ahora procedemos a solapar las
fases y no importará en qué momento tengas que volver atrás, siempre habrá un equipo de
trabajo de buena calidad, que tenga ese soporte para aguantar los cambios que son
ciertamente normales dentro de la metodología Scrum. Por último, como ingrediente vital
tenemos la comunicación, y es que acá olvídate de las tendencias de ese jefe que te tienen
envuelto en una burbuja desarrollando. Con el modelo scrum podrás estar comunicado con tu
equipo de trabajo en todo momento, para estar al tanto de los sucesos.
Ahora veremos brevemente, cuáles son los procesos que el modelo Scrum utiliza:
1. Product Backlog
2. Sprint Backlog
3. Sprint Planning Meeting
 4. Daily Scrum o Stand-up Meeting
5. Sprint Review
6. Sprint Retrospective
Estas son las fases del ciclo de vida del software en esta metodología, el cuál
básicamente consiste en realizar un análisis de los requerimientos del sistema (Product
Backlog), señalar cuáles serán los objetivos a corto o mediano plazo dentro de un sprint, ósea,
la fase de desarrollo. Posteriormente los desarrolladores harán lo suyo, se realizan algunas
pruebas y se retroalimenta de acuerdo a lo conseguido al terminar la última fase. Recuerda
que aquí, se pueden añadir nuevas cosas en todo momento, pues el modelo Scrum no se
bloquea en ninguna de sus fases.

Modelo Kanban

El modelo Kanban, es uno de los modelos más visuales de las metodologías ágiles. Consiste
en la creación de un tablero con etiquetas, donde se seccionan cada una de las fases de su
desarrollo, además se clasifica de acuerdo a los equipos de trabajo y se les asignan objetivos
a corto, mediano y largo plazo.
Entre las ventajas de este modelo del ciclo de vida del software, destaca el hecho de no tener
un orden tal cual, de hecho, todas las fases comienzan a trabajar a la par, no hay tiempos de
espera y básicamente su objetivo es que los desarrolladores y programadores estén
trabajando todo el tiempo. Si concluyes con las fases del proyecto que te corresponde,
seguramente tendrás que avanzar en fases del nuevo proyecto que está por venir.
Por supuesto, la metodología Kanban, también requiere de un equipo totalmente capacitado,
pues solamente de esta forma se podrán lograr los objetivos. Así que aquí les muestro las
fases del proceso del ciclo de vida de un sistema, mediante la metodología japonesa Kanban:
1. Definir el Flujo de Trabajo
2. Fases del Ciclo de Producción
3. Stop Starting, start finishing
4. Tener un Control
Si aún no estás seguro de si implementar la metodología Kanban o no, te cuento. La empresa
Toyota, ha sido una de las primeras en implementar la metodología, incrementando la
eficiencia y productividad en un alto porcentaje. Considera como principal ventaja, que el
producto final quedará terminado en un periodo de tiempo mucho más corto, que con
cualquiera de las metodologías vistas al principio.

Modelo XP o Programación extrema

Posiblemente la más destacada de las metodologías ágiles para los ciclos de vida de un
software, es la metodología XP o modelo de programación extrema. A diferencia del resto de
las metodologías del mundo, habidas y por haber, esta es adaptable de acuerdo a las
necesidades y requerimientos que se tengan que implementar, con la ventaja de que podemos
hacer uso de cualquier modelo anterior para el desarrollo y de inmediato salirnos y programar
otras cosas, es muy solapador y permite mucha más libertad en el equipo de trabajo que el
resto de los modelos.
Además, si querías una diferencia aún mayor, en la metodología de programación extrema, el
cliente se encuentra involucrado en el proceso de desarrollo, lo que hace que al final el
producto pueda estar terminado en un menor tiempo, pues evitamos muchas pérdidas de
tiempo, elaborando cosas que no son y que en la revisión al cliente no le agradarán, acá el
cliente va viendo lo que se va desarrollando y tiene la libertad de proponer cambios, ideas,
requerimientos o actualizaciones sin ningún problema.
Los valores que componen a al modelo de programación extrema, son los siguientes:
1. Comunicación
2. Simplicidad
3. Retroalimentación
4. Valentía
5. Respeto
Esta serie de valores, son de suma importancia para que se pueda llevar a cabo un proyecto
de alta calidad. Cada uno de ellos, tiene su razón de ser y existir, por ejemplo, la
comunicación, la cual debe estar incluso con el cliente y ni hablar del resto de los equipos de
trabajo. La simplicidad corresponde al hecho de no hacer cosas que quiten mucho tiempo, la
idea es terminar rápido y las cosas que sean muy tardadas es mejor dejarlas de lado. La
retroalimentación es vital, más cuando los equipos de trabajo deben ser de dos personas,
siempre es bueno aprender cosas nuevas de nuestro compañero de trabajo y esto
seguramente todos lo hemos vivido alguna vez.
La valentía es un valor integrado como programador, pues deber ser valiente para afrontar los
cambios que se vengan, tomar decisiones radicales y en todo momento mantener esa fuerza
que tanto a ti como a tu equipo de trabajo los debe mantener a tope. Y por su puesto el
respeto, esto es en todo el equipo de trabajo, hasta el cliente debe tener un margen de
respeto por el equipo de desarrollo. Con estos valores la metodología tendrá una buena
formación, pero vamos a ver cuáles son las características principales de la programación
extrema:

1. Tipo de Desarrollo Iterativo e incremental

2. Pruebas Unitarias
3. Trabajo en Equipo
4. Trabajo junto al cliente
5. Corrección de Errores
6. Reestructuración del Código
7. El Código es de todos
8. Código simple es la clave
Como te puedes dar cuenta, pasos como hacer el código simple o las pruebas unitarias para
prevenir errores y tener que darle muchas vueltas al código, además de que las fases se
segmentan en pequeñas porciones, para que, si hay errores, estos puedan ser modificados
fácilmente.
Sin embargo, seguramente notaste que no hay documentación por ningún lado, esto es
porque con tanta comunicación, en realidad no es necesaria, sin embargo, dentro del código
se van dejando comentarios con las cosas que otro programador no pueda llegar a entender y
se utilizan variables o clases entendibles para que todo el mundo tenga la facilidad de
comprenderlo. Ya solamente en caso muy necesario, se procede a hacer documentación
breve para algunas partes, pero regularmente no se utiliza de forma tradicional.
Evaluación y Mejoramiento de los Procesos de Software
El Modelo de Madurez de la Capacidad (CMM)

El CMM (Capability Maturity Model) fue desarrollado por el Software Engineering Institute
(SEI) de la Univ. Carnegie-Mellon en USA con la finalidad de:

- Evaluar la madurez de los procesos de desarrollo de software dentro de una

organización.
- Proponer un plan de mejoramiento de los procesos de desarrollo de software en base
a una serie de niveles que van desde un proceso caótico (inmaduro) hasta un proceso
disciplinado y de mejoramiento continuo (maduro).
Capacidad de un proceso de software:

Rango de resultados esperados que pueden ser logrados siguiendo un proceso de

software dado

Madurez de un proceso de software:

- Determina en que grado un proceso de software es explícitamente definido,
administrado, medido, controlado y hecho efectivo
- La madurez es un indicador de la capacidad del proceso de software para lograr sus
objetivos y resultados esperados.
- Una organización logra mayor madurez mediante la institucionalización del proceso de
desarrollo de software, estableciendo las políticas, estándares y estructuras
organizativas

El CMM emplea 5 niveles de madurez para evaluar y mejorar los procesos de software
de una organización

Imagen 5
Nivel Inicial
- La organización no posee un ambiente estable de desarrollo de software
- Ausencia de gerencia de proyectos
- El proceso de software es cambiante e irregular:
• Durante las crisis, los grupos abandonan el método y se concentran en la
codificación y pruebas
- Los planes, estimaciones y calidad son impredecibles
- El rendimiento y el éxito dependen de la capacidad individual de los miembros del
grupo
- La capacidad es una característica de los individuos y no de la organización

Nivel Repetible

• La organización establece políticas para gerenciar los proyectos de software y

procedimientos para implantar estas políticas
• Los procesos están bajo un control efectivo de un sistema de gerencia de
proyectos basado en experiencias anteriores
• Los procesos son definidos, documentados, practicados, medidos, obligados y
mejorables
• Los procesos de software son estables y repetibles
• Existen estándares de desarrollo definidos y exigidos
• La calidad es controlada

Nivel Definido

• Los procesos de software son definidos:

- estandarizados, documentados e institucionalizados
• Se institucionaliza un proceso estándar de desarrollo de software que integra en uno
solo:
• los procesos de ingeniería de software y gerencia de proyectos de software
• Existe un entendimiento común de los procesos, funciones y responsabilidades. La
organización mantiene un grupo dedicado a la definición, mejoramiento y difusión del
proceso estándar
• El proceso estándar es adaptado a cada proyecto

Nivel Gerenciado:

La organización define metas de calidad cuantitativas para:

- los productos de software y los procesos de software

El proceso estándar es medible o cuantificable:

- La productividad y la calidad se miden y se registran para cada proyecto

La calidad del software es predecible, Mediante el uso de métricas de software, se crea una
base de datos cuantitativa para la evaluación y estimación en proyectos futuros.
La capacidad del proceso de software es cuantificable y predecible
Nivel Optimizado:
La organización se orienta hacia el mejoramiento continuo de sus procesos de software, la
organización identifica las debilidades y fortalezas de su proceso y determina maneras de
mejorar su capacidad
La organización busca aumentar la capacidad y el rendimiento de sus procesos
Se incorporan nuevas tecnologías y métodos para mejorar los procesos

El mejoramiento ocurre a través de:

- El avance incremental del proceso

- Uso de nuevas tecnologías y métodos

Imagen 6
Aspectos de uso del modelo:
• El escalamiento de los niveles es progresivo
Saltarse un nivel es contraproducente
• Normalmente se requiere 1 – 3 años para escalar al siguiente nivel
Alcanzar, desde el nivel 1, la categoría de “Organización Madura” puede tomar más de
10 años
• Es posible retroceder desde un nivel superior
• El CMM no es una “bala de plata” (silver bullet), no resuelve todos los problemas de
calidad en el complejo proceso de desarrollo y mantenimiento de software
• La evaluación es hecha por especialistas adiestrados y acreditados por el SEI
Conclusiones

• El desarrollo de software es un proceso complejo que requiere:

✓ Un recurso humano altamente especializado y actualizado

✓ Un mejoramiento continuo y estandarización de los procesos de desarrollo
✓ Aplicación de procesos gerenciales
✓ Un aseguramiento de la alta calidad del software producido
✓ Tecnología y herramientas apropiadas y actualizadas

• El CMM proporciona una estructura conceptual y metodológica para mejorar la

gerencia y el desarrollo de S/W y, por ende, la calidad de los productos

Norma ISO/IEC 12207

La Norma ISO/IEC 12207, fue la primera norma internacional que proporcionó un amplio
conjunto de procesos de ciclo de vida del software, el cual forma parte de un sistema

mayor, se realizó su primera publicación el 1 de agosto de 1995, la misma que fue

precedido en noviembre del 2002 por la norma ISO/15288 que trata los procesos del ciclo

de vida de un sistema.

Imagen 7
Según esta norma, el

software y sus procesos de diseño, no deben estar desvinculados de los sistemas, por el

contrario deben ser tomados como una parte integral de los procesos de diseño de

sistemas, la norma puede ser utilizada:

➢ Por una organización: para ayudar a establecer un entorno de trabajo.

➢ Por un proyecto: para ayudar a seleccionar una infraestructura y emplear todos

los elementos que comprenden un conjunto de ciclo de vida establecido.

➢ Por un comprador o proveedor: para ayudar a desarrollar un acuerdo sobre los

procesos y actividades que se van a manejar.

➢ Por las organizaciones y asesores: para realizar evaluaciones que puedan servir

de apoyo para mejorar los procesos de la organización.

Definiciones Importantes

Antes de entrar en materia de la norma, es necesario conocer las definiciones de términos

que facilitaran el entendimiento de la misma.

Estándar

Un estándar es un modelo o conjunto de reglas y procedimientos documentados que se

siguen con la finalidad de cumplir un objetivo.

ISO

Son las siglas de (International Organization for Standardization), proviene del griego

(isos), que significa igual, la Organización Internacional de Estandarización, es un

organismo que promueve el desarrollo de normas internacionales de comercio y

comunicación, su principal objetivo es el de estandarizar productos y seguridad para

organizaciones o empresas a nivel internacional.

IEC

La Comisión Electrónica Internacional IEC (International Electronic Comission), es una

organización que se encarga de la normalización en el campo eléctrico, electrónico y en

todas las tecnologías que se encuentren relacionadas, existen numerosas normas que se

elaboran conjuntamente con la ISO conocidas como normas ISO/IEC, como es el caso

de la norma ISO/IEC 12207.

Norma ISO/IEC 12207:2008

La norma ISO/IEC 12207:2008 la cual será tomada como referencia para elaborar el

estándar de aplicación de desarrollo de software, implanta un marco común para los

procesos de ciclo de vida de software, estableciendo dentro de estos procesos,

terminologías bien definidas que hacen referencia a la industria del software.

Propósito

El objetivo de la norma ISO/IEC 12207, es proporcionar un conjunto de procesos bien

definidos, que permitan facilitar la comunicación entre compradores, proveedores y

demás inmersos en el ciclo de vida del software.

Está escrita, encaminada a los adquirientes de sistemas, productos de software y

servicios, proveedores, desarrolladores, operadores, gerentes, directores de control de

calidad y usuarios.

Limitaciones

No detalla el ciclo de vida de los procesos, en términos de métodos o procedimientos

necesarios para cumplir con los requisitos y los resultados de un proceso.

No posee documentación detallada en términos de nombre, formato, contenido explícito

y medios de grabación, puede requerir de la elaboración de documentos adicionales de

características semejantes a la norma.

Conformidad

Uso Correcto

La aplicación de esta norma en general, consiste en seleccionar un conjunto de procesos

y adecuarlos para determinada organización o proyecto, en vista de que no en toda

organización o proyecto será necesaria la inclusión de todos los procesos establecidos

en la norma.

Existen dos formas en las cuales se puede afirmar que una implementación se ajusta a

esta norma.

Conformidad Completa

Se denomina una conformidad completa, cuando se demuestra que todos los procesos

establecidos por la norma, han sido satisfechos usando los resultados como evidencia
de esto.

Conformidad a la Medida

Se denomina conformidad a la medida, cuando esta norma utiliza como base un

conjunto de procesos específicos, y estos han sido satisfechos usando los resultados

como evidencia de esto.

Organización de la Norma ISO/IEC 12207:2008

Categorías del Proceso de Ciclo de Vida del Software

La ISO/IEC 12207:2008, agrupa las actividades que se pueden realizar durante el proceso

de ciclo de vida, de un sistema de software en siete (7) etapas, cada uno de estos grupos,

se describen en función del propósito y resultados que se desean obtener, se enumeran

las actividades y tareas que se deben seguir para el cumplimiento de dichos resultados.

➢ Procesos de Acuerdo.

➢ Procesos Organizativos de Habilitación del Proyecto.

➢ Procesos de Proyecto.

➢ Procesos Técnicos.

➢ Procesos de Implementación del Software.

➢ Procesos de Soporte de Software.

➢ Procesos de Reutilización del Software10

 Imagen 8

(Ciclo de Vida de los Procesos de Software de 12207)

 Imagen 9

(Selección de Elemento(s) de la Norma que se ajustan a necesidades de la Organización)

Estructura de los Procesos del Ciclo de Vida del Software según

la Norma ISO/IEC 12207

Los procesos de la Norma ISO/IEC 12207 están distribuidos de la siguiente manera:

Procesos del Contexto del sistema:

➢ Procesos de Acuerdo.

➢ Procesos de Proyecto.

➢ Procesos Técnicos.

Procesos Específicos del Software:

➢ SW. Procesos de Implementación.

➢ SW. Procesos de Apoyo.

Procesos de Reutilización del Software:

➢ Proceso de Ingeniería del Dominio.

➢ Proceso de Gestión de Reúso de Activos.

➢ Proceso de Gestión de Reúso del Programa.

 CMMI
Integración de modelos de madurez de capacidades o Capability Maturity Model Integration (CMMI) es
un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de
sistemas de software.

Imagen 10

•Creado como un marco (framework) para varias disciplinas relacionadas:

➢ Ingeniería de sistemas
➢ Ingeniería de software
➢ Desarrollo integrado de productos y procesos
➢ Control de proveedores
➢ No se requieren usar todas.
➢ Se espera agregar otras más adelante

•Dos tipos De moDelos:

➢ Continuo: útil para evaluaciones diferenciadas por proceso y comparaciones detalladas; permite
migración de EIA/IS 731 (Industria eléctrica); permite comparación con ISO/IEC 15504
➢ Por niveles: útil para comparación agregada; da resultado global que puede compararse con otras
empresas; ayuda a migrar desde SW-CMM

•CaDa moDelo tiene Cuatro áreas:

➢ Gestión de procesos
➢ Gestión de proyectos
➢ Soporte
➢ Ingeniería

•tiene metas espeCífiCas

•tiene práCtiCas espeCífiCas

Ingeniería de sistemas:

➢ Desarrollo de sistemas totales con o sin software. Transforma requerimientos del cliente en producto
que resuelva sus problemas y soporte durante su ciclo de vida.

Ingeniería de Software:

➢ Enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software

Desarrollo integrado de productos y procesos:

➢ Enfoque sistemático que logra la colaboración a tiempo de los principales involucrados a través de la
vida del producto. Debe usarse junto a un área de ingeniería.

Control de proveedores:

➢ Análisis de fuentes y monitoreo de proveedores antes de que entreguen los productos; sólo si es crítica la
adquisición.

Área de proceso:

➢ Conjunto de prácticas relacionadas en un área que, al realizarse, satisfacen un conjunto de metas

consideradas importantes para lograr mejoras significativas en el área.

Cada área de proceso:

•Componentes requeridas:

➢ Metas específicas

➢ Metas genéricas (soporte

➢ •Componentes esperadas:

➢ –Prácticas específicas

➢ –Prácticas genéricas
Niveles de capacidad:

Nivel 0 Incompleto:

➢ Una o más metas no se satisfacen; puede realizarse parcialmente o no realizarse del todo.

Nivel 1 Realizado:

➢ Todas las metas específicas se cumplen; permite y soporta la producción de productos de salida

bien identificados a partir de productos de entrada bien identificados.

➢ Realiza prácticas básicas.

Nivel 2 Administrado:

➢ Además de ejecutarse, se planeó y se ejecutó de acuerdo a política; emplea gente hábil, recursos

adecuados y salidas controladas; involucrados participan; monitoreado, controlado y revisado;

evaluado frente a descripción de proceso.

➢ Se satisfacen otrs metas como costo, calendario y aspectos de calidad.

➢ Realiza prácticas avanzadas.

Nivel 3 Definido:

➢ Se define a partir de procesos estandarizados de la empresa, usando guías de adaptación.

➢ Proceso definido: propósito; entradas; criterios de entrada; actividades; papeles; medidas; pasos de

verificación; salidas; criterios de salida.

Nivel 4 Administrado cuantitativamente:

➢ Se le controla usando métodos cuantitativos, especialmente con técnicas estadísticas.

➢ Calidad y rendimiento del proceso sujetos a metas cuantitativas.

Nivel 5 Optimizante:

➢ Se cambia y adapta para satisfacer objetivos de negocios relevantes, actuales y proyectados.

➢ Mejora continua analizando causas de variación en procesos.

Administración de procesos

➢ Enfoque de procesos organizacionales

➢ Definición de procesos organizacionales

➢ Entrenamiento organizacional

➢ Rendimiento de procesos organizacionales

➢ Innovasción y despliegue organizacionales

Administración de proyectos

➢ Planeación

➢ Monitoreo y control

➢ Administración de acuerdos con proveedores

➢ Administración de proyectos integrada

➢ Gestión de riesgo

➢ Control integrado de equipos

➢ Administración integrada de proveedores

➢ Administración cuantitativa del proyecto

 MOPROSOFT

Es un Modelo de Procesos de la industria de software conformado por un conjunto de buenas prácticas y

procesos de gestión e ingeniería de software, que contribuyen a que las organizaciones dedicadas al
desarrollo y mantenimiento de software mejoren su forma de trabajar y gestionar sus proyectos y por
consiguiente incrementar sus niveles de capacidad y competitividad tanto nacional como internacionalmente.

El Modelo MoProSoft Proporciona un conjunto de procesos integrados, con sus flujos de trabajo, roles y
productos, que pueden servir de marco de referencia para las empresas de la industria de software.

Imagen 11

El esquema MoProSoft permite a las pequeñas y medianas empresas que desarrollan software, demostrar
la capacidad de sus procesos y, con esto, hacerlas más competitivas, a fin de que tengan mayores
probabilidades de permanecer en el mercado.

Se trata de un estándar enfocado hacia una de las estrategias del Programa de Software (ProSoft) de la
Secretaría de Economía, relativa a “alcanzar niveles internacionales de capacidad de procesos” por parte de
las pequeñas y medianas empresas mexicanas desarrolladoras de software.

ORIGEN

Fue desarrollado por la Asociacion Mexicana para la calidad en ingeniería de software a través de la facultad
de ciencias de la Universidad Nacional Autonoma de Mexico(UNAM)

FUNCION

Mejora los procesos de desarrollo y su evaluación, y mantenimiento de sistemas y productos de

software.

OBJETIVO

Apoyar a las organizaciones en la estadarizacion de sus practicas, en la evaluación de su efectividad y

en la integración de la mejora continua.
Características

1. Es específico para el desarrollo y mantenimiento de software.

2. Facilita el cumplimiento de los requisitos de otros modelos como ISO 9000:2008 y CMMI.
3. Es sencillo de entender y adoptar.
4. Es práctico en su aplicación.
5. Comprende un documento de menos de 200 páginas que al compararlo con otros modelos y
estándares, lo hace bastante práctico.
6. Resulta acorde con la estructura de las organizaciones mexicanas con desarrollo o mantenimiento
de software.
7. Está orientado a mejorar los procesos, para contribuir a los objetivos de la organización, y no
simplemente ser un marco de referencia o dictaminación.
8. Tiene un bajo costo, tanto para su capacitación y, su adopción como para su evaluación.

Beneficios

1. Mejorar la calidad del software producido por la organización que adopta el modelo.
2. Elevar la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles
internacionales de competitividad.
3. Integrar todos los procesos de la organización y mantiene la alineación con los objetivos
estratégicos.
4. Reconocer a las organizaciones mexicanas por su nivel de madurez de procesos.
5. Obtener acceso a las prácticas de ingeniería de software de clase mundial.
6. Pertenecer a la Lista Nacional de Empresas Dictaminadas, que sirve como una referencia oficial
para clientes, autoridades y competidores
 1. Modelos de evaluación iso/iec 15504 ¿En qué consisten?

En la norma ISO 15504 tenemos la posibilidad de

afrontar la evaluación de procesos en una
organización bajo dos aproximaciones diferentes, pero
con los mismos elementos

• Evaluación por niveles de Madurez

• Evaluación por niveles de Capacidad

Los elementos que contienen ambos métodos son los

mismos lo que los diferencia es la forma de planificar

Imagen 12 la evaluación.
La evaluación por niveles de madurez realiza la
evaluación de procesos teniendo en cuenta la organización a nivel global teniendo en cuenta
su estructura (departamentos, proyectos etc.) y la evaluación por niveles de capacidad nos da
la flexibilidad de establecer uno o varios procesos específicos para crecer a través de él.

Imagen 13

Figura 1. Modelos de Evaluación según iso/iec 15504.

 EVALUACION POR NIVELES DE CAPACIDAD
El modelo de evaluación por niveles de capacidad nos permite establecer una puntuación
individual para cada proceso dentro de la organización de forma que podemos ir mejorando los
procesos en base a los niveles de capacidad obtenidos para cada uno de ellos.
Cada nivel de capacidad tiene unos atributos del proceso que a su vez se componen de una
serie de Componentes (de atributos del proceso). Estos elementos nos permiten medir o
evaluar una cualidad o característica de proceso que establece finalmente si el proceso ha
alcanzado el nivel de capacidad determinado.
Nivel de Capacidad = Cumplimiento de Atributos de un proceso con sus componentes

Imagen 14

Figura 2. evaluación por niveles de capacidad.

.

Los atributos del proceso son comunes para todos los procesos
Institucionalización del proceso en ISO 15504
El nivel de Capacidad alcanzado por un proceso determina finalmente si el proceso está o no
institucionalizado.
La institucionalización del proceso es un concepto que es fundamental para lograr la
implantación, aceptación y uso de las prácticas definidas en el proceso.
En el modelo ISO 15504 el proceso evoluciona pasando por diferentes etapas que permiten ir
alcanzando mejores niveles de aplicación. El logro de esos niveles se logra mediante la
aplicación de las metas y prácticas genéricas.

Nivel 5: Optimizado
El proceso se mejora continuamente para cumplir los objetivos del negocio actuales y futuro

Nivel 4: Predecible
El proceso se gestiona usando técnicas cuantitativas

Nivel 3: Establecido
Se utiliza un proceso adaptado basado en un proceso estándar

Nivel 2: Gestionado
El proceso se gestiona y los procesos de trabajo se establecen, controlan y mantienen.

Nivel 1: Realizado
Existe evidencia de la realización del proceso.

Nivel 0: Incompleto
El proceso no está implementado.
NIVELES DE CAPACIDAD
 MODELO DE EVALUACION POR NIVELES DE MADUREZ
Frente al modelo de crecimiento que podríamos llamar orgánico propuesto por el modelo
anterior esta forma de evaluar una organización globalmente mediante su nivel de madurez
que puntúa la organización entera sería equivalente a una filosofía de crecimiento corporativo.
En este modelo para alcanzar un nivel de madurez deberemos tener implantados una serie de
procesos predefinidos que acreditan si se quiere, que las distintas actividades de la
organización han alcanzado el nivel de madurez

Imagen 15

Figura 3. modelo de evaluación por niveles de madurez.

Los elementos de evaluación para los procesos son comunes al modelo anterior pues cada
proceso tendrá como criterio de evaluación de proceso el cumplimiento de los atributos de
proceso y los componentes de atributo
Este modelo por tanto establece un sistema de medición a nivel organizacional por lo que nos
permite tener un criterio más global que el anterior método por evaluación individual de
procesos.
 Nivel 5: Optimizado
La organización mejora continuamente los procesos para cumplir los
objetivos de negocio.

Nivel 4: Predecible
La organización gestiona cuantitativamente los procesos.

Nivel 3: Establecido
La organización utiliza procesos adaptados basados en estándares

Nivel 2: Gestionado
La organización gestiona los procesos y los productos de trabajo se
establecen, controlan y mantienen.

Nivel 1: Realizado
La organización implementa y alcanza los objetivos de los procesos.

Nivel 0: Incompleto
La organización no tiene una implementación efectiva de los
procesos.
Como se deduce de la figura los niveles de madurez se estructuran de forma escalonada por
lo que para alcanzar el nivel 3 por ejemplo se deberán tener implementado los procesos de los
niveles anteriores y así sucesivamente hasta el nivel 5
NIVEL 0
Este nivel se caracteriza porque no hay procesos definidos se alcanzan los objetivos solo en
base al esfuerzo de las personas. No se controlan los costes de producción ni hay capacidad
para predecir los resultados tanto en costes como en tiempos de respuesta.

NIVEL 1
En este nivel se es capaz de:

• Entregar productos de acuerdo a requisitos de clientes y requisitos de la organización

(partes interesadas) y requisitos técnicos
• No se controlan los resultados de los procesos, aunque se realizan actividades que
alcanzan su propósito

NIVEL 2
• Gestión de requisitos
• Planificación de proyectos
• Monitorización y control de proyectos
• Gestión de acuerdos con proveedores.
• Medición y análisis
• Aseguramiento de la calidad del producto y del proceso
• Gestión de la configuración

NIVEL 3
• Estandarización de procesos
• Diseño de arquitectura del Software
• Análisis de eficiencia de procesos y mejora
• Gestión de la decisión
• Integración del Software
• Verificación del Software
• Validación del Software
• Gestión de Infraestructuras
• Gestión de Recursos humanos
• Gestión de Riesgos
NIVEL 4
• Gestión cuantitativa de los proyectos.
• Entendimiento cuantitativo del rendimiento de los procesos de la organización.

NIVEL 5
• Análisis y resolución de causas de desviaciones.
• Innovación y despliegue a toda la organización
2. QUÉ ES EVALPROSOFT

El propósito de la herramienta de evaluación consiste en definir un método para obtener un

nivel de la capacidad de sus procesos y un nivel de madurez de capacidades de la
organización, tomando como referencia MOPROSOFT.
La evaluación de cada proceso con lleva a un examen disciplinado, el cual se apoya en una
escala, criterios de evaluación, conjunto de estándares mejores prácticas y un mecanismo
claro para exponer los resultados obtenidos.
En la tabla H se muestran las abreviaturas usadas por MOPROSOFT para diferenciar a
cada proceso.

Tabla H. Claves deMOPROSOFT.

Clave Proceso

GN Gestión de negocios

GPR Gestión de procesos

GPY Gestión de proyectos

GR Gestión de recursos

RHAT Recursos humanos y ambiente de

trabajo

BSI Bienes, servicios e infraestructura

CO Conocimiento de la organización

APE Administración de proyectos específicos

DMS Desarrollo y mantenimiento de software

TABLA 1
La nomenclatura utilizada parta describir cada proceso se describe a continuación:
Pr. An.PTm.

Donde:
Pr: se refiere a la clave con la que se identifica cada proceso. An: es la actividad
número n del proceso
PTm: es el producto de trabajo número m. Siendo n, t
y m números progresivos.
Se describe el proceso recursos humanos y ambiente de trabajo, actividad 2 y producto de
trabajo 1, usando la nomenclatura o clave queda de la siguiente forma. Ver tabla I.
 Tabla I. Claves de MOPROSOFT.

Clave Proceso

RHAT.A2.PT1 Registro de recursos humanos

TABLA 2

Una vez que tenemos identificados todos los procesos y codificados se le da el nombre al
producto de trabajo.
Los productos de trabajo son de suma importancia ya que de ellos depende la calificación
obtenida en conjunto para determinar la madurez del proceso y la capacidad de la
organización determinada con el nivel obtenido.
Un evaluador certificado tiene la capacidad para llevar a cabo la evaluación siguiendo el
proceso del método de evaluación EVALPROSOF.
El método de evaluación involucra al organismo rector que proporciona el paquete de
evaluación, resguarda la información y da seguimiento al método y a la organización a
evaluar, cuya relación se ilustra en la figura 4.

Al término del proceso de evaluación se entrega un reporte estadístico conteniendo las

evidencias documentadas que respaldan elcumplimiento de un atributo perteneciente al
producto los resultados finales.

La certificación tiene vigencia de sólo 2 años.

Reporte Reporte
estadístic de

Figura 4. Relación entre los elementos del método de evaluación.

Usos del método de evaluación

Tenemos tres distintosescenarios:

1. Evaluación de una organización, es cuando una organización solicita a un

evaluador certificado la realización de la evaluación para obtener un perfil del
nivel de capacidad de los procesos implantados y un nivel de madurez de
capacidades.

2. Evaluación de capacidades del proveedor, es cuando un cliente solicita a un

evaluador certificado la realización de una evaluación para seleccionar un
proveedor de desarrollo y mantenimiento de software.

El cliente elige los procesos a evaluar dependiendo del servicio a contratar.

3. Autoevaluación de capacidades de proceso, es cuando una organización

realiza una evaluación por personal interno o externo que no necesariamente
sea evaluador
 Descripción general del método de evaluación

“El modelo de capacidades, que se utiliza para calificar el nivel de capacidad de los
procesos, está basado en la Parte 03: Modelo de capacidades de procesos.”1 Ver
figura5.

Donde se tiene cada uno de los procesos, los cuales son medidos apartir de una escala de
acuerdo al cumplimiento de cada atributo, obteniendo así un nivel de capacidad de
procesos, posicionándolo en una escala, el cual determina el nivel de la organización.

Imagen 16

Figura 5. Modelo de capacidades.

El método de evaluación determina el cumplimiento de los atributos de los procesos ya

implantados en la organización y otorga la calificación del nivel de capacidad por cada
proceso y un nivel de madurez de capacidades.
1 OktabaHanna, et al. Método de Evaluación de procesos para la industria de software EvalProSoft. Secretaria
de Economía, México, 2004, pág
 Modelo de capacidades de procesos

La capacidad de proceso se evalúa en una escala de 0 a 5.

El 0 se asocia al nivel más bajo, lo que significa que no alcanza el propósito del proceso.

El 5 se asocia al nivel más alto demostrando el cumplimiento y alcanzando todas las metas.

Esta medición de capacidad se obtiene de un conjunto de atributos que miden un aspecto

en particular de procesos determinados por este modelo, los cuales son indicadores de que
el proceso ha alcanzado una capacidad.

Los niveles de capacidad y atributos que considera EVALPROSOFT por

cada uno de los nueve procesos se muestran en la figura 6.

Imagen 17

Figura 6. Niveles de capacidad.

Niveles de capacidad de procesos

Nivel 0 Proceso incompleto

❖ No se cumple con el propósito del proceso.

❖ Poca o nula evidencia de algún proceso llevado a cabo para

cumplir con dicho objetivo.

Citando el ejemplo anterior sobre la fabricación del sistema en el tema 2.3, donde el propósito
es diseñar un sistema para llevar el control de una compañía donde su fin es generar los
números de reportes para la atención de multifuncionales con fallas en sitio.

Además de mostrar y ordenar la información por grupos pertenecientes a cada coordinador

de cada estado de la República Mexicana, mostrar datos de serie del equipo, modelo,
domicilio, falla, números de reporte tanto para el cliente como para servicio técnico.

En el nivel 0 aún no se tienen la capacidad para generar los reportes completos, hay
deficiencias debido a que no están dados de alta las series, no están dados de alta todos
los grupos de las localidades atendidas, no aparecen las nominas de cada ingeniero de
servicio, no hay campos para documentar los medidores de cada equipo.

Se omiten algunas actividades en el proceso o tienen deficiencias, por otra parte depende de
la experiencia del encargado de generar el proceso en este caso los reportes, pero se tiene
un producto.

El sistema es muy lento y se presentan mensajes de error, se duplican los reportes, el tiempo
empleado para la generación de estos es máximo a 20 minutos.
Nivel 1 Proceso realizado

El proceso se implementa y alcanza su propósito.

Aquí ya se alcanza el propósito del proceso, ya se generan los números de reportes sin embargo
puede o no estar totalmente completo.
Se obtiene el producto de dicho proceso el cual, es un indicativo del cumplimiento del objetivo.

Aún que se obtengan los productos finales al 100% son evidencia de que se realiza el
proceso, más no es suficiente pues en algunos reportes falta ya sea el grupo, nombre del
coordinador o la actualización de la garantía de cada equipo, la nomina de algún ingeniero
y deben de contribuir a alcanzar el propósito del proceso.

En este nivel se realizan todas las actividades obteniéndose así los productos finales
(reportes). Aún no se tiene el control de todo el proceso, pues los generadores de reportes no
siguen un patrón establecido omiten pasos y no llevan una secuencia como se debería.

P.A. 1.1 Atributo de la realización del proceso

El proceso en este nivel ya está definido. Se sigue una secuencia con la finalidad de
obtener el reporte para su seguimiento.

Nivel 2 Proceso administrado

El proceso realizado se administra sus productos de trabajo están

establecidos controlados ymantenidos.

El proceso realizado en al nivel 1 se implanta de manera administrada o gestionada

(haciendo una planeación, monitoreo y ajustes necesarios) haciendo que en este nivel se
administren tanto el proceso y los productos de trabajo.

P.A. 2.1 Administración de la realización

Ya se definen y asignan responsabilidades para llevar a cabo el proceso. Se identifican los

objetivos para cumplir con lo planeado.
P.A. 2.2 Administración del producto de trabajo

El encargado de realizar los productos ya sigue un estándar definido el cual es

supervisado.

El proceso es gestionado, y los productos ya se establecen, controlan y mantienen.

En el nivel 2 ya se administra tanto el proceso como los productos de trabajo.

Sin embargo la obtención del producto depende de la experiencia del encargado de

generar el proceso.

Cada encargado sigue los procesos para generar los reportes adecuadamente y completos,
se supervisa cada reporte generado para determinar fallas delsistema.

Los reportes se generan y pueden llevarse un tiempo estimado entre 10 y 15 minutos.

Nivel 3 Proceso establecido

El proceso se realiza y gestiona, se implementan por medio de una serie de pasos definidos
yaestandarizados.

El proceso administrado es implementado individualmente con el proceso definido, siguiendo

estándares ya aprobados, revisados y documentados.

Para todo el personal encargado de la generación de reportes dentro de la compañía, se

sigue el mismo proceso y con una secuencia para no omitir datos y llenar campos en el
sistema manualmente, así se evita perder tiempo en la generación del reporte al corregir erres
por omisión de datos, reduciéndolo hasta en 10 minutos.

Ahora sí, se generan los reportes de manera consistente. Ya se puede planear y controlar
con precisión.

3.1 Atributo definición del proceso

Ya se establece la implementación del proceso estandarizado para soportar un despliegue

del proceso ya definido.
 Como resultado:

❖ Se define un proceso estándar, con guías de adaptación para incorporarlas

al proceso definido que ayudaran a la realización del producto requerido.

❖ Se identifican roles, es decir la función de la persona encargada de la

obtención del producto final para la realización del proceso.

❖ Se identifica la estructura y el lugar de trabajo necesarios para la obtención

del proceso solicitado y requerido por el cliente final.

El proceso estándar de una organización incluye:

❖ Políticas, procedimientos y estándares para la realización del

proceso.

❖ Modelos de ciclos de vida para su uso en la organización.

❖ Guías para la adaptación del proceso.

❖ Repositorio de datos y experiencias relacionadas con el proceso estándar.

3.2 Atributo aplicación del proceso

Es una medida de cuánto se implementa /despliega efectivamente el proceso estándar

como proceso para alcanzar sus salidas del proceso.

Como resultado del alcance de este atributo tenemos:

❖ Se implementan procesos definidos apropiados del proceso

estándar.

❖ Se asignan roles y actividades para realizar el proceso definido.

❖ El personal que realiza el proceso definido es competente.

 ❖ Se dispone de recursos e información necesaria para llevar a cabo el proceso
definido.

❖ Se mantiene la infraestructura y entorno de trabajo.

❖ Se recolectan y analizan datos para comprender el

comportamiento del proceso definido.

Ya se genera el producto, ya está controlado por lo que el producto obtenido ya es uniforme

o bien cumplen con todas las características solicitadas.

Nivel 4 Proceso predecible

El proceso establecido opera bajo límites de alcance

En este nivel ya el proceso opera dentro de ciertos límites para cubrir con el objetivo y alcanzar
los resultados.

Los encargados de generar los reportes deben de contar con la experiencia necesaria para
evitar errores y falta de información, obteniendo los reportes cada 5 minutos, se alcanzan
los objetivos solicitados reduciendo el tiempo, costo y calidad del producto solicitado.

El sistema el cual nos sirve de herramienta para la generación de reportes ya no es lento, no

hay falta de información ingresada en la base de datos para cumplir con el objetivo del
producto, los recursos son adecuados para correr la aplicación.

Se cuenta con la suficiente memoria para almacenar datos y consultarla en cualquier

momento.

4.1. Atributo medición del proceso

Los resultados obtenidos son medidos para asegurar que la realización del proceso alcanza
los objetivos relevantes de realización del mismo, en soporte a los objetivos de negocios
definidos.

Como resultados de este atributo:

❖ Se establecen necesidades de información del proceso en soporte a los

objetivos de la organización.
 ❖ Se establecen objetivos cuantitativos para la realización de los procesos en
soporte a los objetivos del negocio relevantes.

❖ Se identifican y definen las medidas y frecuencias de medidas con los

objetivos de medida de procesos y los objetivos cuantitativos de realización
de losprocesos.

❖ Se recolectan, analizan y se informa para conocer el grado en el que se

cumplen los objetivos cuantitativos de realización de los procesos.

4.2. Atributo control del proceso

Este atributo es una medida de cuánto se gestiona cuantitativamente el proceso para

producir un proceso estable, capaz y predecible en los límites definidos paraél.

Como resultado:

❖ Se determinan técnicas de análisis y de control.

❖ Se establecen límites de control para la realización normal de los procesos.

❖ Se analizan los datos medidos.

❖ Se toman acciones correctoras para tratar las causas de variación

especiales.

Nivel 5 Proceso optimizado

El proceso predecible se mejora continuamente.

Existe una mejora continua en el proceso para lograr las metas del negocio actuales y futuras.

En cuanto a la generación de reportes ya está establecido el proceso, ya se puede pensar

en otro tipo de reportes para poder documentar las visitas o para llevar al control de algún
equipo que requiera de piezas para su reparación, etc.
 El sistema no presenta fallas, es eficiente y rápido, los recursos tienen un buen
funcionamiento, ya que son los adecuados para correr la aplicación, el tiempo estimado en
generar el reporte es de 3 a 5 minutos. No se tiene falla alguna.

Cuando se tienen las calificaciones para cada atributo para un proceso en específico, ya se
tiene el perfil del proceso, el cual define el nivel de capacidad de éste.

5.1. Atributo innovación del proceso

Se refiere a un enfoque proactivo en cuanto a la mejora continua para cumplir los objetivos
de las organizaciones y proyectos.

El haber definidos los objetivos de mejora proporciona una base para el nivel 5 de
capacidad.

Al alcanzar este atributo:

❖ Se definen objetivos de mejora de procesos.

❖ Se analizan los datos y se identifican cuáles son las causas en la variación

de la realización de los procesos.

❖ Se identifican oportunidades de mejora que se derivan de nuevas

tecnologías y nuevos conceptos de procesos.

❖ Se establece una estrategia para alcanzar los objetivos de mejora de los

procesos.

5.2. Atributo de optimización del proceso

Se refiere a la identificación de cambios al proceso que son introducidos para minimizar la

no deseada interrupción de la operación del proceso.

Como resultado de este atributo:

❖ Se evalúa el impacto de los cambios propuestos frente a objetivos de los

procesos identificados y procesos estándar.
 ❖ Se gestiona la implementación de todos los cambios para evitar cualquier
interrupción.
❖ Se evalúa la efectividad del cambio del proceso con base en la relación actual
frente a los requisitos definidos para los procesos y los objetivos de los
procesos y así determinar a qué se deben los resultados.

La evaluación final engloba un conjunto de perfiles de capacidad de los 9 procesos que

corresponden a cada proceso evaluado.

CALIFICACIÓN DE LOS PROCESOS

La combinación de las calificaciones de los atributos, determina la capacidad de cada

proceso para generar los productos y en conjunto determinan la madurez de la organización
al ser evaluada.

La evaluación se realiza por cada uno de los nueve procesos. A nivel organizacional el nivel
de madurez se define como el máximo nivel de capacidad alcanzado por todos los
procesos.

Así mismo se apoyan de plantillas para calificar cada proceso, en las cuales se califican
cada uno de los atributos de ese proceso en específico.

Las calificaciones de cada proceso se determinan de acuerdo a los siguientes cuatro

lineamientos.

N – No alcanzado. Va del 0% AL 15%. Hay poca documentación, no hay o

hay muy poca evidencia del alcance en el atributo definido del proceso
evaluado.

❖ P – Parcialmente alcanzado. Del 16% a un 50% de alcance. Se dice que si

hay una evidencia y un alcance del atributo definido.

❖ L – Ampliamente alcanzado. Del 51% al 85% de alcance. Existe un enfoque

sistemático y un alcance significativo del atributo definido.

❖ F – Totalmente alcanzado. Desde un 86% al 100% ya se tiene una evidencia

de un enfoque completo y sistemático, y ya se alcanza por completo el
atributo definido, no existen debilidades significativas en la realización del
proceso.
Las calificaciones se registran en cualquier formato. Siempre y cuando se muestre la
calificación de cada atributo calificado. Ver tabla J.

Se obtienen calificaciones para cada proceso de acuerdo al

cumplimiento de susatributos.

Si:
N=0
P=1
L=2
F=3

Tabla J. Calificaciones de atributos.

Atributo 1.1 2.1 2.2 3.1 3.2 4.1 4.2 5.1

Calificación F L F L L F P P

TABLA 3

De acuerdo a la escala, la calificación para el nivel del ejemplo de la tabla anterior nos da
como resultado:

El proceso es: Ampliamente alcanzado, esto se obtuvo aplicando una regla de tres tomando
que 27 en el total de F que es el máximo para cada proceso tendremos así un 74%.

TABLA 4

Atributo 1.1 2.1 2.2 3.1 3.2 4.1 4.2 5.1 5.2

Calificación F L F L L F P P F

Máximo 27 3 2 3 2 2 3 1 1 3

Total 20 74 % Ampliamente alcanzado

No podemos avanzar a un nivel 1 si aún no tenemos el 100% de los productos cumplidos
por cada proceso, hasta que cada proceso tenga el valor de 3.

En otro ejemplo se muestran las calificaciones de los nueve procesos donde la organización
ya se cumplió con un nivel 1 al ver que cada proceso tiene la máxima calificación obtenida
F y también abarca en su totalidad el nivel administrado, excepto por dos procesos los
cuales no se han cubierto del todo, por tanto no se puede contar con un nivel 2 administrado
hasta que se cumplan al 100 %.

Se debe poner mayor atención en los procesos correspondientes a la Gestión de procesos

y administración de proyectos específicos. Ver figura 7.

TABLA 5. Calificación por proceso.

A continuación se describe el proceso llevado a cabo en la evaluación por EVALPROSOFT,
para determinar el nivel de la organización al evaluar sus procesos y determinar su
capacidad para generar el producto de software.

PROCESO DE EVALUACIÓN
Consta de 5 etapas, las cuales se detallan a continuación en la figura 8.

La evaluación debe de contar con los procesos documentados, para cubrir los objetivos
de ésta.

Recolección

Proceso de evaluación.

Etapa 1. Planificación

Verificar entradas y salidas, calendarios registros de responsabilidades.

En esta etapa se definen las actividades que se llevaran a cabo para la evaluación, se hace
una selección para definir las actividades de los participantes en la evaluación, así como
también los criterios para verificar que se han cumplido los requisitos. Ver figura 9.

Etapa de planificación.
Etapa 2. Recolección de datos

Se obtendrán los datos registrados para verificar resultados.

Se hace una recolección de los datos que se requieren para la evaluación de cada
proceso de una manera sistemática.

Se establece una estrategia y técnica para la selección, recolección, análisis de datos y

justificación de las calificaciones. Con esto se obtiene una evidencia objetiva para cada
proceso evaluado. Ver figura 10.

La mayoría de los métodos aplicados incluyen:

❖ Establecimiento del contexto de la organización.

❖ Se realiza un estudio inicial de la organización.
❖ Realización de entrevistas iníciales.
❖ Entrevistas de refuerzo.
❖ Estudio de la documentación del refuerzo.

Recolección

Etapa de recolección de datos.

Etapa 3. Validación de datos

Como su nombre lo dice, se debe validar toda la información recabada, revisar que los
datos sean consistentes y representativos.

Se juntan todos los datos obtenidos para consolidarlos y hacer su respectiva validación de
los mismos. Ver figura 11.

Etapa de validación de datos

Etapa 4. Calificación de los atributos de los procesos

Se le asigna una calificación para cada atributo de los procesos analizados, basándose en
los datos ya validados, donde cada calificación se expresa de acuerdo a N, P, A, o C. Ver
figura 12.

Calificación de atributos de los procesos.

Etapa 5. Informe

Se generan reportes, los cuales se proporcionan al promotor de la evaluación. Ver figura

13.

Se realiza un informe de evaluación de la situación actual de la organización, preparada por

el evaluador, el cual tiene la obligación de presentarlo ante los participantes y al área
directiva de la organización.

Calificación de atributos de los procesos.

Después de evaluar la organización, se entregan los siguientes documentos contenidos en la

tabla K.
 Tabla K. Etapas del proceso de evaluación.

Etapa Nombre del documento Contenido

1 Propósito de auditoría Qué persigue y qué debe calificarse para el proceso

1 Alcance de auditoría Identificar la profundidad de la revisión

1 Programa de auditoría Actividades específicas que se revisarán

✓ Documentos Aplicables. Documentos de la

organización se anticipa que contengan la
información a revisar

✓ Equipo auditor. Nombres y firmas de los

responsables de la ejecución de la auditoría

✓ Participantes. Grupo de la organización

responsables de actividades a realizar

✓ Firma autorizada de aprobación

✓ Lista de verificación del auditor

✓ Calendario detallado de las actividades

2 Métodos de recolección de Cuestionarios

datos Plantillas de entrevistas
Especificación de la revisión documental
Definición de encuestas
Técnicas de muestreo
Matriz de doble entrada, requisitos y evidencias

3 Informe de auditoría Narrativa detallada de hallazgos y ubicación del hallazgo

Buenas práctica

4 Resumen general de auditoría Narrativa resumida de hallazgos y logros significativos y

métodos utilizados

5 Cierre de auditorias Dictamen formal de auditoría

Como anexos: plan de auditoría, listas de verificación llenas,
informe de auditoría y plan de acciones correctivas
RESULTADOS DE LA EVALUACIÓN

El reporte final de la evaluación, se entrega a la organización y contiene la siguiente

información:

Nombre de la organización evaluada.

Nombre del promotor y su rol dentro de la organización.

Nombre del evaluador certificado, equipo de evaluación y sus roles dentro de la

evaluación.

Versión del método de evaluación.

Procesos evaluados.

Fechas de la evaluación.

Tabla de perfiles de calificaciones de atributos de cada proceso evaluado.

Perfil del nivel de capacidad de los procesos implantados y un nivel de madurez de

capacidades. Resumen de hallazgos detectados para cada proceso.

Resumen de hallazgos que aplican a varios procesos.

Hallazgos que no están directamente relacionadas con la parte 01: Requisitos de

procesos, pero que afectan a la implantación.

Adicionalmente, el evaluador certificado elabora y entrega al organismo rector el reporte

estadístico de la evaluación que contiene la siguiente información:

• Tipo de evaluación.

• Versión del método de evaluación.

• Fechas de la evaluación.

• Datos de la organización evaluada.

 • Unidades administrativas de la organización evaluadas.

• Datos del promotor.

• Datos del evaluador certificado.

• Datos del representante de la organización.

• Datos del facilitador.

• Equipo de evaluación.

• Participantes entrevistados.

• Resumen de resultados de la evaluación.

• Grado de apego al proceso de evaluación.

• Lecciones aprendidas sobre el método de evaluación y la parte 01: Requisitos de

procesos.

• Documentos a ser enviados al organismo rector.

Ya se describió el proceso llevado a cabo para determinar el nivel de cada organización, el

cual es importante ya que nos mostrará la madurez de los procesos y el estado o avance de
una organización para ayudar a mejorar el producto en cuestión, así como también a
controlarlo y pensar en innovaciones y mejora continua.
“La relación entre el proceso de software y los métodos aplicados para la evaluación y el
mejoramiento se muestra en la figura 14.”

Mejoramiento del Determinación de

Motiva la capacidad
proceso de software

Evaluación de procesos.

Cuando se obtiene una certificación bajo la norma, se demuestra que una empresa ya es
capaz de optimizar sus procesos, buscar una mejora continua, destacar sobre sus
competidores y proporcionar para los clientes productos de software de calidad.

Sabemos ahora que cuando una empresa tiene una capacidad de nivel 1 indica que tiene
un orden y una disciplina para llevar a cabo los procesos y obtiene lo que se compromete, las
actividades de las empresas ya se documentan con esta fortaleza se puede competir y con
empresas que no llevan un buencontrol.

2
Pressman S. Roger; Ingeniería de Software; McGraw-Hill, 6ta. edición. México, 2005, pág. 37.
 Una empresa de nivel 2, además de cumplir totalmente con el nivel 1 ya es capaz de
cumplir con el tiempo y costo planeados, ya existe una planificación se supervisa y
corrigen errores encontrados.

Se tiene una base de conocimiento con información valiosa que permite tener
oportunidades de mejora, con todo esto se o puede cumplir con empresas de nivel
1 o nivel 0.

La capacidad 3 de una empresa en este nivel tiene una manera uniforme de trabajo
al seguir un estándar, ya que todo está documentado para seguir la línea y obtener
un producto uniforme, consistente y confiable a lo largo de susprocesos.

En un nivel 4 la empresa cumple con sus proyectos apoyados en procesos

estandarizados, permitiendo predecir las causas que originan problemas en manera
masiva, se puede vencer a las empresas con nivel 1, nivel 2 y nivel 3.

Alcanzar el nivel 5 nos indica que hay un proceso de mejora implantado en sus
procesos y proyectos, se pueden buscar innovaciones para competir con una mejor
estrategia.

El esfuerzo en grupo de cada participante logra la obtención de un nivel al cumplir con

las documentaciones de todos los productos y actividades, las cuales son importantes
para saber la causa del error agrupándola en una base.

La base de conocimiento puede ser consultada las veces que se requieran para dar
respuestas oportunas a algún problema, de aquí la importancia para documentar
según el patrón propuesto por MOPROSOFT, aunque cada empresa puede usar sus
plantillas siempre y cuando contengan los puntos importantes de cada proceso.

Todo proyecto para ser exitoso debe estar organizado, y en el caso de no aplicar
metodologías para organizar los procesos, y llevar una perfecta documentación del
proyecto que se está ejecutando podría caer en el caos y también fracasar, por eso
es de gran importancia la aplicación de normas. Es muy importante que si se está
recién comenzando y no se tiene mucho personal y es una empresa muy pequeña,
pudiera empezar por analizar cómo está llevando sus procesos, cómo está
organizada, para luego, cuando siga creciendo, aplicar estas metodologías.

Bibliografía
 ➢ https://okhosting.com/blog/el-ciclo-de-vida-del-software/

➢ http://www.ciens.ucv.ve:8080/genasig/sites/disist/archivos/clase6.pdf

➢ http://calidadenlossi-norasolis.blogspot.com/2017/07/43-moprosoft.html

➢ https://www.nyce.org.mx/moprosoft-nyce/

➢ https://repositorio.espe.edu.ec/bitstream/21000/4275/1/T-ESPE-032633.pdf

➢ http://sedici.unlp.edu.ar/bitstream/handle/10915/4009/Presentaci%C3%B3n_.pdf-
PDFA.pdf?sequence=5

➢ https://repositorioacademico.upc.edu.pe/bitstream/handle/10757/273687/JD%C3
%ADaz.pdf?sequence=1

BIBLIOGRAFIA DE IMAGENES
IMAGEN 1
http://sistemasinformaticosadsi.blogspot.com/2013/03/procesos-de-
software.html

IMAGEN 2
https://gestiondeproyectosprocesos.wordpress.com/

IMAGEN 3
https://okhosting.com/blog/el-ciclo-de-vida-del-software/

IMAGEN 4
https://okhosting.com/blog/el-ciclo-de-vida-del-software/

IMAGEN 5
http://www.ciens.ucv.ve:8080/genasig/sites/disist/archivos/clase6.pdf

IMAGEN 6
http://www.ciens.ucv.ve:8080/genasig/sites/disist/archivos/clase6.pdf

IMAGEN 7
http://ingertec.com/iso-15504/iso-iec-12207/

IMAGEN 8
https://repositorio.espe.edu.ec/bitstream/21000/4275/3/T-ESPE-032633-
A.pdf

IMAGEN 9
https://repositorioacademico.upc.edu.pe/bitstream/handle/10757/273687/
JD%C3%ADaz.pdf?sequence=1

IMAGEN 10
http://isoglob.in/product_portfolio.php

IMAGEN 11
http://calidadenlossi-norasolis.blogspot.com/2017/07/43-moprosoft.html

IMAGEN 12
http://ingertec.com/iso-15504/modelos-de-evaluacion

IMAGEN 13
http://ingertec.com/iso-15504/modelos-de-evaluacion
IMAGEN 14
https://repositorio.espe.edu.ec/bitstream/21000/4275/1/T-ESPE-
032633.pdf

IMAGEN 15
http://ingertec.com/iso-15504/modelos-de-evaluacion

IMAGEN 16
https://repositorioacademico.upc.edu.pe/bitstream/handle/10757/273687/
JD%C3%ADaz.pdf?sequence=1

IMAGEN 17
http://www.ptolomeo.unam.mx:8080/xmlui/bitstream/handle/132.248.52.1
00/180/A6.pdf?sequence=6