PROCESOS DE

SOFTWARE
 INTEGRANTES

 Flores Reyes Eveliz

 Mancilla Salazar Juan Carlos
 Mayo Cáceres Luis Miguel
El Proceso del Software
Conjunto estructurado de actividades requeridas para desarrollar un
sistema de software de alta calidad y proporciona el marco de trabajo
desde el cual se puede establecer un plan detallado para el desarrollo del
software.
Actividades:
 Especificación.
 Diseño.
 Validación.
 Evolución.
 Elementos del proceso
de software
Un marco común del proceso, son
aplicables a todos los proyectos de
software, con independencia del tamaño
o complejidad.
Un conjunto de tareas, cada uno es
una colección de tareas de ingeniería
del software, hitos de proyectos,
entregas y productos de trabajo
del software, y puntos de garantía de
calidad, que permiten que las
actividades del marco de trabajo se
adapten a las características del
proyecto de software y los requisitos del
equipo del proyecto.
Las actividades de protección, tales
como garantía de calidad del software,
gestión de configuración
del software y medición abarcan el
modelo del proceso.
 Relación entre los elementos
del proceso de software

  Quién: Las Personas participantes en el proyecto de desarrollo desempeñando

uno o más Roles específicos.
 - Qué: Un Artefacto1 es producido por un Rol en una de sus Actividades. Los
Artefactos se especifican utilizando Notaciones específicas. Las Herramientas
apoyan la elaboración de Artefactos soportando ciertas Notaciones.
 - Cómo y Cuándo: Las Actividades son una serie de pasos que lleva a cabo un Rol
durante el proceso de desarrollo. El avance del proyecto está controlado mediante
hitos que establecen un determinado estado de terminación de ciertos Artefactos.
 Modelos de Proceso Software

Los modelos genéricos no son descripciones definitivas de procesos

de software; sin embargo, son abstracciones útiles que pueden ser
utilizadas para explicar diferentes enfoques del desarrollo de
software.
Modelos que se van a discutir a continuación:
 Codificar y corregir
 Modelo en cascada
 Desarrollo evolutivo
 Desarrollo incremental
 Desarrollo en espiral
 Integrantes:
DEFINICION DE • Huaracc Palomino Milton
•
MODELO DE
Licas Yarasca Clenin
• Huillcamasco Ramos Wilson

PROCESOS
Definición:

El modelo de proceso de
desarrollo de software es
quizás la pieza más
importante de este
engranaje conocido como
ingeniería de software.
Existen varios modelos para
el proceso de desarrollo
software.
1.
Modelo
secuencial o en
cascada
“El modelo en lineal secuencial es
también conocido como el ciclo de
vida del software, está conformado
por las etapas de Análisis de
requerimientos, Diseño,
Codificación y pruebas.
PROCESO DE SOFTWARE POR
PROTOTIPOS
El paradigma de desarrollo por
prototipos permite refinar
sistemas complejos con base en
un sistema mínimo definido al
principio del proceso de la
especificación del sistema y de los
cuales el cliente no tiene la
definición completa de requisitos.
PROCESO DE
SOFTWARE
BASADO POR
COMPOENENTES
 Cuenta con 4 partes:

Analisis Modificacion Diseño Desarrollo

PROCESO DE SOFTWARE POR
ENTREGAS INCREMENTALES
“
Este modelo del proceso software es un
proceso intermedio entre las mejores
características del modelo en cascada y el
modelo evolutivo. El analista comienza por
realizar una definición de los requerimientos
del sistema completo y luego diseña una
estructura por incrementos o entregables de
la aplicación.
PROCESO DE
SOFTWARE
ESPIRAL
El modelo en espiral es una mirada
diferente al proceso software. Más que
representar el proceso del software
como una secuencia de actividades
con retrospectiva de una actividad a
otra, se representa como una espiral.
 CICLO DE VIDA DEL SOFTWARE:

Analisis Manteni
miento

Explotac
ion
Diseño

Codificac Integraci
ion on
GRACIAS
!!!!
DEFINICIÓN DE MODELOS DE
PROCESOS:
DEFINICIÓN DE EVALUACIÓN DE CAPACIDADES

Grupo 3
EVALUACIONE
S DE LAS
CAPACIDADES Una vez ajustado el proceso y disminuido su variación se
evalúa la capacidad del proceso. Un estudio de capacidad es
un procedimiento ordenado de planeación, recolección y
DE LOS análisis de información, con la finalidad de evaluar la
estabilidad de un proceso, y la capacidad que éste tiene para
producir dentro de especificaciones. Los estudios de
PROCESOS capacidad miden la variación y el centrado de un proceso con
respecto a sus especificaciones.  
 G rá
me
f ic o
dici
s de
ón!
¿Cómo evaluar la
capacidad de un
proceso?
 Gráficos de medición!
¿Qué es un Histograma?

HISTOGRAMA

El histograma es aquella representación gráfica de estadísticas de diferentes tipos. La utilidad del histograma tiene que ver con la
posibilidad de establecer de manera visual, ordenada y fácilmente comprensible todos los datos numéricos estadísticos que pueden
tornarse difíciles de entender. Hay muchos tipos de histogramas y cada uno se ajusta a diferentes necesidades como también a
diferentes tipos de información.
¿Que son las
graficas de
control?
Es un diagrama que sirve para
examinar si un proceso se encuentra en
una condición estable, o para asegurar
que se mantenga en esa condición.
 Gráficos de medición!
¿Qué son las planillas de inspección u hojas de control?

PLANILLAS DE INSPECCIÓN U HOJAS

DE CONTROL
La Hoja de Control u hoja de recogida de datos, también llamada de Registro, sirve para reunir y clasificar las
informaciones según determinadas categorías, mediante la anotación y registro de sus frecuencias bajo la forma
de datos.
D
is
tr
ib
uc
ió
n
5 Funciones

Cl
a si
fic
ac
ió
n

Lo
ca
liz
ac
ió
n

Ca
us
a s

Ve
rif
ic
ac
ió
n
PLANILLAS DE INSPECCIÓN U HOJAS DE CONTROL
¡Gracias por la
atención!
¿Alguna pregunta?
MODELOS DE DEFINICIÓN DE
PROCESOS DE CICLO
12207
DEVIDA
Modelo ISO/IEC
• ANCHANTE CANELO, ANGEL
• MOREANO CORTEZ, JOHER
• SOTO CAHUA , JUAN JOSE
INTEGRANTES:

TREY
 SOBRE ISO
La Organización Internacional de
Normalización (conocida por la
abreviación ISO) es una organización
para la creación de estándares
internacionales compuesta por
diversas organizaciones nacionales de
estandarización.
Fundada el 23 de febrero de 1947, la
organización promueve el uso de
estándares propietarios, industriales y
comerciales a nivel mundial. Su sede
está en Ginebra (Suiza) y hasta 2015
trabajaba en 196 países. TREY
ORIGEN
La norma Técnica 12207 fue elaborada por el comité técnico de
normalización de ingeniería de software y sistemas de información,
mediante el antecedente de la norma ISO/IEC 12207 durante los
mese de enero a marzo del año 2006.

VERSIONES:
 ISO/IEC 12207:1995. Primera publicación
 ISO/IEC 12207:1995/Amd 1:2002. Primera modificación
 ISO/IEC 12207:1995/Amd 2:2004. Segunda modificación
 ISO/IEC 12207:1995/Amd 1:2008. Tercera modificación
INTRODUCCIÓN
El ISO/IEC 12207 es el estándar para los procesos de
ciclo de vida del software de la organización ISO.
Este estándar se concebió para aquellos interesados en
adquisición de software, así como desarrolladores y
proveedores. El estándar indica una serie de procesos
desde la recopilación de requisitos hasta la culminación
del software.

TREY
 1 Una organización de software 2 Un Proyecto
How to customize this template
Con el fin de ayudar
a establecer un
entorno de trabajo.
CAMPO DE
APLICACIÓN
3 4
Es aplicable a la adquisición Un Comprador o vendedor
de sistemas, productos y
servicios de software, al Para ayudar a desarrollar un
suministro, al desarrollo, acuerdo sobre los procesos y
operación y mantenimiento actividades que se vayan a
de productos software. manejar.
Con el fin de ayudar a
seleccionar una infraestructura y
emplear todos los elementos
que conforman un ciclo de vida
de software establecido
Asesores
Con el fin de realizar
evaluaciones que puedan servir
de apoyo para mejorar los
procesos de la organización.
TREY
Large image

El estándar comprende 17
procesos lo cuales son agrupados
en tres categorías:
TREY
 PROCESOS
PRINCIPALES
Los procesos principales del ciclo de vida son 5, los
cuales brindan servicios a las partes principales durante
el ciclo de vida del software.

TREY
Procesos Principales Del Ciclo De Vida
A continuación explicaremos cada proceso:

1. Proceso De Adquisición 2. Proceso De Suministro

Este proceso consiste de las siguientes actividades: Este proceso consta de las siguientes actividades:
• Inicio • Inicio
• Preparación de la solicitud de propuestas • Preparación de la respuesta
• Preparación y actualización del contrato • Contrato
• Seguimiento del proveedor • Planificación
• Aceptación y finalización

TREY
Procesos Principales Del Ciclo De Vida
A continuación explicaremos cada proceso:
3. Proceso De Desarrollo
Este proceso consta de las siguientes actividades:
• Implementación del proceso
• Análisis de los requerimientos del sistema
• Diseño de la arquitectura del sistema
• Análisis de los requerimientos software
• Diseño de la arquitectura del software
4. Proceso De Operación
El operado hace uso de otros procesos a nivel de proyecto para
llevar a cabo su función:
• El Proceso De Gestión
• Proceso De Infraestructura
A nivel de organización emplea los siguientes:
• El Proceso De Mejora De Procesos
• Proceso De Recursos Humanos
TREY
Procesos Principales Del Ciclo De Vida
A continuación explicaremos cada proceso:

5. Proceso De Mantenimiento
El operado hace uso de otros procesos a nivel de proyecto para
llevar a cabo su función:
• El Proceso De Gestión
• Proceso De Infraestructura

TREY
 PROCESOS DE
SOPORTE
Las actividades y tareas en un proceso de apoyo son
responsabilidad de la organización que lleva a cabo dicho
proceso. Esta organización se asegura que el proceso
existe y está operativo.

TREY
PROCESOS DE SOPORTE DEL CICLO DE VIDA
1. Proceso de documentación

2. Proceso de gestión de la configuración

3. Proceso de aseguramiento de la calidad

4. Proceso de verificación

5. Proceso de validación

6. Proceso de revisión conjunta

7. Proceso de auditoria

8. Proceso de solución de problemas

TREY
 Procesos
Organizacionales
Se emplean por una organización para establecer e
implementar una infraestructura constituida por
procesos y personal asociado al ciclo de vida y para
mejorar continuamente esta infraestructura

TREY
Procesos Organizativos Del Ciclo De Vida
A continuación explicaremos cada proceso:

1. Proceso De Mejora 2. Proceso De Infraestructura

Este proceso consiste de las siguientes actividades: Este proceso consta de las siguientes actividades:
• Establecimiento del proceso. • Implementación del proceso.
• Evaluación del proceso. • Establecimiento de la infraestructura.
• Mejora de proceso. • Mantenimiento de infraestructura.

TREY
Procesos Principales Del Ciclo De Vida
A continuación explicaremos cada proceso:
3. Proceso De Adquisición
Este proceso consiste de las siguientes actividades:
• Inicio
• Preparación de la solicitud de propuestas
• Preparación y actualización del contrato
• Seguimiento del proveedor
• Aceptación y finalización
4. Proceso De Recursos Humanos
Este proceso consta de las siguientes actividades:
• Implementación del proceso.
• Desarrollo del material de formación.
• Implementación de plan de formación.
TREY
Agregue un pie de página TREY
Modelo CMMI
Control de calidad de software
 Integrantes:

 Navarro Ore. Dany Efraín.

 Espinoza Guevara Jander.
 Huaripaucar Allccahuaman Kenyo.
 Introducción
Antes que nada debemos de comenzar por
decir qué significa CMMI. Pues bien, estas siglas
significan Capability Maturity Model Integration
(Modelo de Madurez de Capacidades de
Integración). Dicho modelo de procesos
contiene las mejores prácticas de la industria
del desarrollo de software, tanto para el
desarrollo del mismo, como para su
mantenimiento, adquisición y operación de
productos y servicios.
¿QUE
¿QUE ES
ES EL
EL MODELO
MODELO CMMI?
CMMI?

La CMMI  es  un  modelo  que  contiene  las  mejores 

prácticas  y  que  provee  a  las  organizaciones  de 
aquellos  elementos  que  son  esenciales  para  que 
los procesos de negocio de estas sean efectivos.

El  CMMI  es  el  Modelo  de  Madurez  de 

Capacidades Integrado.

Mide  la  madurez  del  desarrollo  del  software  en 

una escala del 1 al 5
OBJETIVOS DEL CMMI.

Producir servicios y Productos de alta calidad.

Crear valor para los accionistas.

Mejorar la satisfacción del cliente.

Incrementar la participación en el mercado.

Ganar reconocimiento en la industria.

¿Por qué debe usarse un modelo?
•proporciona un marco y un lenguaje comunes que
ayudan a comunicarse,

•aporta años de experiencia,

•ayuda a los usuarios a no perder de vista la idea global

cuando se enfocan específicamente en la mejora,

•suele tener el respaldo de instructores y consultores,

•puede proporcionar un estándar para ayudar a salvar las

discrepancias.
 DISCIPLINAS
DEL MODELO.

• Ingeniería de Software (SW)

• Ingeniería de Sistemas (SE)
• Desarrollo Integrado de
Productos y Procesos (IPPD)
• Acuerdos con Proveedores
(SS).
 • Nivel 1 (Inicial): El proceso es impredecible, es reactivo y
pobremente controlado.

Niveles de • Nivel 2 (Administrado): El proceso es reactivo y se caracteriza por su

aplicación a proyectos.

Madurez
• Nivel 3 (Definido): El proceso es proactivo y se ve a nivel de la
(por organización.

Etapas) • Nivel 4 (Administrado Cuantitativamente): El proceso es medido y

controlado.

• Nivel 5 (Optimizado): El proceso se enfoca en la mejora continua.

Areas de Proceso
Clasificadas en 4 categorías
Ingeniería
Gestión de Proyecto 
 Gestión de Proceso 
 Soporte
Gestión de proyectos
Cubren las actividades relacionadas con la  
planificación, seguimiento y control del proyecto.

Proporcionan mecanismos para establecer,  
mantener y monitorizar acuerdos con clientes y 
 proveedores

Proporciona mecanismos para establecer y 
  mantener  un  entorno  de  colaboración 
entre  equipos
Ingeniería

Da soporte las actividades del ciclo de vida de  
desarrollo del producto, desde el desarrollo inicial 
 de requisitos a la transición al uso operacional
Soporte
Proporciona los procesos esenciales para 
  soportar  el  desarrollo  y  mantenimiento 
del  producto

Proporciona funciones de soporte usadas 
  por  todas  las  áreas  de  proceso  durante 
el  desarrollo del producto
Gestión de procesos
Contiene las prácticas relacionadas 
 con la implementación de un  
programa de mejora de procesos

Proporciona capacidad de  
conseguir objetivos cuantitativos de 
 calidad y rendimiento del proceso
!Gracias por su
atención!
Control de calidad de software
MOPROSOFT
MODELO DE PROCESOS DE SOFTWARE
 El Modelo de Procesos de
Software fue desarrollado a
solicitud de la Secretaría de
Economía para servir de base
a la Norma Mexicana para la
Industria de Desarrollo y
Mantenimiento de Software
bajo el convenio con la
Facultad de Ciencias,
Universidad Nacional
Autónoma de México.
ESTRUCTURA
Categoria de alta direccion (DIR)
Se establecen los lineamientos para los procesos de la Categoría de
Gerencia y se retroalimenta con la información generada por ellos en
apoyo a la estrategia de la organización.

Categorita de Gerencia (GER)

Se definen los elementos para el funcionamiento de los procesos de
la Categoría de Operación en función de la estrategícia de Dirección,
recibe y evalúa la información generada por éstos y comunica los
resultados a la Categoría de Alta Dirección.

Categoria de Operación (OPE)

Se realizan las actividades de acuerdo a los elementos
proporcionados por la Categoría de Gerencia y entrega a ésta la
información y productos generados.
PROCESOS
 Categoria Direccion
Gestión de Negocios
Su propósito la razón de ser de la organización, sus objetivos y las condiciones para lograrlos, para lo
cual es necesario considerar las necesidades de los clientes, así como evaluar los resultados para
poder proponer cambios que permitan la mejora continua.

 Categoria Gerencia
Gestión de Proyectos
Generar proyectos que contribuyan al cumplimiento de los objetivos y estrategias de la organización.

Gestión de Recursos
Consigue y provee a la organización de los recursos para desarrollar las actividades de acuerdo a las
necesidades de cada proceso y proyecto.
 Recursos Humanos y Ambiente de Trabajo
 Bienes, Servicios e Infraestructura
 Conocimiento de la Organización
 PROCESOS

 Categoria Operación
 Administración Específica de Proyectos
Administra los proyectos internos y externos en base a los
planes de cada uno, genera acciones correctivas.

 Desarrollo y Mantenimiento de Software

Genera los productos a traves del ciclo de vida de
desarrollo del software buscando satisfacer las
necesidades del cliente.
NIVELES DE MADUREZ
ROLES
INTEGRANTES:
LUJAN CORTAVITARTE EDGAR

RAMIREZ TIPIANA SEBASTIAN

VELARDE MUÑANTE ISABEL
Modelo ISO/IEC 15504
 EL ESTANDAR INTERNACIONAL ISO/IEC 15504
El Estándar internacional  ISO/IEC 15504 denominado como Software 
Process Improvement Capability Determination  también conocido por 
su abreviatura SPICE nos propone un modelo para la evaluación de la 
capacidad en los procesos de desarrollo de productos Software.

ISO/IEC 15004 SPICES se trata de una herramienta con los siguientes 
objetivos:

• Proponer  y  desarrollar  un  estándar  de  evaluación  de  procesos  de 

software.

• Evaluar su desempeño mediante su experimentación en la industria 
emergente del desarrollo Software.

• Promover  la  transferencia  de  tecnología  de  la  evaluación  de 

procesos de software a la industria del software a nivel mundial.
 ¿EN QUÉ CONSISTE LA NORMA ISO/IEC 15504
SPICE?
La  norma  SPICE  establece  requisitos  para  una  evaluación  de  procesos  y  los  modelos  de  evaluación 
pretendiendo  que  estos  requisitos  puedan  ser  aplicados  en  cualquier  modelo  de  evaluación  en  una 
organización.

En general, los requisitos para la evaluación de procesos comprenden:

• Evaluación de procesos.

• Mejora de procesos.

• Evaluación de la capacidad y/o madurez de los procesos.

Por  otro  lado  en  cuanto  a  otros  aspectos   la  norma  SPICE  también  establece  requisitos  para  la 
evaluación  de  procesos  para  las  fases  de  ciclo  de  vida  del  software  que  se  definen  en  la  norma 
ISO/IEC 12207, así como requisitos para la evaluación de procesos las fases del ciclo de vida del 
sistema definidos en el estándar ISO/IEC 15288.

En la norma SPICE también encontramos requisitos que puede ser utilizada para la evaluación de 
procesos  relacionados  con  el  desarrollo  de  servicios  TIC  los  cuales  son  definidos  en  la 
norma ISO/IEC 20000.
 ESTRUCTURA DE LA NORMA ISO 15504
ISO 15504 consta de 10 partes que se han ido publicando por separado desde 2003 a 2011:

• ISO 15504. Parte 1. Conceptos y vocabulario

• ISO 15504. Parte 2. Realización de una evaluación

• ISO 15504. Parte 2. Llevando a cabo una evaluación. Guía para la realización de la evaluación

• ISO  15504.  Parte  4.  Guía  sobre  el  uso  para  la  mejora  del  proceso  y  la  determinación  de  la 
capacidad del proceso

• ISO  15504.  Parte  5.  Un  ejemplo  de  modelo  de  evaluación  de  procesos  del  ciclo  de  vida  del 
software (según ISO/IEC 12207)
ESTRUCTURA DE LA NORMA ISO 15504
• ISO 15504. Parte 6. Un ejemplo de modelo de evaluación del ciclo de vida del sistema 
(Según ISO/IEC 15288).

• ISO 15504. Parte 7. Evaluación de madurez organizacional.

• ISO 15504. Parte 8. Un modelo ejemplar de evaluación de procesos para la gestión de 
servicios de TI (Según ISO/IEC 20000).

• ISO 15504. Parte 9. Perfiles de proceso objetivo.

• ISO 15504. Parte 10. Extensión de seguridad
1. NIVELES DE CAPACIDAD
El Estándar establece el principio de los niveles de capacidad heredados de la CMM:

 Nivel 0: El proceso es incompleto; No está completamente implementado y no logra sus objetivos.

 Nivel 1: El proceso se realiza; Se implementa y logra sus objetivos.

 Nivel 2: El proceso se gestiona; Está controlado, su implementación está planificada, monitoreada 
y  ajustada.  Sus  resultados  (productos  de  trabajo)  son  establecidos,  controlados  y  debidamente 
registrados y mantenidos.

 Nivel 3: El proceso está establecido; Está documentado para garantizar su capacidad para cumplir 
sus objetivos.

 Nivel 4: El proceso es predecible; Opera de acuerdo con los objetivos de rendimiento definidos.

 Nivel 5: El  proceso  está  en  optimización  (optimización);  Mejora  continuamente  para  ayudar  a 
alcanzar los objetivos actuales y futuros.
2. ATRIBUTOS DEL PROCESO
Para evaluar el alcance de un nivel de capacidad determinado para un proceso, el estándar 
especifica una serie de atributos del proceso que están ligados a cada nivel de capacidad:
Nivel 1:
- Atributos de rendimiento del proceso PA.1.1

Nivel 2:
- Atributo de gestión del rendimiento PA 2.1
- Atributos PA de la gestión de los productos de las actividades

Nivel 3:
- Atributos de definición de proceso PA 3.1
- Atributo de despliegue de proceso PA 3.2

Nivel 4:
- Atributos de medición del proceso PA 4.1
- Atributo de control de proceso PA 4.2

Nivel 5:
- Atributos de innovación de procesos de PA 5.1
- Atributo de optimización del proceso PA 5.2
 EVALUACION POR NIVELES DE MADUREZ
• ISO 15504 Una norma para evaluar/certificar la madurez Organizacional

El estándar nos permite tanto realizar una evaluación de procesos “digamos

independiente” o a selección u optar por una evaluación que considere además el nivel
global de todos los procesos de una organización.
 • La organización no tiene ninguna implementación efectiva de los procesos.
Nivel 0:
Inmadura

• La  organización  no  cuenta  con  procedimientos  formales  para  la  evaluación,  el 
desarrollo  y  la  evolución  de  sus  aplicaciones.  Las  crisis  ocurren  durante  el 
Nivel 1: proyecto. Cuando la falla se materializa, los posibles fundamentos del método se 
Inicial abandonan para intentar atajos en el proceso de realización y validación.

• La gestión de nuevos proyectos se basa en la experiencia almacenada en 
proyectos similares. El compromiso permanente de los recursos humanos 
Nivel 2: garantiza la durabilidad de los conocimientos dentro del límite de su presencia 
Gestionada dentro de la organización.
 • Se  establecen  pautas  y  procedimientos  de  gestión  del  proyecto  para  permitir  la  aplicación.  El 
proceso estándar de desarrollo y evolución del software está documentado. Se ha implementado 
un  programa  de  capacitación  dentro  de  la  organización  para  garantizar  que  los  usuarios  y  los 
Nivel 3: informáticos adquieran el conocimiento y las habilidades necesarias para asumir los roles que se 
Definido les asignan.

• La  organización  establece  objetivos  cuantitativos  y  cualitativos.  Productividad  y  calidad  son 

evaluadas Este control se basa en la validación de los principales hitos del proyecto como parte 
Nivel 4: de un programa planificado de medidas. 
Gestionado

• La mejora continua del proceso es la principal preocupación. La organización se da a sí misma los 
medios para identificar y medir las debilidades de sus procesos. Una célula de reloj de tecnología 
Nivel 5: identifica y luego adquiere e implementa productos innovadores.
Optimizado
GRACIAS
 MoProSoft
EvalProSoft
Uculmana Lara Luis Ivan
Velasquez Alvites Andersson
MoProSoft
 MoProSoft

Se define como un modelo de procesos para el desarrollo y

mantenimiento de software dirigido a la pequeña y mediana
industria y a las áreas internas de desarrollo de software

Su objetivo principal es incorporar las mejores prácticas en

gestión e ingeniería de software. Su incorporación en la
industria eventualmente permitirá elevar la capacidad de
ofrecer productos y servicios de software con calidad.

Moprosoft fue desarrollado por expertos mexicanos que

recopilaron las experiencias exitosas de la industria de
software a nivel mundial, y las adaptaron a las necesidades y
características de las pequeñas y medianas industrias
mexicanas (PYMEs) desarrolladoras de software.
 Está dividido en 9 procesos,
llamados también prácticas,
organizados por categorías de
acuerdo a sus respectivas
áreas de aplicación. Las
categorías de procesos
coinciden con los tres niveles
básicos de la estructura de
una organización: alta
dirección, gestión y operación.

Cada proceso esta

cuidadosamente detallado a
través de un instrumento
llamado Patrón de Procesos.
Esta descripción está dividida
en 3 partes: descripción
general, descripción de
prácticas y guías de ajuste. Estructura de
Moprosoft
Evalprosoft
MÉTODO DE EVALUACIÓN DE
PROCESOS DEL SOFTWARE
(EVALPROSOFT).
• NYCE (Normalización y Certificación Electrónica) pone
a tu disposición una herramienta que te
permitirá evaluar de una forma fácil y amigable el
cumplimiento con los requisitos de implantación de
MoProSoft conforme vaya avanzando en el proceso.
• La intención final, es que la evaluación formal se
realice de una manera fácil y productiva,
sobre implantaciones que en forma asistida pre-
evaluaron el cumplimiento de los requisitos
correspondientes a los niveles de capacidad deseados.
Posibles usos del Método de
Evaluación
• Evaluación para la acreditación de capacidades:
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.

• Evaluación de capacidades del proveedor: El

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

• Auto-evaluación de capacidades de proceso :

una organización o el Representante de un proyecto
realiza una evaluación con personal interno o externo
que no necesariamente sea Evaluador. En este caso
CONTROL DE CALIDAD
DE SOFTWARE

DOCENTE: DR. ERWIN PEÑA CASAS
Modelo
McCall
Modelos de calidad de
software
Modelo McCall

Desarrollado en 1977 por Jim McCall para la

USAF (United States Air Force).

Busca reducir la brecha entre usuarios y

desarrolladores.

Se enfoca en un número de factores de

calidad que reflejen las prioridades de
ambos.

El  modelo  establece  una  jerarquía  de  aspectos, 

factores y criterios. 
Aspectos
Descompone  el  concepto  de  calidad  en  tres 
usos  o  capacidades  importantes  para  un 
producto de software.

Transición

Revisión

Operación
Factores
Cada aspecto se descompone en una serie
de factores que determinan la calidad en
cada una de ellas.

 Operación  Revisión  Transición

 Facilidad de Uso  Facilidad de prueba  Reusabilidad
 Integridad  Facilidad de  Portabilidad
 Eficiencia Mantenimiento  Interoperabilidad
 Flexibilidad
 Corrección o exactitud
 Fiabilidad
1. OPERACIÓN DEL PRODUCTO
1.1 Facilidad de uso

- Facilidad  de  operación:  determinan  la  facilidad  de 

operación del software.

- Facilidad  de  comunicación:  proporcionan  entradas  y 

salidas fácilmente asimilables.

- Facilidad  de  aprendizaje:  facilitan  la  familiarización 

inicial del usuario con el software

- Formación:  grado  en  que  el  software  ayuda  para 

permitir que nuevos usuarios apliquen el sistema.
1. OPERACIÓN DEL PRODUCTO
1.2 Integridad

- Control  de  accesos:  proporcionan  control  de 

acceso al software y los datos que maneja.

- Facilidad  de  auditoría:  facilitan  la  auditoría  de  los 

accesos al software

- Seguridad:  mecanismos  que  controlen  o  protejan 

los programas o los datos.
1. OPERACIÓN DEL PRODUCTO
1.3 Corrección

- Completitud:  proporcionan  la  implementación  completa 

de todas las funciones requeridas.

- Consistencia: proporcionan uniformidad

- Trazabilidad  o  rastreabilidad:  proporcionan  una  traza 

desde los requisitos a la implementación
1. OPERACIÓN DEL PRODUCTO
1.4 Fiabilidad

- Precisión: proporcionan el grado de precisión requerido

- Consistencia: proporcionan uniformidad

- Tolerancia  a  fallos:  posibilitan  la  continuidad  del  funcionamiento  bajo 

condiciones no usuales. 

- Modularidad: proporcionan una estructura de módulos 

- Simplicidad: posibilita la implementación de funciones de la forma más 
comprensible posible

- Exactitud: La precisión de los cálculos y del control.  
1. OPERACIÓN DEL PRODUCTO
1.5 Eficiencia

- En  ejecución:  minimizan  el  tiempo  de 

procesamiento. 

- En  almacenamiento:  que  minimizan  el 

espacio de almacenamiento necesario. 
2. REVISIÓN DEL PRODUCTO
2.1 Facilidad de mantenimiento
- Modularidad: proporcionan una estructura de módulos.

- Simplicidad: posibilitan la implementación de funciones de la forma 
más comprensible posible. 

- Consistencia: proporcionan uniformidad en las técnicas.

- Concisión:  posibilitan  la  implementación  de  una  función  con  la 

menor cantidad de códigos posible. 

- Auto descripción: proporcionan explicaciones sobre implementación 
de las funciones.
2. REVISIÓN DEL PRODUCTO
2.2 Facilidad de prueba

- Modularidad: proporcionan una estructura de módulos.

- Simplicidad:  posibilitan  la  implementación  de  funciones  de 

la forma más comprensible posible. 

- Auto  descripción:  proporcionan  explicaciones  sobre 

implementación de las funciones.

- Instrumentación:  posibilitan  la  observación  del 

comportamiento del software durante su ejecución.
2. REVISIÓN DEL PRODUCTO
2.3 Flexibilidad
- Auto  descripción:  proporcionan  explicaciones  sobre 
implementación de las funciones.

- Generalidad:  proporcionan  amplitud  a  las  funciones 

implementadas. 

- Capacidad  de  expansión:  posibilitan  la  expansión  del 

software en cuanto a capacidades funcionales y datos. 

- Modularidad: proporcionan una estructura de módulos.
3. TRANSICIÓN DEL PRODUCTO
3.1 Reusabilidad
- Auto descripción: proporcionan explicaciones sobre implementación 
de las funciones.

- Generalidad: proporcionan amplitud a las funciones implementadas. 

- Modularidad: proporcionan una estructura de módulos.

- Independencia entres sistema y software: Atributos del software que 
determinan su dependencia del entorno operativo.

- Independencia del hardware: Atributos del software que determinan 
su dependencia del hardware. 
3. TRANSICIÓN DEL PRODUCTO
3.2 Interoperabilidad

- Modularidad: proporcionan una estructura de módulos.

- Compatibilidad  de  comunicaciones:  posibilitan  el  uso  de 

protocolos de comunicación.

- Compatibilidad  de  datos:  posibilitan  el  uso  de 

representaciones de datos estándar. 

- Estandarización de los datos: El uso de estructuras de datos y 
de tipos estándar a lo largo de todo el programa.  
3. TRANSICIÓN DEL PRODUCTO
3.3 Portabilidad

- Auto  descripción:  proporcionan  explicaciones  sobre  la 

implementación de las funciones.

- Modularidad: proporcionan una estructura de módulos.

- Independencia  entres  sistema  y  software:  Atributos  del 

software  que  determinan  su  dependencia  del  entorno 
operativo.

- Independencia  del  hardware:  Atributos  del  software  que 

determinan su dependencia del hardware. 
¡Gracias!
Modelo de calidad de
Software: BOEHM
INTEGRANTES:
Carrión Herrera. Carlos Alberto
Pretill Escobar. Genaro Víctor
Vargas Reyes, Abel Antony
INTRODUCCIÓN
• Este modelo de calidad fue propuesto por Barry Boehm en el año de 1978
• este define la calidad de software en términos de atributos cualitativos y los
mide usando métricas
• El modelo no es muy distinto al de McCall, porque muchos de sus factores de
calidad son los mismos
• presenta sus factores de calidad estructurados jerárquicamente de alto a bajo
nivel
CARACTERÍSTICAS
Características de alto nivel
• Utilidad per-ser cuan(usable, confiable eficiente) es el producto en
si mismo
• Mantenimiento, cuan fácil es modificarlo, entenderlo y retestearlo
• Utilidad general, si puede seguir usándose si se cambia el
ambiente
Características de nivel intermedio

• Portabilidad(utilidad general)
• Confiabilidad (utilidad per-se)
• Eficiencia (utilidad per-se)
• Usabilidad (utilidad per-se)
• Testeabilidad (mantenibilidad)
• Facilidad de entendimiento (mantenibilidad)
• Modificalidad o flexibilidad (mantenibilidad)
Características primitivas
• De portabilidad • De usabilidad
• Robuztes/integridad
• Independencia de dispositivos • Accesibilidad
• Auto-contención • Comunicación
• De confiabilidad • De testeabilidad
• Comunicación
• Auto-contención
• Auto descripción
• Exactitud • Estructuración
• Completitud • De entendibilidad
• Consistencia • Consistencia
• Robustez/integridad • Estructuración
• Concisidad
• De eficiencia • Legibilidad
• Accesibilidad • De modificalidad
• Eficiencia de uso de dispositivos • Estructuración
Comparación del modelo BOEHM
con el modelo McCall
• Aunque estos dos modelos parezcan similares, la diferencia está en que
McCall focaliza en medidas precisas de alto nivel.
• La mantenibilidad está más desarrollada en Boehm.
• En este modelo es difícil que las características y sub-características sean
siempre perfectamente independientes
• No siempre existe una relación perfectamente lineal entre los valores de las
métricas y las características que deben estimar.
Ventajas y desventajas
• este modelo tiene como ventajas que presenta un alto rango de
características primitivas, además, integra el desarrollo del software con el
mantenimiento. En cuanto a desventajas encontramos que es un modelo
costoso y debe seguir estrictamente un protocolo para su buen
funcionamiento.