INSTITUTO TECNOLÓGICO SUPERIOR P´URHÉPECHA

Ingeniería en Sistemas Computacionales

Fundamentos de Ingeniería de Software.
MCTC. Juvenal Alejandro Espinosa Barragán.

INGENIERÍA EN SISTEMAS COMPUTACIONALES

MCTC. JUVENAL ALEJANDRO ESPINOSA B.

FUNDAMENTOS DE INGENIERÍA DE SOFTWARE

UNIDAD 5: CALIDAD DE SOFTWARE.

INVESTIGACIONES

SANTIAGO ANGEL CORTEZ

QUINTO SEMESTRE ICHAN, MICH.

sack.23@live.com.mx

1
 CONTENIDO

Unidad 5 (5.1 Definición de calidad) ................................................................................................... 3

5.2 Importancia de la calidad. ......................................................................................................... 3

5.3 Factores de calidad. .................................................................................................................. 4

5.4 Aseguramiento de la calidad .................................................................................................... 6

5.4 Aseguramiento de la calidad .................................................................................................... 7

5.5 Estándares y métricas de calidad ........................................................................................... 8

5.6 Modelos de madurez ............................................................................................................... 10

5.6.1 Enfoque de procesos ........................................................................................................... 12

5.6.2 PSP y TSP ............................................................................................................................. 14

5.6.3 SPICE ..................................................................................................................................... 16

5.6.4 CMMI ...................................................................................................................................... 19

5.6.5 MoProSoft .............................................................................................................................. 21

2
Unidad 5 (5.1 Definición de calidad)
Calidad
La calidad es una herramienta básica e importante para una propiedad inherente
de cualquier cosa que permite que la misma sea comparada con cualquier otra de
su misma especie. La palabra calidad tiene múltiples significados. De forma básica,
se refiere al conjunto de propiedades inherentes a un objeto que le confieren
capacidad para satisfacer necesidades implícitas o explícitas. Por otro lado, la
calidad de un producto o servicio es la percepción que el cliente tiene del mismo, es
una fijación mental del consumidor que asume conformidad con dicho producto o
servicio y la capacidad del mismo para satisfacer sus necesidades. Por tanto, debe
definirse en el contexto que se esté considerando, por ejemplo, la calidad
del servicio postal, del servicio dental, del producto, de vida, etc.

5.2 Importancia de la calidad.

DEFINICIÓN DE LA CALIDAD DE SOFTWARE

Primeramente definimos la calidad relacionado al desarrollo de software. Según

Pressman la calidad del software es “la concordancia con los requisitos funcionales
y de rendimiento explícitamente establecidos, con los estándares de desarrollo
explícitamente documentados y con las características implícitas que se espera de
todo software desarrollado profesionalmente”. Según el Departamento de
Defensa de los Estados Unidos es la capacidad de un producto software para
satisfacer sus requerimientos específicos. Se define como la capacidad del producto
de software para permitirles a usuarios específicos lograr las metas propuestas con
eficacia, productividad, seguridad y satisfacción, en contextos especificados de uso.
Se considera como la totalidad de las características de un producto o servicio que
le confieren su aptitud para satisfacer unas necesidades expresadas o implícitas por
Norma UNE 66-001-92 traducción de ISO 8402. La calidad del software la obtención
de un software con calidad implica la utilización de metodologías o procedimientos
estándares para el análisis, diseño, programación y prueba del software que
permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad,
mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para
la labor de desarrollo como para el control de la calidad del software. Del mismo
modo se define de las maneras siguientes:

3
1.- La totalidad de las funciones y características de un producto software que
influyen en su capacidad de satisfacer determinadas necesidades; por ejemplo, el
cumplimiento de las especificaciones.

2.- El grado en el que el software posee una combinación de atributos deseada.

3.- El grado en el que un cliente o usuario percibe que el software satisface sus
expectativas globales.
4.- Aquellas características globales del software que determinan el grado en el que
el software que se está utilizando satisfará las expectativas del cliente.

5.3 Factores de calidad.

Factores de calidad
Entre los factores que Determinan la Calidad existen dos tipos de factores:
 Factores que pueden ser medidos directamente (errores/KLDC/unidad de
tiempo).
 Factores que solo pueden ser medidos indirectamente (la facilidad de uso o
de mantenimiento).
En ambos casos se puede medir la calidad, debemos comparar el software
(documentos, programas, etc.) con alguna referencia y llegar a una indicación de
calidad.

Factores de Calidad según McCall

PUNTO DE VISTA FACTOR
REVISIÓN DEL Mantenibilidad
PRODUCTO Flexibilidad
Testeabilidad
TRANSICIÓN DEL Portabilidad
PRODUCTO Reusabilidad
Interoperabilidad
OPERACIÓN DEL Correctitud
PRODUCTO Confiabilidad
Eficiencia
Integridad
Usabilidad

4
Factores de Calidad según Boehm

El modelo que presenta Boehm presenta una jerarquía de características donde

cada una de ellas contribuye a la calidad global. Dentro de los factores que se
describen en el modelo se toman muchos de los que propone McCall. Parte de la
estructura del modelo de Boehm se presenta en la siguiente figura, se hace énfasis
en los factores presentes en dicho modelo. En total el modelo de Boehm presenta
siete factores:

Factores de Calidad según ISO 9126

Es un modelo jerárquico con seis atributos especiales.

5
5.4 Aseguramiento de la calidad

Aseguramiento de la calidad
Las normas ISO 9000 establecen que el aseguramiento de la calidad son todas las
acciones sistemáticas y planificadas, necesarias para proporcionar una confianza
adecuada de que un producto o servicio satisfaga los requisitos dados de calidad.
Para conseguir, mantener y mejorar la calidad, las organizaciones desarrollan y
utilizan su Sistema de Calidad. Estos sistemas de calidad deben diseñarse de
acuerdo con ISO 9004 y evaluarse de acuerdo con la norma apropiada, que en el
caso del software es ISO 9001.
Los productos no pueden cumplir los estándares ISO 9001, las organizaciones si, y
eso es lo que se pretende: garantizar el uso de un sistema de calidad por el cual se
asegura que el proceso de fabricación del software cumple los requisitos
establecidos por la calidad.
Los sistemas de calidad pueden establecer la necesidad de confeccionar y cumplir
el sistema de calidad del proyecto, de modo que cada uno en particular se regirá
por las normas establecidas en el propio sistema del proyecto. Básicamente un
sistema de calidad se compone de:
 El programa de garantía de calidad: Documentación en el que se establece
la política de aseguramiento de la calidad, de acuerdo con las direcciones y
estrategias de la organización.
 Manuales de normas y procedimientos: Comprenden el manual de
organización, los manuales de administración, producción, etc., los cuales
regulan las actividades que afectan a la calidad de los productos, asignando
responsabilidades y describiendo las técnicas aplicables.
Estos dos componentes básicos del sistema (programa y manual) se complementan
para facilitar su integración con las actividades propias del desarrollo del proyecto.

6
5.4 Aseguramiento de la calidad

Aseguramiento de la calidad
Las normas ISO 9000 establecen que el aseguramiento de la calidad son todas las
acciones sistemáticas y planificadas, necesarias para proporcionar una confianza
adecuada de que un producto o servicio satisfaga los requisitos dados de calidad.
Para conseguir, mantener y mejorar la calidad, las organizaciones desarrollan y
utilizan su Sistema de Calidad. Estos sistemas de calidad deben diseñarse de
acuerdo con ISO 9004 y evaluarse de acuerdo con la norma apropiada, que en el
caso del software es ISO 9001.
Los productos no pueden cumplir los estándares ISO 9001, las organizaciones si, y
eso es lo que se pretende: garantizar el uso de un sistema de calidad por el cual se
asegura que el proceso de fabricación del software cumple los requisitos
establecidos por la calidad.
Los sistemas de calidad pueden establecer la necesidad de confeccionar y cumplir
el sistema de calidad del proyecto, de modo que cada uno en particular se regirá
por las normas establecidas en el propio sistema del proyecto. Básicamente un
sistema de calidad se compone de:
 El programa de garantía de calidad: Documentación en el que se establece
la política de aseguramiento de la calidad, de acuerdo con las direcciones y
estrategias de la organización.
 Manuales de normas y procedimientos: Comprenden el manual de
organización, los manuales de administración, producción, etc., los cuales
regulan las actividades que afectan a la calidad de los productos, asignando
responsabilidades y describiendo las técnicas aplicables.
Estos dos componentes básicos del sistema (programa y manual) se complementan
para facilitar su integración con las actividades propias del desarrollo del proyecto.

7
5.5 Estándares y métricas de calidad

Estándares y métricas de calidad

ESTÁNDARES
Los estándares de calidad de software son normas emitidas por organismos
específicos, que sirven para sentar un marco con el que comparar si un proceso
de desarrollo es o no de calidad. Las normas de calidad del software más
conocidas han sido desarrolladas por ISO, y son la serie ISO-9000.
1.-ISO 9000
Las normas ISO-9000 son un estándar de calidad para todo tipo de industrias;
contiene una normativa específica para el desarrollo de software, la ISO-9003.
Consiste en una serie de cláusulas que deben aplicarse en el marco de trabajo,
en el ciclo de vida del proyecto y en las actividades de apoyo al mismo.
2.-CMMI
CMM fue desarrollado por el Software Engineering Institute en estados unidos,
sirve para comprobar la habilidad de los procesos de las organizaciones para
realizar determinados proyectos.
3.-SPICE
SPCE es el modelo de madurez propuesto por ISO, similar a CMMI.
-Factores de calidad
Los factores de calidad sirven para descomponer el concepto genérico de
“calidad”; para facilitar su control y su medición. Se clasifican en:
1)Factores operativos
Los factores operativos son aquellos que afectan al uso del software.
2)Factores de mantenimiento
Los factores de mantenimiento son aquellos que se aplican a la capacidad de
modificación del software.
3)Factores evolutivos
Los factores evolutivos son aquellos que indican si el software se puede trasladar
con facilidad a otra máquina o a otro producto de base (SO, SGBD).

8
MÉTRICAS
Las métricas del producto son una medida cuantitativa que permite a la gente del
software tener una visión profunda de la eficacia del proceso del software y de
los proyectos que dirigen utilizando el proceso como un marco de trabajo;son
analizadas y evaluadas por los administradores del software.
-VENTAJAS DEL USO DE METRICAS:
-Determina la calidad del producto.
-Evalúa la productividad de los desarrolladores.
-Se tiene conocimiento cuantitativo de las características del proceso y del
producto.
-Se tiene un soporte para la estimación y la planificación.
Se evalúan los beneficios (en cuanto a calidad y productividad) derivados del uso
de nuevos métodos y herramientas de ingeniería del software.
-Establece una línea base para la estimación
CARACTERISTICAS DE LAS METRICAS:
-ExactasPrecisas: No se debe perder información en los redondeos ya que la
información se desvirtúa.
-Consistentes: Una medición de un atributo debe dar el mismo valor
independientemente de la medición.

9
5.6 Modelos de madurez

Modelos de madurez
El grado en el cual una organización, o una unidad organizacional desarrollan,
asimila e implementa buenas prácticas en dirección de proyectos, programas y
portafolios, se conoce como madurez en administración/dirección de proyectos.

El nivel de madurez en administración de proyectos de una organización u unidad

organizacional, es factible de ser medido mediante modelos de madurez.
Un modelo de madurez, es un conjunto estructurado de elementos (buenas
prácticas, herramientas de medición, criterios de análisis, etc.), que permite
identificar las capacidades instaladas en dirección de proyectos en la
organización, compararlas con estándares, identificar vacios o debilidades y
establecer procesos de mejora continúa.
Los modelos de madurez en administración de proyectos, derivan del Capability
Maturity Model, CMMdesarrollado, a requerimiento del Gobierno Federal de
Estados Unidos, en 1986 por el Software Engineering Institute, SEI, para la
evaluación de procesos vinculados con el desarrollo de software. El objetivo de este
modelo fue la provisión de un cuestionario que sirviese como herramienta para
identificar las áreas donde los procesos de desarrollo de software necesitasen
mejora.

10
Los modelos de madurez, para medir las capacidades instaladas en dirección de
proyectos, más conocidos son:
 PMMM (Project Management Maturity Model), publicado en 1992, por
Dekker, este modelo analiza el nivel de madurez a través de las nueve áreas
de conocimiento del PMBOK, a través de 5 niveles de
medición: i) Inicial; ii) Repetición; iii) definición; iv)Dirección
y v) Optimización.
 Kezner, publicado por Harold Kezner en el año 2000 en el libro, ¨Strategic
Planning for Project Management¨, este modelo basado en el CMM y en el
PMBOK, consta de 183 preguntas distribuidas en cinco niveles de
medición: i) lenguaje común (80 preguntas); ii) Procesos comunes (20
preguntas); iii) Metodología común (42 preguntas); iv) Comparación (25
preguntas ; y v) Mejoramiento continuo (16 preguntas). Si bien este
modelo analiza los mismos ámbitos que el OPM3, no evalúa la madurez de
programas y de portafolio.
 OPM3 (Organizational, Project Management Maturity Model),
desarrollado por el PMI en el año 2003 y actualizado en el 2008 en una
segunda versión[3], este modelo describe la metodología de medición de
madurez organizacional en gerencia de proyectos de acuerdo a los
estándares del PMI, (Project Management Body Of Knowledge, The
Standard for Portfolio Management y The Standard for Program
Management, entre otros)El OPM3 establece una rejilla de buenas prácticas
para los niveles de estandarización, medición, control y mejora continua para
proyectos, programas y portafolio. Entre sus fortalezas destacan:
 Se basa en la guía del PMBOK;
 Permite identificar las buenas prácticas requeridas para mejorar las
capacidades en dirección de proyectos y sus vinculaciones entre sí a
nivel de procesos de dirección, áreas de conocimiento, procesos de
gestión, procesos de estandarización, medición, control y mejora
continúa.
 Proporciona un medio objetivo para evaluar la madurez en dirección
de proyectos con respecto a un conjunto de mejores prácticas
reconocidas a nivel mundial y que prontamente se encontrarán
vinculadas con una norma ISO.
 Incorpora la experiencia y conocimientos de cientos de profesionales
en dirección de proyectos de un amplio espectro de industrias y área
geográficas reflejadas a través de 574 buenas prácticas, 231 en
dirección de proyectos, 235 para programas y 108 para la gestión de
portafolios.

11
5.6.1 Enfoque de procesos

Enfoque de procesos
Estándar internacional que ofrece un marco para la evaluación de procesos. Fue
iniciado en 1991 como el proyecto SPICE (Software Process Improvement and
Capability dEtermination). La versión de Reporte Técnico fue aceptada y publicada
en 1998, enfocada únicamente en procesos de software.
En el transcurso de su desarrollo ha evolucionado, de ser un modelo de referencia
de buenas prácticas de software, para convertirse en un marco de trabajo para
evaluación de múltiples modelos (de software o no). Su dirección actual es poder
aplicarse a múltiples disciplinas y permitir a las diferentes comunidades definir sus
propios procesos específicos, modelos de referencia o buenas prácticas. ISO 15504
está en vías de convertirse en estándar internacional, y se espera que esté completo
para 2006. Esta versión esta compuesta de cinco documentos, a diferencia del
reporte técnico que consta de nueve partes (Ver gráfica 1 - Estructura de
documentos).
La parte 2 de este estándar es de especial interés, ya que es la que define como se
realiza una evaluación. Establece requisitos tanto para modelos de procesos de
referencia como para los métodos de evaluación sin establecer alguno en particular.

Niveles de Capacidad (Ver gráfica 2):

0. Incompleto.- Falta de cumplimiento del proceso.
1. Realizado.- Genera los productos de trabajo esperados.
2. Administrado.- Proceso y productos administrados y controlados.
3. Establecido.- Proceso definido para la organización y utilizado adecuadamente.
4. Predecible.- El proceso opera dentro de los límites estadísticos establecidos.
5. Optimizado.- El proceso mejora continuamente.
Las organizaciones de software no tienen que seleccionar entre 15504 y su modelo
actual. El rol de 15504 es proveer un marco de trabajo en el que los modelos y
métodos de evaluación puedan existir de una manera armónica. No esta diseñado
para ser utilizado solo. La selección radica en decidir si el ajustarse a 15504 es
importante para el negocio (¿El negocio compite en el mercado global?, ¿Provee
software a algún cliente que requiera 15504?, ¿Existen varios modelos de
evaluación en la organización?). De ser así, deberán elegir modelos que se ajusten
a 15504.

12
Compatibilidad entre Modelos

ISO/IEC 15504
 Evaluación de procesos de software.
 En vías de ser estándar.
 Dirección amplia.
 Niveles de capacidad.
 Evaluación de capacidades por proceso individual.
 Guía para realizar la evaluación.
 Toma como referencia ISO 9001 y CMMI.
CMMI
 Modelo de madurez de procesos de software.
 Modelo – estándar de facto.
 Dirección detallada.
 Pasos progresivos (niveles) - Escalonada.
 Categorías de procesos - Continua.
 Guía para institucionalización e implementación.
 Modelo de evaluación será conforme al modelo de evaluación de 15504.
ISO 9001-2000
 Sistema de Gestión de la Calidad.
 Estándar internacional.
 Dirección amplia.
 Un conjunto de requerimientos a ser cubierto.
 No hay lineamientos para su implementación.
 Usado como referencia en actividades de gestión de calidad por CMMI y
15504.
Con eso concluímos nuestra revisión de modelos genéricos. A continuación veamos
los modelos específicos para software.

13
5.6.2 PSP y TSP

PSP – Personal Software ProcessSM

Personal Software Process (PSP) es un proceso diseñado para ayudar a los

ingenieros de software a controlar, manejar y mejorar su trabajo. PSP está basado
en una motivación: La calidad de software depende del trabajo de cada uno de los
ingenieros de software. Debido a que los costos de personal constituyen 70% del
costo del desarrollo de software, las capacidades y hábitos de trabajo de los
ingenieros determinan en gran manera los resultados del desarrollo de software.
Basado en prácticas encontradas en CMM, el PSP puede ser usado por ingenieros
para estructurar y disciplinar el desarrollo de software. El ingeniero de software
podrá planear mejor el trabajo, conocer con precisión el desempeño, medir la
calidad de productos, y mejorar las técnicas.
PSP puede ser aplicado en:
 Desarrollo de programas.
 Definición de requerimientos.
 Documentación.
 Pruebas de sistemas.
 Mantenimiento de sistemas.
TSP
TSP - Team Software Process
Team Software Process (TSP) es un marco para el desarrollo de software que pone
igual énfasis en el proceso, producto y trabajo en equipo. Al igual que PSP, TSP fue
propuesto por Watts Humphrey.
TSP se basa en PSP, y se fundamenta en que el software, en su mayoría, es
desarrollado por equipos, por lo que los ingenieros de software deben primero saber
controlar su trabajo, y después saber trabajar en equipo. TSP le enseña a los
ingenieros a construir equipos autodirigidos y desempeñarse como un miembro
efectivo del equipo. También muestra a los administradores como guiar y soportar
estos equipos.

14
Estrategia de TSP
• Proveer un proceso sencillo basado en PSP.
• Desarrollar productos en varios ciclos. Ciclo de TSP: Lanzamiento, Estrategia,
Plan, Requerimientos, Diseño, Implementación, Pruebas, Postmortem.
• Establecer medidas estándares para calidad y desempeño.
• Proveer definiciones de roles, y evaluaciones de rol y de equipo.
• Requiere disciplina de proceso.
• Provee guía para manejo de problemas de trabajo en equipo.

15
5.6.3 SPICE

SPICE
SPICE es un acrónimo inglés de Simulation Program with Integrated Circuits
Emphasis (Programa de simulación con énfasis en circuitos integrados). Fue
desarrollado por la Universidad de California, Berkeley en 1973 por Donald O.
Pederson y Laurence W. Nagel.
Es un estándar internacional cuyo objetivo es simular circuitos
electrónicos analógicos compuestos
por resistencias, condensadores, diodos, transistores, etc. Para ello hay que
describir los componentes, describir el circuito y luego elegir el tipo de simulación
(temporal, en frecuencia, en continua, paramétrico, Montecarlo, etc.).

16
Características del programa
Análisis
SPICE realiza los siguiente tipos de análisis:
 DC - Función de transferencia.
 AC - Respuesta en frecuencia de circuito.
 Transitorio - Evolución del circuito en el tiempo.

Dependiendo del software utilizado y versión del mismo, se encuentran

implementados análisis avanzados, que pueden ir desde un sencillo cálculo de
respuesta en frecuencia, hasta la simulación de diseños de radio frecuencia y
análisis térmico, entre ellos:
 Punto operativo CD
 Análisis de CA
 Análisis de CA de Frecuencia Única
 Análisis de Transitorio
 Análisis de Fourier
 Análisis de Ruido
 Análisis de Figura de Ruido
 Análisis de Distorsión
 Análisis de CD
 Análisis de Peor-caso.
 Comportamiento de Monte Carlo
 Sensibilidad
 Barrido de Parámetro
 Barrido de Temperatura

17
Dispositivos y componentes
Resistencias
El modelo de resistencias en SPICE corresponde al modelo clásico de la teoría de
circuitos, más el modelo de variación del valor de este dispositivo por efecto de la
temperatura.
Inductancias
Inductancias mutuas
Si por una bobina fluye una corriente que varía en el tiempo, se produce un flujo
magnético y por ende un voltaje en esta. Si acercamos otra bobina observamos que
las líneas de flujo inciden de manera que recíprocamente en esta se induce un
voltaje y si existe trayectoria posible, también existirá una corriente. El voltaje que
se induce en la segunda bobina es proporcional al cambio de la corriente de la
primera bobina.
Condensadores
Es un dispositivo con la capacidad de acumular cargas eléctricas dentro de si, muy
utilizado en circuitos.
Dispositivos semiconductores
Líneas de transmisión (parámetros distribuidos)
Ejemplos
La forma de modelar una señal cuadrada es Vnodo Nodo 0 PULSE (V1 V2 TD TR
TF PW PER) con:
 V1: Valor inicial
 V2: Valor final
 TD: Latencia inicial del pulso
 TR: Tiempo de subida
 TF: Tiempo de bajada.
 PW: Ancho del pulso
 PER: Periodo del pulso.
Una de las formas de modelar un transistor MOS es MNúmero nD nG nS nB tipo
W= L= PD= AD= PS= AS= con:
 Mnúmero: identifica al transistor
 nD: número nodo drenador

18
  nG: número nodo puerta
 nS: número nodo surtidor
 nB: número nodo substrato
 tipo: NMOS / PMOS
 W: anchura del canal
 L: longitud del canal
 PD / PS: perímetros del drenador / surtidor
 AD / AS: área del drenador / surtidor
Uniendo varios de estos dispositivos por medio de los nodos se describe el circuito
completo que luego será empleado para la simulación.

5.6.4 CMMI

Capability Maturity Model Integration

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.
Modelos CMMI
Las mejores prácticas CMMI se publican en los documentos llamados modelos. En
la actualidad hay tres áreas de interés cubiertas por los modelos de CMMI:
Desarrollo, Adquisición y Servicios.
La versión actual de CMMI es la versión 1.3 la cual fue liberada el 1 de noviembre
de 2010. Hay tres constelaciones de la versión 1.2 disponible:
· CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), Versión 1.2
fue liberado en agosto de 2006. En él se tratan procesos de desarrollo de productos
y servicios.
· CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition), Versión 1.2
fue liberado en noviembre de 2007. En él se tratan la gestión de la cadena de
suministro, adquisición y contratación externa en los procesos del gobierno y la
industria.
· CMMI (CMMI-SVC o CMMI for Services), está diseñado para cubrir todas las
actividades que requieren gestionar, establecer y entregar Servicios.

19
Dentro de la constelación CMMI-DEV, existen dos modelos:
· CMMI-DEV
· CMMI-DEV + IPPD (Integrated Product and Process Development)
Independientemente de la constelación\modelo que opta una organización, las
prácticas CMMI deben adaptarse a cada organización en función de sus objetivos
de negocio.
Las organizaciones no pueden ser certificadas CMMI. Por el contrario, una
organización es evaluada (por ejemplo, usando un método de evaluación como
SCAMPI) y recibe una calificación de nivel 1-5 si sigue los niveles de Madurez (si
bien se comienza con el nivel 2). En caso de que quiera la organización, puede
coger áreas de proceso y en vez de por niveles de madurez puede obtener los
niveles de capacidad en cada una de las Áreas de Proceso, obteniendo el "Perfil de
Capacidad" de la Organización.
Nivel 1: No Confiable- Ambiente impredecible donde las organizaciones no tienen
actividades de control y no están diseñadas.
Nivel 2: Informal- Las actividades de control existen pero no se ponen en practica.
Los controles dependen básicamente de las personas. No hay un entrenamiento
formal ni comunicación de las actividades de control.
Nivel 3: estandarizado- Las actividades de control existen y están diseñadas, han
sido documentadas y comunicadas a los empleados, las desviaciones de las
actividades de control probablemente no se detecten.
Nivel 4: Monitoreado- Se utilizan herramientas en una forma limitada para soportar
las actividades de control
Nivel 5: Optimizado- Es una estructura integrada de control interno con un monitoreo
en tiempo real por la gerencia, así como mejoras continuas-auto control, se
encuentran cambios más rápidos al momento de detectar errores en los manejos
de las actividades o en las personas.
Evaluación (Appraisal)
Muchas organizaciones valoran el medir su progreso llevando a cabo una
evaluación (appraisal) y ganando una clasificación del nivel de madurez o de un
nivel de capacidad de logro. Este tipo de evaluaciones son realizadas normalmente
por una o más de las siguientes razones:
· Para determinar que tan bien los procesos de la organización se comparan
con las mejores prácticas CMMI y determinar qué mejoras se pueden hacer.

20
· Como requisito del cliente en licitaciones públicas o concursos privados.
Las valoraciones de las organizaciones utilizando un modelo CMMI deben ajustarse
a los requisitos definidos en el documento "Appraisal Requirements for CMMI"
(ARC). La evaluación se enfoca en identificar oportunidades de mejora, y comparar
los procesos de la organización con las mejores prácticas CMMI. Los equipos de
evaluación usan el modelo CMMI y un método conforme a ARC para guiar su
evaluación y reporte de conclusiones. Los resultados de la evaluación son usados
para planear mejoras en la organización. Hay tres clases de evaluación: Clase
A,B,C. El Standard CMMI Appraisal Method for Process Improvement (SCAMPI) es
un Método de evaluación que cumple todos los requerimientos ARC. Una
evaluación de clase A es más formal y es la única que puede resultar en una
clasificación de nivel.

El Standard CMMI Appraisal Method for Process Improvement (SCAMPI) es el

método oficial SEI para proveer puntos de referencia de sistemas de calificación en
relación con los modelos CMMI. SCAMPI se usa para identificar fortalezas y
debilidades de los procesos, revelar riesgos de desarrollo/adquisición, y determinar
niveles de capacidad y madurez. Se utilizan ya sea como parte de un proceso o
programa de mejoramiento, o para la calificación de posibles proveedores. El
método define el proceso de evaluación constando de preparación; las actividades
sobre el terreno; observaciones preliminares, conclusiones y valoraciones;
presentación de informes y actividades de seguimiento.

5.6.5 MoProSoft

MoProSoft

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.

21
¿A quién está dirigido MoProSoft?
A las empresas o áreas internas dedicadas al desarrollo y/o mantenimiento de
software. El esquema agrupa los procesos en tres categorías principales: Alta
Dirección, Gerencia y Operación. Esta división de procesos se ajusta a la
estructura funcional de una organización convencional.
Las organizaciones que no cuenten con procesos establecidos, pueden usar el
modelo como la primera versión de sus procesos e ir ajustándolos de acuerdo a sus
necesidades y experiencia adquirida.

Aquellas organizaciones, que ya tienen procesos establecidos, pueden usarlo

como punto de referencia para identificar los elementos que les hace falta cubrir.
La implementación de MoProSoft en una organización necesita ser gestionada
como un proyecto de mejora promovido por la alta dirección, además de
tener un alcance claro, así como tener definidos objetivos que sean alcanzables.

Características
 Es específico para el desarrollo y mantenimiento de software.
• Facilita el cumplimiento de los requisitos de otros modelos como ISO
9000:2008 y CMMI.
• Es sencillo de entender y adoptar.
• Es práctico en su aplicación.
• Comprende un documento de menos de 200 páginas que al compararlo
con otros modelos y estándares, lo hace bastante práctico.
• Resulta acorde con la estructura de las organizaciones mexicanas con
desarrollo o mantenimiento de software.
• 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.
• Tiene un bajo costo, tanto para su capacitación y, su adopción como para
su evaluación.
Beneficios
 Mejorar la calidad del software producido por la organización que adopta
el modelo.
• Elevar la capacidad de las organizaciones para ofrecer servicios con
calidad y alcanzar niveles internacionales de competitividad.
• Integrar todos los procesos de la organización y mantiene la alineación con
los objetivos estratégicos.
• Reconocer a las organizaciones mexicanas por su nivel de madurez

22
 de procesos.
• Obtener acceso a las prácticas de ingeniería de software de clase mundial.
• Pertenecer a la Lista Nacional de Empresas Dictaminadas, que
sirve como una referencia oficial para clientes, autoridades y competidores.

FUENTE DE CONSULTA:

http://andoniandresperezdominguezfis.blogspot.com/
http://andoniandresperezdominguezfis.blogspot.com/2017/12/56-modelos-de-
madurez.html

23