Unidad 2 Asc

INSTITUTO TECNOLOGICO DE VILLAHERMOSA
MATERIA:
ASEGURAMIENTO Y CALIDAD DEL SOFTWARE
UNIDAD: 2
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
CATEDRATICO:
ING. MIGUEL ANGEL MARTINEZ DE LA CRUZ
ALUMNOS:
WILLIAM GARCIA FRANCO
DANIEL CRUZ SALVADOR
LEYVI SILVAN SILVAN
MARIA ANGELICA ARCOS ARCOS
LEANDRO ANTONIO TOTOSAO HERNANDEZ
PEDRO LUIS HERNANDEZ HERNANDEZ
AULA K-54
VILLAHERMOSA, TABASCO MARZO DE 2011.

4
Modelos de Proceso y de su Capacidad

 CMM (Capability Maturity Model)
 Desarrollado por SEI (Software Engineering Institute), org. creado por
el DoD de USA
 Fuerte impacto en mejora del proceso
 Estipula un Camino para la mejora
 Areas Clave que se deben atacar CMMI

Proceso de Mejora Continuo: CMM y CMMI
CMM (Década del ’90): Características
 Mide la capacidad del proceso seguido para desarrollar software incrementando la predictibilidad
en cuanto a costos, tiempos y calidad lograda.
 Es el modelo más utilizado en la industria de software.
CMMI (A partir del 2001): Características

 Sirve como guía única para la mejora de múltiples disciplinas tales como la Ingeniería de sistemas
(SE), Ingeniería de software (SWE), el desarrollo integrado entre el producto y el proceso (IPPD)
y la gestión de compras y control de proveedores.
Objetivos que se persiguen:

 Determinar el nivel de madurez del Proceso de Desarrollo (Indicador de calidad)
 Servir de guía en el Proceso de Desarrollo permitiendo la Mejora Continua de la organización.

Características principales:
Para cada nivel de madurez se describen áreas de proceso a ser desarrolladas y para
cada Área de Proceso se establecen niveles de capacidad a ser alcanzados.
Cada área de proceso se asocia a uno de los 5 niveles de madurez.
Una organización alcanza un nivel de madurez determinado cuando ha puesto en
práctica todas y cada una de las áreas de proceso aplicables a ese nivel y a todos los
niveles inferiores.
Los niveles de capacidad se designan para cada área de proceso, proporcionando un
orden recomendado para acercarse a la mejora dentro de cada área de proceso.
Permite flexibilidad en las áreas a seleccionar para mejorar y para alinearse a los
objetivos del negocio definidos por la organización.
Es compatible con ISO 9000:2000
Sienta las bases para que las organizaciones del sector de desarrollo de software se
encaminen hacia el ciclo de mejora continua.

7
CMM SW v1.1(Capability Maturity Model)

Mejora continua Nivel 5:
del proceso Optimizante
Control del Nivel 4: Gestión del
proceso Gestionado Cambio
Definición Nivel 3: Gestión
del Proceso Definido Cuantitativa
Disciplina
Nivel 2: Gestión de
del Proceso
Repetible Ingeniería
Madurez
Nivel 1: Gestión del
Inicial Proyecto
8
Nivel 1 - Inicial
Desempeño basado en la competencia del personal
 frecuentemente la organización vive apagando incendios
 aparecen héroes
 dificultad para encarar mejoras a largo plazo
 la organización actúa esencialmente por reacción
 Promueve alta calidad y desempeño excepcional, posible siempre que se logre contar
con los mejores
 Impredecible (para bien y para mal)
 Caracterizado por problemas que son esencialmente de gestión, no técnicos
Salidas
Entran los requerimientos y otras
Entradas entradas y salen los productos
9
Nivel 2 - Repetible
La organización
 estableció la gestión efectiva de los proyectos de software
 el proceso de gestión del software está documentado
 usa políticas organizacionales para guiar a los proyectos en establecer los
procesos de gestión
 repite prácticas exitosas desarrolladas en proyectos previos
Entradas
Salidas
Reqs. Diseño Codif. Prueba
Existen riesgos al presentarse

nuevos desafíos.
10
Nivel 3 - Definido
 El proceso para la gestión y las actividades de ingeniería está documentado e
integrado en un proceso estándar para la organización.
 Todos los proyectos usan una versión documentada y aprobada del proceso
estándar de la organización.
 Una task force dedicada al proceso de Ingeniería de software ha sido
establecido para focalizar y liderar esfuerzos en la mejora.
Entradas Salidas

11
Nivel 4 - Gestionado
La organización
 aplica los principios de la gestión estadística de procesos para controlar el
proceso del software
 la dirección tiene bases objetivas para tomar decisiones,
 puede predecir el desempeño en un entorno cuantificado realista
 usa los datos como base para decisiones, objetivos y mejoras
Reacción frente a las mediciones fuera de

rango de control
Entradas
Salidas
Productos y Proceso Gestionados

cuantitativamente
12
Nivel 5 - Optimizante
La organización
 identifica y elimina causas de desempeño pobre
 mejora continua del proceso en base a gestión del cambio del proceso y de
la tecnología
Foco en la mejora del proceso y tecnología
Entradas
Salidas
Cambio controlado se
institucionaliza
13
Estructura del modelo CMM

Niveles de Madurez
indican contiene
Capacidad del proceso Areas Clave del Proceso

logra organizada por
Objetivos Características Comunes
refiere a
Implementación o Prácticas Clave
Institucionalización
describe
Infraestructura o actividades
15
Algunas Características del Desarrollo de SW

– Los requerimientos de los usuarios
 La satisfacción del cliente se ha no siempre son satisfechos
convertido en un objetivo crítico para

seguir siendo competitivo – Las fechas de entrega de software
comúnmente se retrasan
– Los costos de producción de
 El costo y el tiempo de desarrollo son
software son generalmente más
determinantes en la mayoría de los
altos de lo estimado
planes de negocio
– Los procesos de administración de
 El software se desarrolla de manera proyectos de software son poco
artesanal practicados
– El éxito de los proyectos depende
comúnmente de “héroes”

Dos Tecnologías de Vanguardia
Personal Software Process (PSP)
Team Software Process (TSP)
 Creadas por Watts Humphrey (SEI)

 Orígenes en CMM
 Motivación
 Implementación de CMM
 Administración de tiempo y Costo
 Administración de calidad
 Reducir el tiempo de desarrollo
 Estado Actual
 En uso con muy buenos resultados
 Efectividad en acelerar SPI
 Diseminando esta tecnología
16 TABASCO MARZO DE 2011.

VILLAHERMOSA,
17
Mapeo de Modelos yNiveles

Procesos
Organizacionales
CMM Organización
Equipos
TSP
Personas
PSP

PSP (Personal Software Process)
•Proporciona una serie de principios al ingeniero para llevar a
cabo un proceso personal disciplinado
•Asiste a los ingenieros en la realización de planes precisos
•Determina los pasos que los ingenieros deben seguir para
mejorar la calidad del producto
•Establece bancos de pruebas para medir la mejora del proceso
personal, y
•Determina el impacto que los cambios del proceso tienen sobre
el rendimiento del ingeniero

TSP (Team Software Process)

Capability Maturity Model
for Software SW-CMM
Recomendaciones para
Mejorar el Proceso del
Software
Organizaciones
Maduras e Inmaduras
 En una organización inmadura…

 los procesos de software son improvisados por los
desarrolladores y su administración.
 si hay procesos definidos, generalmente no se
siguen.
 los administradores son reaccionarios y se enfocan a
resolver crisis inmediatas (apaga fuegos).
 la calendarización y el presupuesto son
rutinariamente excedidos por que no se basan en
estimaciones realistas.

Organizaciones
Maduras e Inmaduras
 En una organización inmadura…

 cuando los deadlines son impuestos, la funcionalidad
del producto se compromete para cumplir el
calendario.
 no hay manera objetiva de evaluar la calidad de un
producto.
 la calidad del producto no se puede predecir.
 las actividades como revisiones y pruebas son
recortadas o eliminadas cuando el proyecto se
retrasa.

Organizaciones
Maduras e Inmaduras
 En una organización madura …

 El proceso del software es comunicado al personal
existente y al nuevo.
 El proceso a implantar es el adecuado y es consistente con
la manera como se hacen las cosas.
 El proceso es actualizado siempre que sea necesario y las
mejoras se desarrollan con pruebas piloto y/o análisis de
costo beneficio.
 Los papeles y las responsabilidades son claras para todos.

Organizaciones
Maduras e Inmaduras
 En una organización madura …
 los administradores monitorean la calidad de los
productos de software y la satisfacción del cliente.
 hay una manera objetiva y cuantitativa de medir la calidad
del producto.
 la calendarización y los costos se basan en rendimientos
históricos y son realistas.
 los resultados esperados de costo, calendarización,
funcionalidad, y calidad del producto son generalmente
alcanzados.

Conceptos Fundamentales
 Proceso del Software
 el conjunto de actividades, métodos, prácticas, y
transformaciones que la gente usa para desarrollar y
mantener el software y sus productos asociados (los
entregables, por ejemplo los planes del proyecto, los
documentos del diseño, el código, los casos de
prueba, manuales de usuario, etc.)
Derechos Reservados, 1999

El Proceso del Software
Procedures
& Methods
Process
People Tools

El Proceso del Software
 Un proceso es una secuencia de pasos realizados con un
propósito específico.
 En pocas palabras, un proceso es lo que tu haces.
 Una descripción o definición del proceso no es un proceso.
 Sólo cuando las actividades son realizadas o los métodos
utilizados, se puede hablar de un proceso.
 Los estándares o procedimientos que no son utilizados son
simplemente “shelfware” y el proceso es ad hoc.

 Capacidad del Proceso del Software
 el rango de resultados esperados que pueden ser
logrados siguiendo el proceso del software. La
capacidad del proceso del software de una
organización provee el medio de predecir el
resultado más probable que se puede esperar para el
siguiente proyecto de software que la organización
desarrolle.

 Rendimiento del Proceso del Software

 representa el resultado real alcanzado por seguir el proceso del
software. El rendimiento se enfoca en los resultados reales, la
capacidad en los resultados esperados.
 Basados en los atributos reales y el contexto en el que se condujo
el proyecto, el rendimiento actual puede no reflejar la capacidad
total de la organización
 Ejem. cambios radicales en la aplicación o la tecnología pueden
poner al personal en una curva de aprendizaje ocasionando que
el rendimiento sea corto comparado con la capacidad.

 Madurez del Proceso del Software
 el grado en el que un proceso específico es definido,
administrado, medido, controlado y efectivo.
 La madurez indica un potencial de crecimiento en la
capacidad e indica lo valioso del proceso de software de
una organización y la consistencia con la cual se aplica en
los proyectos de la organización.
 Implica que la productividad y calidad resultante pueden
ser mejorados a lo largo del tiempo.

 Institucionalización del Proceso del

Software
 es construir una infraestructura y una cultura
corporativa que soporte los métodos, las
prácticas y los procedimientos de la empresa, de
manera que perduren después que se hayan ido
los que la definieron originalmente.

CALIDAD DEL SOFTWARE
CMMI - CAPABILITY MATURITY MODEL
El objetivo del presente material es brindar un análisis sobre la utilidad

de aplicar los, lineamientos del Capability Maturity Model Integration
(CMMI
) en la obtención de productos de software de calidad.
contexto actual de la ingeniería de software.

La crisis del software y la realidad del software.
Crisis del software
1960
El software no cubre todos los requisitos
 El software falla muy a menudo
 El software debe ser modificado frecuentemente
 Los proyectos se retrasan o incluso se abandonan
 Los proyectos exceden los costos previstos

A modo de ejemplo, un reporte sobre contratos de desarrollo de software,
realizado
en 1979 por el General Accounting Office (USA) revelaba los siguientes
datos:

Realidad del software
Por otro lado, existen hechos innegables relacionados con la ingeniería de

software,
algunos de ellos son los siguientes:
 Existe una necesidad de software cada vez más complejo y crítico

 La producción de software es una actividad creativa e intelectual realizada,
principalmente, por seres humanos, que no se puede delegar a máquinas
 Las técnicas de ingeniería de software deben ser acompañadas por:
 Sentido común
 Competencia
Experiencia
 Aceptación del principio de “No silver bullet”
Procesos maduros e inmaduros.

Paradigma de la calidad

Aplicar el paradigma no es tarea fácil en la ingeniería de software
El profesional de ingeniería de software cuenta con una batería de

Conceptos y actividades relacionadas con la calidad
Testing
 Revisiones
 Verificaciones
 Auditorías
SQA
Este desconcierto se puede sintetizar en los siguientes interrogantes:
 ¿Por dónde se empieza?

 ¿Se debe priorizar un punto de vista?
 ¿Qué punto de vista se prioriza?
 ¿La mejora debe ser gradual?
 ¿Cómo se estructura la mejora?
 ¿Cuánto se tarda en mejorar?
 ¿Cuánto cuesta mejorar?
 ¿Vale la pena?
Algunas de las organizaciones, modelos y normas que intentan dar respuestas a
éstos interrogantes son los siguientes: ISO,IEEE,SEI Y ESA.
CMM - CAPABILITY MATURITY MODEL
Orígenes y evolución
Fue concebido en el año 1987 por el Instituto de Ingeniería de Software (SEI)

de la
Universidad Carnegie Mellon (CMU).
Su principal objetivo era calificar a proveedores de software del Departamento
de
Defensa (DoD) de USA, pero el modelo fue incorporado paulatinamente por
numerosas empresas.
Es actualmente un esquema que representa un camino de mejoramiento recomendado

para organizaciones que quieren incrementar la capacidad de su
proceso de software.
Usos. El CMM soporta los siguientes usos:
Comprender las actividades necesarias para planear e implementar un programa

de mejora del proceso de software (SPI)
 Definir y mejorar el proceso de software
 Identificar fortalezas y debilidades en las organizaciones
 Identificar los riesgos de seleccionar entre diferentes proveedores de software

USOS Y MEJORAS QUE SOPORTA EL CMM
Mejora la visibilidad sobre los Proyectos: En el sentido de que el equipo y
cada integrante sabe en qué trabaja, así como la Gerencia y la Dirección.
Cada uno sabe el estado de cada uno de los proyectos, se tienen datos.
Mejora la comunicación: Cada participante, en su rol, sabe cuales son sus

responsabilidades y compromisos en los proyectos en los que participa, y
tiene la información para hacer sus tareas.
Mejora la planificación: Permite que se establezcan planes más realistas y

de acuerdo a lo que la empresa es capaz de hacer. Toma tiempo aceptar la
realidad (sobre todo al jefe), pero beneficia mucho a los proyectos y a la
organización para, a partir de esa base, mejorar la productividad, eficiencia y
calidad.
Reduce el Re-trabajo: Reduce el re-trabajo al mejorar la planificación y

seguimiento, la comunicación, las responsabilidades, y la detección temprana
de errores.
Mejora la calidad del producto: Con una apropiada obtención de
requerimientos, la detección temprana de errores, uso de inspecciones y
pruebas, la rastreabilidad de los requerimientos, la implementación de
prácticas de ingeniería de software, la planificación y seguimiento, y la
capacitación adecuada de los participantes. VILLAHERMOSA, TABASCO MARZO DE 2011.
Conocimiento de la organización: Al contar con más información (métricas)
la organización es más predecible y sabe de lo que es capaz de hacer
(retroalimenta al proceso y a la planificación). Esto beneficia también al área
de ventas ya que conoce los márgenes de maniobra a la hora de vender un
proyecto.
Mejora el ambiente de trabajo: Si bien al principio hay tensión por la
implementación de las nuevas prácticas, cuando todos trabajan con el proceso
se genera una política de puertas abiertas, cada uno sabe que hacer, se
aceptan ideas, se generan discusiones con sentido, se participa en mejorar el
proceso, el producto y la relación con el cliente. Mejor comunicación.
Se genera una Base de Conocimiento: Con la ejecución de los procesos y
los proyectos se genera una base de conocimiento muy rica e importante para
la organización. Procesos, planes, ejemplos, métricas, estimaciones, lecciones
aprendidas, capacitaciones, historia; accesible y que puede ser utilizada. El
tiempo de incorporación de una persona es más rápido al tener acceso a esta
base.
Se tiene una visión compartida: Se genera un ambiente de equipo al contar
con una visión compartida de lo que quiere la organización, de sus objetivos y
de cómo cada uno participa y aporta al logro de estos objetivos.
Un cliente más informado: El cliente participa más en el proyecto, conoce el
estado de su proyecto y sabe cuáles son sus responsabilidades.
Fundamentos
Los siguientes son los fundamentos del modelo:

 La madurez recorre diferentes etapas
 La clave del crecimiento es entender dónde se está y a dónde se quiere llegar
 El proceso se mejora evolucionando a partir de lo preexistente
 El progreso requiere concentrar los esfuerzos en pocas áreas
Generalidades
A modo de introducción a temas que se desarrollarán a lo largo del artículo, se

mencionan las siguientes características del CMM:
 El modelo incorpora los principales elementos del paradigma de la calidad

 El modelo identifica:
 5 niveles de madurez
 Mejoras claves requeridas por cada nivel
 Un orden de prioridades para escalar a niveles superiores
 El SEI proporciona:
 Servicio de apreciaciones (Assessments) del proceso de software (SPA)
 Programa de evaluación de la capacidad del software (SCE)
Estructura
La estructura completa del modelo se representa en el siguiente gráfico:

NIVEL 1 - INICIAL
 Proceso ad-hoc y a veces caótico
El éxito depende del esfuerzo individual
NIVEL 2 REPETIBLE.
Se concentran en establecer controles básicos de gestión de proyectos:
Control y supervisión de proyectos
La disciplina del proceso permite la repetición de éxitos anteriores en proyectos
Similares
NIVEL 3 – DEFINIDO
Direccionan aspectos organizacionales y del proyecto, lo que establece una
infraestructura que institucionaliza procesos de ingeniería de software y gestión, a lo largo de todos los proyectos:
Programa de entrenamiento
El proceso para gerentes e ingenieros está documentado e integrado en un
proceso estándar para la organización
NIVEL 4 – ADMINISTRADO
Se concentran en establecer una comprensión cuantitativa y cualitativa del proceso y
de los productos:
Administración de la calidad del software
 Existen mediciones detalladas del proceso y calidad del producto
NIVEL 5 – OPTIMIZADO
Cubren los aspectos de la organización y de los proyectos que deben atenderse
Para implementar una mejora continua y medible del proceso de software:
Prevención de defectos
Administración del cambio del proceso
Administración del cambio tecnológico
 La organización busca identificar aquellos elementos más débiles del proceso y optimizarlos sobre la base de un análisis
defecto-causa y prevención de defectos

Aspectos comunes
Son atributos que permiten que la implementación o institucionalización de un área clave de proceso sea
efectiva, repetible y perdurable, por ejemplo:
Compromisos para la ejecución

 Habilidad para ejecutar
 Actividades a ejecutar
Practicas clave
Describen una infraestructura o actividades necesarias para implementar o

institucionalizar un área clave de proceso.
Evaluación del proceso

Finalmente, la evaluación tiene como objetivo determinar y evaluar la capacidad y madurez del proceso de software de
una organización, y ubicarlo en un nivel del CMM.
Existen dos tipos de evaluaciones:
Apreciación (Assessment) del proceso de software (SPA): Realizada por

profesionales del SEI o autorizados o independientes, en conjunto con personal de la organización. Se asemeja a contratar
una consultoría.
Evaluación de la capacidad del software (SCE): Realizado por agentes gubernamentales a contratistas o proveedores de
software. Se asemeja a una auditoría externa.
Ambas evaluaciones se basan en las respuestas, por Si o por No, a un cuestionario y en la aplicación de un algoritmo
sobre las mismas.

ESTADISTICAS SOBRE LA APLICACION DEL CMM
A continuación se presenta una serie de estadísticas y observaciones relativas a la
aplicación del modelo:
El nivel de madurez de las organizaciones, según un estudio del Software
Engineering Measurement and Analisys Team del SEI, realizado en Marzo de 1996,
sobre un total de 477 organizaciones, 83% de las cuales corresponden a USA, es el
siguiente:

Los cambios en el nivel de madurez de las organizaciones, según un estudio del Software
Engineering Measurement and Analisys Team del SEI, realizado en Marzo de 1996 sobre un total
de 28 re-apreciaciones, es el siguiente:
Algunos datos promedio de un estudio realizado sobre los primeros 3 niveles (Estudio de Junio de 1997 -
Fnte: [1]) son los siguientes:
 Tiempo requerido para pasar del nivel 1 al 2: 26 meses
 Tiempo requerido para pasar del nivel 2 al 3: 24 meses
 Inversión aproximada requerida: 1400 U$S por año por ingeniero de software
 Reducción de defectos post-release alcanzada: 39% por año
 Productividad ganada: 35% por año
 Relación costo/beneficio lograda: 1 a 5
Algunas observaciones del estudio realizado sobre los primeros 3 niveles (Estudio
de Junio de 1997 - Fuente: [1]) son las siguientes:
Mejora en la capacidad para alcanzar:
Cronogramas y presupuestos previstos
 Calidad del producto requerida
 Mejora de la moral del equipo de desarrollo
 Baja la satisfacción del cliente en nivel 2 y sube considerablemente en el nivel 3
Simbología y significado
Óvalo: Inicio y término (Abre y/o cierra el diagrama).
Rectángulo: Actividad (Representa la ejecución de una o más actividades o

procedimientos).
Rombo: Decisión (Formula una pregunta o cuestión).
Triangulo boca abajo: Archivo definitivo (Guarda un documento en forma

permanente).
Triangulo boca arriba: Archivo temporal (Proporciona un tiempo para el

almacenamiento del documento

DEFINICION
Un diagrama de flujo es una representación gráfica de un algoritmo o proceso. Se utiliza en

disciplinas como la programación, la economía, los procesos industriales y la psicología
cognitiva.
Estos diagramas utilizan símbolos con significados bien definidos que representan los pasos del
algoritmo, y representan el flujo de ejecución mediante flechas que conectan los puntos de inicio
y de término.
Tipos de diagrama de flujos.
Formato vertical: En él el flujo o la secuencia de las operaciones, va de arriba hacia abajo
Formato horizontal: En él, el flujo o la secuencia de las operaciones, va de izquierda a derecha.
Formato panorámico: El proceso entero está representado en una sola carta y puede apreciarse
de una sola mirada mucho más rápido que leyendo el texto, lo que facilita su comprensión, aun
para personas no familiarizadas.
Registra no solo en línea vertical, sino también horizontal, distintas acciones simultáneas y la
participación de más de un puesto o departamento que el formato vertical no registra.
Formato Arquitectónico: Describe el itinerario de ruta de una forma o persona sobre el plano
arquitectónico del área de trabajo. El primero de los flujo gramas es eminentemente descriptivo,
mientras que los utilizados son fundamentalmente representativos.

Símbolos del flujograma
Inicio y final
del proceso Medición
Actividad o paso
individual
Documento
Punto de
decisión
Conector Datos
almacenados

Diagrama de flujo de proceso y soporte
Un diagrama de flujo

CARACTERISTICAS DEL NIVEL
 Características Nivel:
o Existencia de políticas y procedimientos.
o Objetivo es lograr la institucionalización de los
o procesos de gestión.
o Planeamiento y Gestión.
o Compromiso basado en proyecto previos.
o Requerimientos y Productos delimitados.
o Estándares de proyectos
o Relación con contratistas.

ÁREAS CLAVE
DEL PROCESO
POR NIVEL
Áreas Clave del Proceso (KPAs)
El modelo CMM establece un conjunto de

prácticas o procesos clave agrupados en
Áreas Clave de Proceso (KPA - Key
Process Area).
Grupo de Actividades que satisfacen un conjunto

de objetivos

Áreas Clave del Proceso (KPAs)
Para cada área de proceso define un conjunto de buenas
prácticas que habrán de ser:
•Definidas en un procedimiento documentado.

•Provistas (la organización) de los medios y formación
necesario.
•Ejecutadas de un modo sistemático, universal y
uniforme (institucionalizadas).
•Medidas.
•Verificadas.
Nivel Area clave del proceso
1) Inicial
2) Repetible Ingeniería de requerimientos
Planificación de proyectos
Control y seguimiento de proyectos
Gerencia de subcontratación
Aseguramiento de la calidad del software (S/W)
Gerencia de la configuración del S/W
3) Definido Coordinación de la definición y mejora del proceso
Programa de adiestramiento
Integración Gerencia e Ingeniería de S/W
Ingeniería de productos de S/W
Coordinación inter-grupos
Revisiones
4) Gerenciado Gerencia cuantitativa de procesos
Gerencia de la calidad del software
5) Optimizado Prevención de defectos
Gerencia del cambio tecnológico y del proceso
Nivel 2
Requirements Management
Gestión de Requerimientos
Descripción:
 Establecer un entendimiento común entre el usuario y los
requerimientos del usuario en el proyecto de Software que
serán guía del mismo.
 Este acuerdo con el usuario es la base para la planeación
(Software Project Planning) y el manejo (Software Project
Tracking and Oversight) del proyecto de software.
 El control de la relación con el cliente depende del
seguimiento efectivo del control del proceso (Software
Configuration Management)
Calidad en el desarrollo de Software

Nivel 2
Software Project Planning
Planeación del Proyecto de SW
Descripción:
 La propuesta (Software Project Planning) es
establecer planes razonables para desarrollar la
ingeniería de software y para administrar el proyecto
de software.
 Estos planes son las bases necesarias para la
administración del proyecto de software ( como se
describe en Software Project Tracking and Oversight)
 Sin planes realistas, la administración de proyectos
efectivos no puede ser implementada.

Nivel 2
Software Project Tracking and Oversight
Descuido y Rastreo del Proyecto de Software
Descripción:
 La propuesta (Software Project Tracking and
Oversight) es establecer una visibilidad
adecuada dentro del progreso actual.
 Entonces la gestión puede tomar acciones
efectivas cuando el desarrollo del proyecto de
software se desvía significativamente de los
planes iniciales de software.

Nivel 2
Software Configuration Management
Gestión de la Configuración del SW
Descripción:
 Se define como una disciplina que aplica dirección y vigilancia
técnica y administrativa dentro del ciclo de vida en algunos etapas:
1. Identifica y documenta la funcionalidad y características físicas en
las etapas de configuración.
2. Control de cambios en las etapas de configuración y la
documentación relacionada.
3. Documenta y reporta información necesaria para una efectiva
gestión de la configuración, incluyendo el estado de los cambios
propuestos y el estado de implementación de los cambios aprobados.
4. Los puntos de configuración de la auditoria para verificar su
correspondencia con las especificaciones, dibujos, documentos de
control de interfases y otros requerimientos contractuales.

Nivel 2
Software Quality Assurance
Aseguramiento de la Calidad del SW
Descripción:
 La propuesta es proveer gestión con una apropiada
visibilidad dentro del proceso empezando a
utilizarla dentro del proyecto de software y en los
productos que se están construyendo.
 El aseguramiento de la calidad del SW es una
parte integral de los procesos de gestión e
ingeniería de software.

Nivel 2
Software Contract Management
Gestión de los Contratos de SW
Descripción:
 Se define como una disciplina que aplica dirección y vigilancia
técnica y administrativa dentro del ciclo de vida en algunos etapas:
1. Identifica y documenta la funcionalidad y características físicas en
las etapas de configuración.
2. Control de cambios en las etapas de configuración y la
documentación relacionada.
3. Documenta y reporta información necesaria para una efectiva
gestión de la configuración, incluyendo el estado de los cambios
propuestos y el estado de implementación de los cambios
aprobados.
4. Los puntos de configuración de la auditoria para verificar su
correspondencia con las especificaciones, dibujos, documentos de
control de interfases y otros requerimientos contractuales.

NIVEL 3
Peer Reviews
Revisiones Exhaustivas
Descripción:
 La propuesta es remover defectos de los productos de
software temprana y eficientemente.
 Un efecto importante de esta corolario es desarrollar un
mejor entendimiento del trabajo de los productos de
software y que los defectos pueden ser prevenidos.
 La revisión exhaustiva es un importante y efectivo
método que es llamado Software Product Engineering
(Ingeniería del producto de SW) y puede ser
implementada a través de inspecciones de estilo Fagan
(Fagan 86), revisiones estructuradas o a través de
métodos de revisión colegiales (Freedman 90)

NIVEL 3
Intergroup Coordination
Coordinación Intergrupal
Descripción:
 La propuesta de la Coordinación Intergrupal es establecer un
medio para que el grupo de Ingeniería de Software (Software
Engineering Group) participe activamente con los otros
grupos de ingeniería.
 Esto provocará que el proyecto cubra de una mejor manera
(efectiva y eficazmente )las necesidades del usuario.
 La coordinación Intergrupal es un aspecto interdisciplinario de
la Gestión de Software Integrada (Integrated Software
Management) que extiende más allá la ingeniería de software.
 No sólo debe integrarse el proceso de software, sino que las
interacciones de los grupos de ingeniería de software con otros
grupos deben ser coordinadas y controladas.

Nivel 3
Software Product Engineering
Ingeniería del Producto de SW
Descripción:
 La propuesta es desarrollar consistentemente un
bien definido proceso de ingeniería que integre
todas las actividades de ingeniería de software
para producir efectiva y eficientemente
productos de software correctos y consistentes.
 La ingeniería del producto de SW describe las
actividades técnicas del proyecto por ejemplo: el
análisis de requerimientos, diseño, código y
prueba.

Nivel 3
Integrated Software Management
Gestión del SW Integrado
Descripción:
 La propuesta es integrar la ingeniería de software y las actividades
de gestión dentro de un proceso de software definido y coherente
que sea adaptado dentro del proceso de software estándar de la
organización y los procesos activos relacionados, que son descritos
en la Definición del proceso de la Organización (Organization
Process definition).
 Este adaptamiento está basada en el ambiente de negocio y las
técnicas necesarias del proyecto, como se describe en la Ingeniera
del Producto de SW.
 La gestión del SW integrado evoluciona desde la Planeación del
Proyecto de Software y del Descuido y Rastreo del Proyecto de
Software del nivel. 2

Nivel 3
Training Program
Programa de Capacitación
Descripción:
 La propuesta es desarrollar las habilidades y el
conocimiento de los individuos para que
puedan efectuar sus roles efectiva y
eficientemente.
 La capacitación es una responsabilidad
organizacional, pero los proyectos de software
deben identificar sus necesidades de
habilidades y proveer la capacitación necesario
cuando las necesidades del proyecto son únicas.

Nivel 3
Organization Process Definition
Definición del proceso de la Organización
Descripción:
 La propuesta es desarrollar y mantener un conjunto de
recursos de los procesos de software usables que
mejoren de manera global la capacidad de los procesos
de software de la organización.
 El resultado primario de las actividades del Proceso de
Enfoque de la Organización (Organization Process
Focus ) es un conjunto de recursos de los procesos del
software, que son descritos en la Definición del Proceso
de la Organización.
 Estos recursos son usados por los proyectos del software
como se describe en la Gestión del Software Integrado.

Nivel 3
Organization Process Focus
Enfoque del proceso de la Organización
Descripción:
 La propuesta es establecer la responsabilidad
organizacional para las actividades del proceso de
software que mejoren la capacidad global de los
procesos de software de la organización.
 El resultado primario de las actividades del Enfoque
del proceso de la Organización es un conjunto de
recursos del proceso de software, que son descritos
en la Definición del Proceso de la Organización.
 Estos recursos son usados en los proyectos de
software como se describe en la Gestión del Software
Integrado.

Nivel 4
Software Quality Management
Gestión de la Calidad del Software
Descripción:
 La propuesta es desarrollar un
entendimiento cuantitativo de la calidad de
los proyectos de software y alcanzar
objetivos de calidad específicos.
 La gestión de la calidad del software aplica
un programa comprensivo de medida a los
productos de trabajo del software descritos
en la Ingeniería del Producto de SW.

Nivel 4
Quantitative Process Management
Gestión Cuantitativa del Proceso
Descripción:
 La propuesta es controlar el proceso de desarrollo del
proyecto de software cuantitativamente.
 El desarrollo del proceso de software representa los
resultados actuales alcanzados siguiendo el proceso de
software.
 El enfoque esta en identificar causas especiales de variación
dentro de un proceso estable de medición y correctitud,
apropiado a las circunstancias de desviación.
 La gestión del proceso cuantitativo agrega un programa de
medida comprensiva a las prácticas de Definición del Proceso
de Software, Gestión del Software Integrado , Coordinación
Intergrupal y Revisiones Exhaustivas.

KPA’S Nivel 5
 Process Change Management
 Technology Change Management
 Defect Prevention

Nivel 5
Process Change Management
Gestión del Cambio del Proceso
Descripción:
 La propuesta es mejorar continuamente los
procesos de software usados en la organización
con la intensión de mejor la calidad del software,
incrementar la productividad y decrementar el
tiempo del ciclo de vida del desarrollo del
producto.
 La gestión del cambio del proceso toma las
mejoras incrementales de la gestión del cambio
Tecnológico y las hace viables para la
organización entera.

Nivel 5
Technology Change Management
Gestión del cambio tecnológico
Descripción:
 La propuesta es el identificar beneficios de las
nuevas tecnologías( por ejemplo, herramientas,
métodos y procesos) y transferirlos a la
organización de una manera ordenada, como se
describe en la Gestión del cambio del proceso.
 El enfoque de la gestión del cambio
tecnológico esta en implementar una
innovación eficientemente en un mundo
cambiante.

Nivel 5
Defect Prevention
Prevención de Defecto
Descripción:
 Las actividades envueltas en la identificación de
defectos o potenciales defectos y en la prevención
de estos desde que son introducidos en el producto.
 El proyecto de software analiza defectos, identifica
sus causas y los define en el proceso del software,
como se describen en la Gestión del Software
Integrado.
 Los cambios del proceso de valor general son
transmitidos a otros proyectos de software, como se
describe en la Gestión del Cambio del Proceso.

Es el punto hasta el cual un determinado proceso es
explícitamente definido, administrado, medido,
controlado y efectivo.

Método SCAMPI
El SCAMPI (Standard CMMI Appraisal Method for Process Improvement) es un
método desarrollado por Instituto de Ingeniería de Software (SEI) para evaluar el
estado de los procesos de software de una organización basado en los modelos CMMI.
• Un SCAMPI C es el de menor duración y alcance, y es

utilizado para ver el uso de los procesos en la
organización y de las iniciativas de mejora con relación
al modelo CMMI.
• Un SCAMPI B es de mayor duración que un C y su
alcance permite identificar la implementación del
proceso en la organización con una muestra más amplia
de información.
• Un SCAMPI A es el de mayor duración y permite ver la
institucionalización de los procesos en la organización.

Herramientas de evaluación para CMMI

Bibliografía
Juan Antonio Vega Fernández
Técnicas de Calidad en el Software

Unidad 2 Asc

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Unidad 2 Asc

Загружено:

Авторское право:

Доступные форматы

INSTITUTO TECNOLOGICO DE VILLAHERMOSA

VILLAHERMOSA, TABASCO MARZO DE 2011.

Modelos de Proceso y de su Capacidad

VILLAHERMOSA, TABASCO MARZO DE 2011.

CMMI (A partir del 2001): Características

Objetivos que se persiguen:

VILLAHERMOSA, TABASCO MARZO DE 2011.

VILLAHERMOSA, TABASCO MARZO DE 2011.

CMM SW v1.1(Capability Maturity Model)

Existen riesgos al presentarse

VILLAHERMOSA, TABASCO MARZO DE 2011.

Reacción frente a las mediciones fuera de

Productos y Proceso Gestionados

Foco en la mejora del proceso y tecnología

Estructura del modelo CMM

Capacidad del proceso Areas Clave del Proceso

Objetivos Características Comunes

Algunas Características del Desarrollo de SW

convertido en un objetivo crítico para

VILLAHERMOSA, TABASCO MARZO DE 2011.

 Creadas por Watts Humphrey (SEI)

16 TABASCO MARZO DE 2011.

Mapeo de Modelos yNiveles

VILLAHERMOSA, TABASCO MARZO DE 2011.

VILLAHERMOSA, TABASCO MARZO DE 2011.

VILLAHERMOSA, TABASCO MARZO DE 2011.

 En una organización inmadura…

VILLAHERMOSA, TABASCO MARZO DE 2011.

 En una organización inmadura…

VILLAHERMOSA, TABASCO MARZO DE 2011.

 En una organización madura …

VILLAHERMOSA, TABASCO MARZO DE 2011.

VILLAHERMOSA, TABASCO MARZO DE 2011.

Derechos Reservados, 1999

VILLAHERMOSA, TABASCO MARZO DE 2011.

VILLAHERMOSA, TABASCO MARZO DE 2011.

VILLAHERMOSA, TABASCO MARZO DE 2011.

 Rendimiento del Proceso del Software

VILLAHERMOSA, TABASCO MARZO DE 2011.

VILLAHERMOSA, TABASCO MARZO DE 2011.

 Institucionalización del Proceso del

VILLAHERMOSA, TABASCO MARZO DE 2011.

El objetivo del presente material es brindar un análisis sobre la utilidad

) en la obtención de productos de software de calidad.

contexto actual de la ingeniería de software.

VILLAHERMOSA, TABASCO MARZO DE 2011.

VILLAHERMOSA, TABASCO MARZO DE 2011.

Por otro lado, existen hechos innegables relacionados con la ingeniería de

algunos de ellos son los siguientes:

 Existe una necesidad de software cada vez más complejo y crítico

Procesos maduros e inmaduros.

VILLAHERMOSA, TABASCO MARZO DE 2011.

El profesional de ingeniería de software cuenta con una batería de

Este desconcierto se puede sintetizar en los siguientes interrogantes:

 ¿Por dónde se empieza?

Fue concebido en el año 1987 por el Instituto de Ingeniería de Software (SEI)

Es actualmente un esquema que representa un camino de mejoramiento recomendado

Usos. El CMM soporta los siguientes usos:

Comprender las actividades necesarias para planear e implementar un programa

VILLAHERMOSA, TABASCO MARZO DE 2011.

Mejora la comunicación: Cada participante, en su rol, sabe cuales son sus

Mejora la planificación: Permite que se establezcan planes más realistas y

Reduce el Re-trabajo: Reduce el re-trabajo al mejorar la planificación y