FUNDAMENTOS DE DESARROLLO DE SISTEMAS UNIDAD IV MODELOS DE PROCESO DE SOFTWARE

Fundamentos de Desarrollo de Sistemas Unidad IV
FUNDAMENTOS DE DESARROLLO DE SISTEMAS
UNIDAD IV
MODELOS DE PROCESO DE SOFTWARE
Modelo de Proceso de Software
(SPM) es una descripción de los aspectos
estructurales y de comportamiento de un proceso en el ámbito del desarrollo de software,
usando como formalismo algún lenguaje de modelización de procesos (Process Modeling
Language, PML). En los últimos 15 años, la modelización de procesos y, particularmente, de
procesos de software, ha adquirido una importancia creciente como mecanismo que debe
permitir, por un lado, una mejor comprensión de ese proceso con vistas a su evaluación y mejora
y, por otro, la posibilidad de lograr un cierto grado de automatización del mismo, tal como es
norma en otras disciplinas de la ingeniería.
Un reto fundamental de la modelización de procesos de software es el de encontrar un
PML (Process Modeling Language, PML) estándar para la descripción de los mismos. En este
sentido, en los últimos años se ha hecho un esfuerzo para tratar de adaptar UML (Unified
Modeling Language) los requisitos que plantean los procesos de software. Con ese objetivo han
nacido perfiles UML y metamodelos, como SPEM o PROMENADE, que tratan de proponer un
formalismo de modelización de procesos de software basado en UML.
El modelo de proceso de software es como “Una representación simplificada de un
proceso de software, representada desde una perspectiva específica. Por su naturaleza los
modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción
de un proceso real.” 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.
Instituto Tecnológico de Ciudad.Juárez
59
Fundamentos de Desarrollo de Sistemas Unidad IV
4.1 MODELO DE CASCADA.
El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de
ingeniería. Éste toma las actividades fundamentales del proceso de especificación, desarrollo,
validación y evolución y las representa como fases separadas del proceso.
El modelo en cascada consta de las siguientes fases:
1. Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos
con los usuarios del sistema. Se busca hacer esta definición en detalle.
2. Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se
establece la arquitectura total del sistema. Se identifican y describen las abstracciones y
relaciones de los componentes del sistema.
3. Implementación y pruebas unitarias: Construcción de los módulos y unidades de
software. Se realizan pruebas de cada unidad.
4. Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en
conjunto. Se entrega el conjunto probado al cliente.
5. Operación y mantenimiento: Generalmente es la fase más larga. El sistema es
puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras
de implementación. Se identifican nuevos requisitos.
La interacción entre fases puede observarse en la Figura 4.1. Cada fase tiene como
resultado documentos que deben ser aprobados por el usuario. Una fase no comienza hasta que
termine la fase anterior y generalmente se incluye la corrección de los problemas encontrados
en fases previas.
Instituto Tecnológico de Ciudad.Juárez
60
Fundamentos de Desarrollo de Sistemas Unidad IV
Figura 4.1: Modelo de desarrollo en cascada.
En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción entre
las distintas fases de desarrollo. Algunos problemas que se observan en el modelo de
cascada son:

Las iteraciones son costosas e implican rehacer trabajo debido a la producción y
aprobación de documentos.

Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las
siguientes fases.

Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean
ignorados o corregidos de una forma poco elegante.

Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario
por el largo tiempo de entrega del producto.

Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil
responder a cambios en los requisitos.
Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza
como parte de proyectos grandes.
Instituto Tecnológico de Ciudad.Juárez
61
Fundamentos de Desarrollo de Sistemas Unidad IV
4.2 MODELO DE ESPIRAL.
El Modelo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en
1985, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo son
una espiral, cada bucle es una actividad. Las actividades no están fijadas a priori, sino que las
siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.
Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se
desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones. La versión
incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se
producen versiones cada vez mas completas de ingeniería del sistema.
CARACTERISTICAS:

Es también al igual que el anterior un modelo evolutivo que combina el modelo clásico
con el diseño de prototipos.

Incluye la etapa de análisis de riesgos, no incluida anteriormente.

Es ideal para crear productos con diferentes versiones mejoradas como se hace con los
softwares modernos de microcomputadoras.

La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de
prototipos.

Este es el enfoque más realista actualmente.
El modelo en espiral se divide en un número de actividades estructurales, también
llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
Comunicación con el cliente: las tareas requeridas para establecer comunicación
entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras
informaciones relacionadas con el proyecto. Son todos los requerimientos.
Instituto Tecnológico de Ciudad.Juárez
62
Fundamentos de Desarrollo de Sistemas Unidad IV
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras
informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la
aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y
proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según
la evaluación de las representaciones del software creadas durante la etapa de ingeniería e
implementación durante la etapa de instalación.
Cuando empieza el proceso evolutivo, el equipo de ingeniería del software gira alrededor
de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito
de la espiral produce el desarrollo de una especificación de productos; los pasos siguientes en la
espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones mas
sofisticadas del software. Cada paso de la región de planificación produce ajustes en el plan del
proyecto. El coste y la planificación se ajustan según la reacción ante la evolución del cliente.
Instituto Tecnológico de Ciudad.Juárez
63
Fundamentos de Desarrollo de Sistemas Unidad IV
VENTAJAS:

El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de
computadora, no termina cuando se entrega el software.

Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el
cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.

Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en
cualquier etapa de evolución del producto.

Demanda una consideración directa de los riesgos técnicos en todas las etapas del
proyecto.

Reduce los riesgos antes de que se conviertan en problemáticos.
Pero al igual que otros paradigmas puede resultar difícil convencer a grandes clientes de
que el enfoque evolutivo es controlable. Si un riesgo importante no es descubierto y gestionado,
indudablemente surgirán problemas. El modelo en sí mismo es relativamente nuevo y no se ha
utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos.
Todavía tendrán que pasar muchos años antes de que se determine con absoluta certeza la
eficacia de este nuevo e importante paradigma.
La siguiente figura define un eje de punto de entrada en el proyecto. Cada uno de los
cubos situados a lo largo del eje representa el punto de arranque para un tipo diferente de
proyecto. Un proyecto de desarrollo de conceptos comienza en el centro de la espiral y
continuara hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar
dentro de un producto real, el proceso procede a través del cubo siguiente y se inicia un nuevo
proyecto de desarrollo.
Instituto Tecnológico de Ciudad.Juárez
64
Fundamentos de Desarrollo de Sistemas Unidad IV
PROBLEMAS:

Demostrar al cliente "exigente" (bajo contrato) que el enfoque evolutivo es controlable.

Requiere gran habilidad y experiencia para valorar el riesgo y saber cuando detener la
evolución.
4.3 MODELO INCREMENTAL.
El modelo incremental mitiga la rigidez del modelo en cascada, descomponiendo el
desarrollo de un sistema en partes; para cada una de las cuales se aplica un ciclo de desarrollo
(en cascada en la representación gráfica siguiente).
Ventajas

El usuario dispone de pequeños subsistemas operativos que ayudan a perfilar
mejor las necesidades reales del sistema en su conjunto.

El modelo produce entregas parciales en periodos cortos de tiempo, comparados
con el tiempo necesario para la construcción del sistema en su conjunto, y permite
la incorporación de nuevos requisitos que pueden no estar disponibles o no ser
conocidos al iniciar el desarrollo.
Inconvenientes
 Se necesitan pruebas de regresión

Pueden aumentar el costo debido a las pruebas
Instituto Tecnológico de Ciudad.Juárez
65
Fundamentos de Desarrollo de Sistemas Unidad IV
Algunas de las desventajas identificadas para este modelo son:

Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas).

Cada incremento debe aumentar la funcionalidad.

Es difícil establecer las correspondencias de los requisitos contra los incrementos.

Es difícil detectar las unidades o servicios genéricos para todo el sistema.
Combina elementos del modelo lineal con la filosofía de creación de prototipos. El primer
incremento a menudo es un producto esencial (núcleo), a partir de la evaluación se planea el
siguiente incremento y así sucesivamente. Es interactivo por naturaleza, es útil cuando el
personal no es suficiente para la implementación completa.
R
E
Q
U
I
S
I
T
O
S
Diseño
Codificación
Diseño
Pruebas
Codificación
Operación
Mantenim.
Integración
Pruebas
Diseño
Integración
Codificación
Sub-sistema
Sub-sistema
Operación
Mantenim.
Pruebas
SISTEMA
…
Aunque en la representación gráfica de la figura anterior, los desarrollos de cada
subsistema se solapan en el tiempo, en su aplicación real, el segundo y siguientes subsistemas
pueden comenzar una vez concluido el anterior.
Resulta Apropiado:
Desarrollo de sistemas en los que el cliente necesita disponer de parte de la funcionalidad
antes de lo que costaría desarrollar el sistema completo. Desarrollo de sistemas en los que por
razones del contexto interesa realizar la obtención de los requisitos de forma escalonada a través
de subsistemas.
Instituto Tecnológico de Ciudad.Juárez
66
Fundamentos de Desarrollo de Sistemas Unidad IV
Se sugirió el enfoque incremental de desarrollo (Mills 1980) como una forma de reducir
la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de
decisiones en los requisitos hasta adquirir experiencia con el sistema (ver Siguiente Figura) .
Es una combinación del Modelo de Cascada y Modelo Evolutivo. Reduce el rehacer
trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta
tener experiencia en el sistema. Durante el desarrollo de cada incremento se puede utilizar el
modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos
a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso,
evolutivo.
4.4 PROCESO DE DESARROLLO UNIFICADO.
El Proceso Unificado "es un proceso de desarrollo de software configurable que se
adapta a través de los proyectos variados en tamaños y complejidad. Se basa en muchos años de
experiencia en el uso de la tecnología orientada a objetos en el desarrollo de software de misión
crítica en una variedad de industrias por la compañía Rational", donde confluyen 'los tres
amigos' como se llaman a sí mismos o los tres grandes OO: Grady Booch, James Rumbaugh e
Ivar Jacobson.
El Proceso Unificado guía a los equipos de proyecto en cómo administrar el desarrollo
iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el
tiempo al mercado y los riesgos del proyecto. El proceso describe los diversos pasos involucrados
en la captura de los requerimientos y en el establecimiento de una guía arquitectónica lo más
pronto, para diseñar y probar el sistema hecho de acuerdo a los requerimientos y a la
arquitectura.
Instituto Tecnológico de Ciudad.Juárez
67
Fundamentos de Desarrollo de Sistemas Unidad IV
El proceso describe qué entregables producir, cómo desarrollarlos y también provee
patrones. El proceso unificado es soportado por herramientas que automatizan entre otras
cosas, el modelado visual, la administración de cambios y las pruebas.
Proceso Unificado y MSF; complementos tecnológicos
"Más que una metodología, Microsoft Solutions Framework (MSF) es una serie de
modelos flexibles interrelacionados que guían a una organización sobre como ensamblar los
recursos, el personal y las técnicas necesaria para asegurar que su infraestructura tecnológica y
sus soluciones cumplan los objetivos de negocio. MSF mantiene una relación clara entre los
objetivos de negocio y las implementaciones tecnológicas".
"MSF se puede utilizar por sí mismo o con otras herramientas y técnicas como el Proceso
Rational [Proceso Unificado] para planear, construir y administrar el desarrollo de soluciones de
negocio a la medida". "El proceso Unificado es un proceso de desarrollo de software configurable
que se adapta a proyectos que varían en tamaño y complejidad. Se basa en muchos años de
experiencia en el uso de la tecnología de objetos en el desarrollo de software de misión crítica en
una variedad de industrias. Uno de los componentes clave es el UML".
MSF proporciona las técnicas ligadas a la tecnología y el Proceso Unificado la guía
detallada para el desarrollo de software minimizando los riesgos.
El Proceso Unificado ha adoptado un enfoque que se caracteriza por:

Interacción con el usuario continua desde un inicio

Mitigación de riesgos antes de que ocurran

Liberaciones frecuentes

Aseguramiento de la calidad

Involucramiento del equipo en todas las decisiones del proyecto

Anticiparse al cambio de requerimientos
Instituto Tecnológico de Ciudad.Juárez
68
Fundamentos de Desarrollo de Sistemas Unidad IV
El Proceso Unificado y MSF se enfocan en la arquitectura como el centro del desarrollo
para asegurar que el desarrollo basado en componentes sea clave para un alto nivel de reuso.
MSF considera que hay cuatro perspectivas de arquitectura que cumplen los
requerimientos de una empresa:

Arquitectura de Negocios - Describe como opera un negocio. Desarrolla una imagen
clara de los procesos de flujo de trabajo de la organización y de cómo son apoyados por
una infraestructura tecnológica basada en servicios.

Arquitectura de Aplicación – Adopta un modelo de aplicación de toda la empresa
para diseñar y desarrollar sistemas de negocios que puedan compartir un conjunto de
componentes back-end de alto valor.

Arquitectura de Información – Define qué información es necesaria para apoyar el
proceso de negocios y como poner esa información eficientemente en manos de quienes
que la necesitan sin crear islas de datos inaccesibles ni sistemas redundantes.

Arquitectura Tecnológica – Define los estándares y guías para la adquisición y
despliegue de herramientas, bloques de construcción de aplicaciones, servicios de
infraestructura, componentes de conectividad de red y plataformas cliente servidor.
El Modelo de Equipo de MSF muestra como estructurar equipos de alto desempeño para
crear soluciones más rápido, mejor y más baratas. El Modelo de Equipo de MSF se basa en las
formas de organizar equipos para crear los propios productos de Microsoft. Hace énfasis en las
comunicaciones claras y en un equipo de iguales con papeles y responsabilidades claras en todo
el proyecto. La calidad del producto se asegura por cada miembro del equipo. El Proceso
Unificado proporciona más detalle y guía para algunos de los roles en el proyecto.
Una vista arquitectónica es "una descripción simplificada (una abstracción) de un
sistema desde una perspectiva particular o punto de vista, que cubre particularidades y omite
entidades que no son relevantes a esta perspectiva".
Instituto Tecnológico de Ciudad.Juárez
69
Fundamentos de Desarrollo de Sistemas Unidad IV
Las características primordiales del Proceso Unificado son:

Iterativo e incremental

Centrado en la arquitectura

Guiado por casos de uso

Confrontación de riesgos
El Proceso Unificado es un proceso porque "define quién está haciendo qué, cuándo lo
hacer y cómo alcanzar cierto objetivo, en este caso el desarrollo de software". Según los
conceptos clave del Proceso Unificado son:
Fase e iteraciones
¿Cuándo se hace?
Flujos de trabajo de procesos (actividades y pasos)
¿Qué se está haciendo?
Artefactos (modelos, reportes, documentos)
¿Qué se produjo?
Trabajador: un arquitecto
¿Quién lo hace?)
El ciclo de vida del software en el Proceso Unificado
Las fases del ciclo de vida del software son: concepción, elaboración, construcción
y transición. La concepción es definir el alcance del proyecto y definir el caso de uso. La
elaboración es proyectar un plan, definir las características y cimentar la arquitectura. La
construcción es crear el producto y la transición es transferir el producto a sus usuarios.
Diagrama ilustrando como el énfasis relativo en las distintas disciplinas cambia a lo largo del proyecto
Figura 1. Estructura del Proceso Unificado
Instituto Tecnológico de Ciudad.Juárez
70
Fundamentos de Desarrollo de Sistemas Unidad IV
Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan
a las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño,
Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las
disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto.
El diseño de software se realiza a tres niveles: conceptual, lógico y físico.
Figura 2. Arquitectura lógica de tres capas de una aplicación cliente/servidor
Características
Iterativo e Incremental
El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de
cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas
fases es a su vez dividida en una serie de iteraciones (la de inicio sólo consta de varias iteraciones
en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto
desarrollado que añade o mejora las funcionalidades del sistema en desarrollo.
Dirigido por los Casos de Uso
En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos
funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración tome
un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas
disciplinas: diseño, implementación, prueba, etc. el proceso dirigido por casos de uso es el RUP.
Instituto Tecnológico de Ciudad.Juárez
71
Fundamentos de Desarrollo de Sistemas Unidad IV
Centrado en la Arquitectura
El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos
del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura
software de un sistema. La analogía con la construcción es clara, cuando construyes un edificio
existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanería,
etc.
Enfocado en los Riesgos
El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los
riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en
especial los de la fase de Elaboración, deben ser seleccionados en un orden que asegure que los
riesgos principales son considerados primero.
4.5 PROCESO DE SOFTWARE PERSONAL.
Cada ingeniero es diferente; para ser más eficiente, debe planificar su trabajo basándose
en datos tomados de su propia trayectoria profesional. Para mejorar auténticamente su trabajo,
los ingenieros deben usar procesos personales bien definidos y cuantificados.
Para obtener productos de calidad, el ingeniero debe asumir la responsabilidad personal
de la calidad de sus productos. Los buenos productos no se obtienen por azar, sino como
sonsecuencia de un esfuerzo positivo para hacer un trabajo de calidad.
El Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un
modelo de evaluación de los procesos de una organización. Fue desarrollado inicialmente para
los procesos relativos al software por la Universidad Carnegie-Mellon para el SEI (Software
Engineering Institute). El SEI es un centro de investigación y desarrollo patrocinado por el
Instituto Tecnológico de Ciudad.Juárez
72
Fundamentos de Desarrollo de Sistemas Unidad IV
Departamento de Defensa de los Estados Unidos de América y gestionado por la Universidad
Carnegie-Mellon. "CMM" es una marca registrada del SEI.
El Proceso Personal de Software es una versión pequeña de CMM donde se preocupa solo
por un conjunto de las KPAs (Key Process Areas). Fue propuesto por Watts Humphrey en
1995 y estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del libro "An
introduction to the Personal Software Process" se dirige ahora a ingenieros principiantes.
El PSP se caracteriza porque es de uso personal y se aplica a programas pequeños de
menos de 10.000 líneas de código. Se centra en la administración del tiempo y en la
administración de la calidad a través de la eliminación temprana de defectos. En el PSP se
excluyen los siguientes temas: Trabajo en equipo, Administración de configuraciones y
Administración de requerimientos.
KPAs (Key Process Area).
Es el conjunto de actividades relacionadas tales que cuando se llevan a cabo, se logran un
conjunto de objetivos. Estos objetivos son considerados importantes para mejorar la capacidad
del proceso.
Para cada Area Clave (Key Process Area) está presentada en el modelo de acuerdo a
Características Comunes (Common Features), referidas a su institucionalización:
 Compromiso en realizar
 Capacidad de realizar
 Actividades realizadas
 Medición y análisis
 Verificación de implementación
Instituto Tecnológico de Ciudad.Juárez
73
Fundamentos de Desarrollo de Sistemas Unidad IV
Estructura del Modelo CMM
Niveles de Madurez
indican
contiene
Capacidad del proceso
Areas Clave del Proceso
logra
organizada por
Características Comunes
Objetivos
refiere a
Implementación o
Institucionalización
Prácticas Clave
describe
Infraestructura o actividades
El PSP se orienta en el conjunto de áreas clave del proceso que debe manejar un
desarrollador cuando trabaja de forma individual. Los siguientes son los niveles y las KPAs
(Key Process Areas) que se manejan en cada uno:

Nivel 1 - Inicial:
o

Nivel 2- Repetible:
o
o
o
o
o
o

Ninguno
Gestión de Requerimientos
 Establecer y mantener un acuerdo con el cliente respecto a los requerimientos para el
software
Planificación de Proyecto de Software
 Establecer planes razonables para la construcción del software y para gestionar el proyecto
de software
Seguimiento y Supervisión de proyectos de Sw
 Ofrecer adecuada visibilidad
Gestión de Subcontratos de Sw
 Elegir subcontratistas de software calificados y gestionarlos de forma adecuada
Aseguramiento de la calidad del Sw
 Proporcionar a la dirección una visibilidad apropiada sobre el proceso utilizado por el
proyecto y los productos construidos
Gestión de la Configuración del Sw
 Establecer y mantener la integridad de los productos del proyecto de software a lo largo de
su ciclo de vida; es una parte integral de la mayoría de los procesos de ingeniería y de
gestión
Nivel 3- Definido:
o
o
o
Foco en el proceso de la organización
Definición del proceso de la organización
Plan de entrenamiento
Instituto Tecnológico de Ciudad.Juárez
74
Fundamentos de Desarrollo de Sistemas Unidad IV
o
o
o
o
Gestión integrada del software
 Utilizar el proceso definido adecuado para cada proyecto y gestionarlo en base a este
Ingeniería del producto de software
 Las tareas están definidas, integradas y se cumplen de forma consistente, y los productos
intermedios se mantienen consistentes
Coordinación entre grupos
 Con otras áreas del proyecto (sistema)
Revisión por pares


Nivel 4- Gestionado:
o
o

Detección temprana de defectos
Gestión de la calidad del sofware
 Definir objetivos de calidad, establecer planes para alcanzar los objetivos, control y ajuste
de los planes, productos y actividades
Gestión cuantitativa del proceso
 Histogramas, listas de comprobación, gráficas
Nivel 5– Optimizante:
o
o
o
Gestión del cambio del proceso
Gestión del cambio de la tecnología
Prevención de defectos
El PSP tiene varias fases:





PSP0: Proceso Base.
PSP0.1: Complementos al proceso base.
PSP1 y PSP1.1: Planeación personal.
PSP2 y PSP2.1: Control de calidad personal.
PSP3: Programas más grandes.
Principios de PSP
El diseño de PSP se basa en los siguientes principios de planeación y de calidad.

Cada ingeniero es esencialmente diferente; para ser más precisos, los ingenieros deben
planear su trabajo y basar sus planes en sus propios datos personales.

Para mejorar constantemente su funcionamiento, los ingenieros deben utilizar
personalmente procesos bien definidos y medidos.

Para desarrollar productos de calidad, los ingenieros deben sentirse personalmente
comprometidos con la calidad de sus productos.

Cuesta menos encontrar y arreglar errores en la etapa inicial del proyecto que encontrarlos
en las etapas subsecuentes.

Es más eficiente prevenir defectos que encontrarlos y arreglarlos.

La manera correcta de hacer las cosas es siempre la manera más rápida y más barata de
hacer un trabajo.
Instituto Tecnológico de Ciudad.Juárez
75