Ilovepdf Merged

Traducido del inglés al español - www.onlinedoctranslator.
com
Pittsburgh, Pensilvania 15213-3890
Proceso de software personalSM

para ingenieros: parte II
Diseño de software II
Este material está aprobado para su publicación pública. La distribución está limitada por el
Instituto de Ingeniería de Software a los asistentes.
Patrocinado por el Departamento de Defensa de EE. UU. ©

2006 por la Universidad Carnegie Mellon
octubre de 2006 PSP II - Diseño de software II - 1

Temas de conferencias
El proceso de diseño
UML y la PSP
Diseño de máquinas de estados.
Verificando máquinas de estados
© 2006 Universidad Carnegie Mellon octubre de 2006 PSP II - Diseño de software II - 2

El proceso de diseño
El diseño de software es el proceso creativo de producir una
solución precisa y eficaz a un problema mal definido.
El proceso de diseño no puede ser

• reducido a un procedimiento de rutina
• automatizado
• controlado o previsto con precisión
El proceso de diseño se puede estructurar para

• separar la rutina de las actividades creativas
• garantizar que el trabajo de diseño se realice correctamente
• identificar herramientas y métodos de diseño eficaces

Diseño como inversión
Los programadores experimentados no necesitan producir diseños para
escribir la mayoría de los programas pequeños.
Los diseños son necesarios cuando se van a utilizar programas pequeños como
parte de sistemas más grandes o cuando la calidad es crítica.
Según datos de 8.100 programas de PSP, los programadores

que produjeron diseños
• pasaron un 53% más de tiempo que aquellos que no lo hicieron
• escribí programas que eran un 46% más pequeños
La mayoría de los programadores saben escribir programas

pequeños. La habilidad crítica es para desarrollar grandes programas.

Los programas diseñados son más pequeños
300.00
250.00
Tamaño del programa - LOC
200.00
150.00
100.00
50.00
0.00
1 2 3 4 5 6 7 8 9 10
8.100 programas Número de programa
Tiempo de diseño < 25% Tiempo de código Tiempo de diseño >=100% Tiempo de código
© 2006 Carne Universidad Gie Mellon octubre de 2006 PSP II - Diseño de software II - 5
El diseño lleva más tiempo
15.00
Tiempo de desarrollo: horas
10.00
5.00
0.00
1 2 3 4 5 6 7 8 9 10
Número de programa
8.100 programas
Tiempo de diseño < 25% Tiempo de código Tiempo de diseño >=100% Tiempo de código
© 2006 Carne Universidad Gie Mellon octubre de 2006 PSP II - Diseño de software II - 6
UML y la PSP -1
El Lenguaje Unificado de Modelado (UML) proporciona una notación gráfica
para describir el comportamiento del sistema de software.
UML se basa en notaciones desarrolladas por

Booch, Rumbaugh y Jacobson.
La estandarización por parte del Object Management Group (OMG) ha

llevado a la aceptación generalizada de UML.
Dado que UML tiene muchos formatos y métodos, los usuarios normalmente trabajan
con subconjuntos (pequeños) de UML.

UML y la PSP -2
UML y las plantillas de PSP son complementarias.
• UML cubre la construcción lógica y física de un sistema
de software.
• Las plantillas de PSP se centran en descripciones precisas de las
interfaces y del comportamiento del sistema y de los componentes.
Se está desarrollando OCL (Object Constraint Language) para

complementar UML con un lenguaje preciso para describir el
comportamiento. Aún no se utiliza mucho.

Mapeo de vistas UML y PSP
Dinámica Estático
Casos de uso y
Externo secuencia Diagramas de clases
diagramas
diagrama de estado
clase y
Interno método
diagramas
especificaciones
© 2006 CarneUniversidad Gie Mellon octubre de 2006 PSP II - Diseño de software II - 9

D S
mi
I
Casos de uso
Los diagramas de casos de uso vinculan a los actores (agentes externos) con los casos
de uso.
Cada caso de uso describe una unidad de funcionalidad y

está documentado en texto. (UML no define un formato).
Un caso de uso describe secuencias de interacciones normales

y anormales entre los actores y el sistema.
La descripción de un caso de uso es una perspectiva externa, en la que el

sistema se ve como una "caja negra".
Los diagramas de actividad UML también pueden describir detalles de uso.

D S
mi
I
Use el diagrama del caso
Media y desviación estándar

Alumno

D S
mi
I
Ejemplo de descripción de caso de uso
Nombre del caso de uso:Media y desviación estándar
Meta:Calcula la media y la desviación estándar de un conjunto de números. Actor:
Estudiante de PSP
Condición previa:El conjunto de números se almacena en un archivo de texto.
Condición final exitosa:Se han impreso la media y la desviación estándar.

Condición final de fallo:Se ha impreso un mensaje de error. Escenario principal:
1. El estudiante ejecuta el programa.

2. El programa solicita el nombre del archivo que contiene los números.
3. El estudiante ingresa el nombre del archivo.
4. El programa imprime la media y la desviación estándar de los números del

archivo.
Escenario alternativo 1:
4. El programa emite un mensaje de error para un archivo inaccesible.
Escenario alternativo 2:
4. El programa emite un mensaje de error por datos no válidos en el archivo.

D S
mi
I
Diagramas de secuencia
Los diagramas de secuencia asignan las acciones del caso de

uso a la secuencia de mensajes entre objetos y actores.
Los diagramas de secuencia también especifican las interacciones

dinámicas entre objetos dentro de un sistema.
Los diagramas de secuencia describen el orden temporal de las

interacciones.
UML también proporciona diagramas de colaboración que describen

las interconexiones estructurales entre objetos.

D S
mi
I
Ejemplo de diagrama de secuencia
msd: : datos: archivo de datos

: Alumno
Media y DE
invocar( )
inmediato
Nombre del archivo( )

abierto( )
leer( )
calcular()
resultados
© 200 Universidad
6 Arkansasmi C n gie Mellon octubre de 2006 PSP II - Diseño de software II - 14
D S
mi
I
Diagramas de clases
Los diagramas de clases UML describen las relaciones

estáticas entre un sistema y sus clases, incluidas las
asociaciones y la herencia.
Los diagramas de clases UML también especifican los métodos y

atributos de la clase y las interfaces externas de la clase.

D S
mi
I
Ejemplo de diagrama de clases
Media y DE Lista
invocar() crear()
Nombre del archivo() agregarElemento()
calcular() iterar()
Archivo de datos
abierto()
leer()
© 2006 CarnUniversidad Egie Mellon octubre de 2006 PSP II - Diseño de software II - 16

D S
mi
I
Diagramas de diagrama de estado
El diagrama de estado UML describe todos los estados que

puede tener un objeto y los eventos que causan transiciones
de estado.
Un diagrama de estado identifica

• los estados asociados con un objeto
• sus transiciones (cómo un objeto cambia de estado)
• sus actividades (lo que hace un objeto en un estado)

D S
mi
I
Ejemplo de diagrama de estado
Conjunto vacio
Primero y único
primero de varios
mediodevarios últimodevarios
© 2006 C. arneUniversidad Gie Mellon octubre de 2006 PSP II - Diseño de software II - 18

Diseño de alto nivel usando UML
Requisitos del programa:

lo que el usuario necesita
(Resumen) Diagramas de clases
Casos de uso
Especificaciones del programa:

cual es el programa
hace
diagramas de estados
Diseño de alto nivel:

cómo el programa
obras
Requisitos del módulo:

lo que necesita el programa

Diseño a nivel de detalle utilizando UML
Requisitos del módulo:

lo que necesita el programa
Diagramas de clases
Especificaciones del módulo:

cual es el modulo
hace
Especificación lógica
diagramas de estados
Diseño detallado:
cómo el módulo
obras
Módulo
código fuente

UML y las plantillas de PSP -1
Los diagramas de secuencia y casos de uso de UML proporcionan la
misma información que la plantilla de especificaciones operativas
de PSP.
Los diagramas de secuencia y clases UML proporcionan información

sobre relaciones e interacciones que no se captura en las plantillas de
PSP.
Los diagramas de clases UML registran la firma del método, pero la

especificación de comportamiento debe documentarse con la
especificación funcional de PSP.

UML y las plantillas de PSP -2
La plantilla de especificación lógica de PSP no tiene equivalente UML, por
lo que debe usarse para registrar la lógica del programa.
El diagrama de estados y el diagrama de estados son equivalentes.
UML no tiene un equivalente a la plantilla de especificación

estatal.
Al diseñar máquinas de estados con UML, registre el diseño terminado

en la plantilla de especificación de estados.

Máquinas de estados
Una máquina de estados tiene memoria y su comportamiento depende del

contenido de la memoria.
Todas las computadoras y muchos programas son máquinas de estados.
Cuando los programas del tamaño de un módulo contienen máquinas de estados,

los diseños de las máquinas de estados se pueden definir y verificar con precisión.
Sin los métodos adecuados, rara vez es posible comprender o

verificar incluso máquinas de estado de tamaño modesto.

Una máquina de estados de ejemplo
El programa de inicio de sesión de usuario es un ejemplo de máquina de estados.
El usuario tiene varias oportunidades para proporcionar una identificación y

contraseña correctas.
Cuando se proporciona una identificación y contraseña correctas, el usuario

inicia sesión.
Si hay demasiados errores de ID o contraseña, se finaliza la sesión de

inicio de sesión.

El diagrama de estado de "iniciar sesión"
Comenzar
/n:= 0; !Identificación válida;
!PW válida; Fallar := falso; obtener identificación
ID de verificación
(!PW válida -
!ID válida) - n < nMax / n := n + Tiempo de espera/fallo: = verdadero
1; obtener identificación
!ID válida / obtener contraseña
ID válida / obtener contraseña
ComprobarPW
(contraseña válida-
ID válida) / Fallo: = falso; n >= nMáx.-

Iniciar sesión usuario Tiempo de espera/fallo: = verdadero
Fin

Diseño de máquinas de estados
Los pasos para diseñar máquinas de estados son los siguientes.

• Define el problema.
• Diseñar una estrategia de solución.
• Definir las decisiones que debe tomar el programa.
• Identificar la información necesaria para tomar estas
decisiones.
• Determinar los estados requeridos para almacenar esta información.
• Especificar las transiciones entre los estados.

Estrategia de solución
La estrategia de solución describe el enfoque para resolver el

problema. Suele ser secuencial y a menudo gráfico.
Una estrategia de ejemplo para iniciar sesión es la siguiente.

• Verifique la identificación del usuario.
• Por motivos de seguridad, pregunte por las contraseñas si la identificación es

correcta o no.
• Si el ID y la contraseña son correctos, inicie sesión como usuario.
• Si la contraseña es incorrecta, solicite los ID y las contraseñas hasta que

ambas sean correctas o el usuario cometa demasiados errores.
• En todos los casos, si el usuario no responde a tiempo, se agota el tiempo de espera.

Decisiones a tomar
Para implementar esta estrategia, el programa debe tomar las
siguientes decisiones.
• ¿Solicito una identificación y contraseña?
• ¿Debo iniciar sesión como usuario?
• ¿Debo esperar al usuario?

• ¿Termino la sesión del usuario?

Información requerida -1
La información necesaria para tomar estas decisiones es la
siguiente.
¿Solicito una identificación?

• ¿Es este un usuario nuevo?
• ¿El usuario ha enviado una contraseña incorrecta?
• ¿Ha enviado el usuario demasiadas identificaciones o
contraseñas incorrectas?
¿Solicito una contraseña?

• ¿Ha enviado el usuario una identificación?

Información requerida -2
¿Debo iniciar sesión como usuario?
• ¿Fueron correctos el ID y la contraseña más recientes?
¿Debo esperar al usuario?

• ¿El usuario ha tardado demasiado en responder una solicitud?
¿Termino la sesión del usuario?

• ¿Se ha agotado el tiempo de espera del usuario?
• ¿El usuario ha cometido demasiados errores de identificación o contraseña?

Información del sistema versus información del estado
Parte de la información da como resultado la misma acción

independientemente del estado, y otra información provoca acciones que
dependen del estado.
Ejemplos son
• Tiempo de espera: independientemente del estado, la sesión finalizó
• n > nMax – independientemente del estado, sesión terminada
En estos casos, el sistema toma medidas idénticas

independientemente del estado.

Condiciones de acción
Para determinar el número de estados requeridos, considere las siguientes
preguntas y las acciones resultantes.
1. ¿Se trata de un usuario nuevo o de uno con una contraseña no válida?

• Sí: obtenga una identificación
• No – pase a la pregunta 2
2. ¿El usuario ha enviado una identificación o una contraseña?

• ID – obtener contraseña
• Contraseña – vaya a la pregunta 3
• Ninguno: finalizar la sesión
3. ¿Son correctos el ID y la contraseña?

• Sí: inicie sesión como usuario y salga
• No – vaya a la pregunta 1
En todos los casos, verifique si n > nMax o tiempo de espera.

Estados requeridos
Para nuestra máquina de estados de ejemplo, se necesitan cuatro estados.

• Estado de inicio o nuevo usuario
• Verificar ID
• Comprobar contraseña
• Fin

Plantilla de especificación estatal
Los siguientes pasos del diseño de la máquina de estados son especificar la
• transiciones entre los estados
• acciones tomadas con cada transición
PSP utiliza la plantilla de especificación de estado (SST) para definir

estados, transiciones y acciones de la máquina de estados.
Con el SST, puedes

• definir la estructura de la máquina de estados
• analizar el diseño de la máquina de estados
• reconocer errores y omisiones

Ejemplo de plantilla de estado
Alumno J. Desarrollador Fecha 27/10
Programa Acceso Programa #
Instructor humphrey Idioma C++
Nombre del Estado Descripción

Comenzar Condición de inicio para el sistema.
ID de verificación El estado del sistema después de que se solicita una ID de usuario. El

ComprobarPW estado del sistema después de que se solicita una contraseña de usuario. El
Fin estado final: Iniciar sesión inicia sesión o cierra la sesión del usuario.
Función/Parámetro Descripción
IDENTIFICACIÓN Identificación de usuario: ID es válido o !Válido
VP Contraseña de usuario: PW es válida o !válida
norte Recuento entero de errores de ID y contraseña
nmáx. Valor máximo de errores de ID y contraseña: n >= nMax se rechaza. Indicador de recuento
Fallar de errores o error de tiempo de espera: Fail = true es un error, Fail = false está bien.
Estados/Próximos Estados Condición de transición Acción
Comenzar
Comenzar Sin transiciones de Inicio a Inicio

ID de verificación Verdadero Obtener identificación, n := 0; ID y contraseña !Válido
ComprobarPW Sin transiciones de Inicio a CheckPW

Fin Sin transiciones de Inicio a Fin
ID de verificación
Comenzar Sin transiciones de CheckID a Inicio Sin

ID de verificación transiciones de CheckID a CheckID ID
ComprobarPW válida Obtener la contraseña
ComprobarPW !Identificación válida Obtener la contraseña
Fin Se acabó el tiempo Fallo := verdadero
ComprobarPW
Comenzar No hay transiciones de CheckPW a Start

ID de verificación (!PW válida - !ID válida) - n < nMax - !Tiempo Obtener ID, n := n + 1; ID y contraseña !
de espera Válido
ComprobarPW Sin transiciones de CheckPW a

CheckPW
Fin PW válida - ID válida - !Timeout n Fallo: = falso, inicia sesión como usuario
Fin >= nMax - Timeout Fallo: = verdadero, corta al usuario
Fin
No hay transiciones desde el final a ningún estado

Condiciones de transición
La mayoría de las condiciones de transición son simples.
La transición de CheckID a CheckPW se produce después de obtener una

identificación. Sucede ya sea que la identificación sea correcta o incorrecta.
La transición CheckID to End ocurre cuando hay un tiempo de

espera, configurando Fail := true.

Verificación de máquinas de estados
Especifique todas las máquinas de estado en sus programas.

• Los triviales deberían ser triviales de definir.
• Las máquinas de estados aparentemente simples a menudo no lo son.
• Sin especificaciones precisas, las máquinas de estados complejas
casi siempre son defectuosas.
Verifique que esté completo y sea consistente.

• El conjunto de condiciones de transición de cualquier estado
dado debe ser completo y ortogonal.
• Se deben definir las acciones en cada transición.

Una máquina de estados adecuada
En una máquina de estados adecuada, las transiciones de estados son

todas completas y ortogonales.
• Transiciones Completas: se define una transición para cada
situación posible.
• Transiciones ortogonales: ninguna de las transiciones tiene
condiciones de superposición.
Con una máquina de estados adecuada

• se define un siguiente estado para cada condición posible
• el siguiente estado designado es único

Verificación de máquina de estados
Los pasos de verificación de la máquina de estados son los siguientes.

• Verifique para asegurarse de que la máquina de estado no tenga trampas o
bucles ocultos.
• Comprobar que el conjunto de todas las transiciones de cada
estado sea completo y ortogonal.
Además de verificar la corrección de la máquina de estado, también

asegúrese de que el programa realice las funciones previstas.

Trampas o bucles ocultos -1
Compruebe si hay trampas y bucles ocultos
• construir la plantilla de estado
• construir un diagrama de máquina de estados
• determinar si algún estado de salida es inalcanzable desde algún
otro estado
Si algún estado no puede alcanzar un estado de salida, esta no es una

máquina de estados adecuada.
Si la máquina de estados no tiene un estado de salida, asegúrese de

que no contenga bucles sin fin.

Trampas o bucles ocultos -2
Por ejemplo, considere elAcceso máquina estatal.
• Hay cuatro estados: Inicio, CheckID, CheckPW y End.
• Existe un camino directo o indirecto desde cada estado hasta el

Fin.
Un posible bucle es entre CheckID y CheckPW.
Dado que n aumenta en uno por cada ciclo, n finalmente

excederá nMax y provocará que finalice la transición.
Por lo tanto, esta máquina de estados no tiene trampas ni bucles

ocultos.

Transiciones de estado -1
Para Iniciar sesión, la transición de Inicio es siempre a CheckID.
Desde CheckID, las transiciones son completas y ortogonales sin

superposiciones. Las condiciones de transición son
• Inicio: imposible
• Identificación válida: para CheckPW
• !ID válida: para comprobarPW

• Tiempo de espera: para finalizar

Desde CheckPW, las transiciones son las siguientes.

• Inicio: imposible
• CheckID: !ID válida o !PW válida
• Fin: contraseña válida e identificación válida
• Fin: n >= nMax o Timeout
Verificar la integridad y ortogonalidad de estas

condiciones requiere análisis.
Una tabla de verdad es una forma útil de realizar dichos análisis.

Las transiciones de CheckPW son las siguientes.
norte < nMáx. = nMáx > nMáx

VP Válido !Válido Válido !Válido Válido !Válido
IDENTIFICACIÓN Válido !Válido Válido !Válido Válido !Válido Válido !Válido Válido !Válido Válido !Válido
Estado siguiente para cada condición de transición definida A

ID de verificación ID de verificación ID de verificación
B Fin Fin Fin

C Fin Fin Fin Fin Fin Fin Fin Fin
Valores de falla resultantes para cada condición de transición definida A
B F F F
C t t t t t t t t
Las condiciones A, B y C son las siguientes.

R: (!ValidID - !ValidPW) - n < nMax - !Tiempo de espera→ID de verificación / n := n + 1
B: ID válida - PW válida -! Tiempo de espera→Finalizar/Fallar: = falso y usuario de inicio de sesión
C: n >= nMax - Tiempo de espera→Finalizar/Fallar: = verdadero y cortar al usuario
© 2006 Universidad de Carnegie mellon octubre de 2006 PSP II - Diseño de software II - 44

La transición Fin tiene dos casos indeterminados.

• n = nMax y PW válida e ID válida
• n > nMax y PW válida e ID válidas
Estos casos son posibles dependiendo de la

implementación y deben evitarse.
Esto se puede hacer cambiando la ecuación C.
C: Tiempo de espera - (n >= nMax - (!ValidID -!ValidPW))→Fin /
Fallo: = verdadero y corta al usuario

Plantilla de estado de inicio de sesión corregida
Alumno J. Desarrollador Fecha 27/10

Programa Acceso Programa #
Instructor humphrey Idioma C++

Comenzar Condición de inicio para el sistema.
ID de verificación El estado del sistema después de que se solicita una ID de usuario. El

ComprobarPW estado del sistema después de que se solicita una contraseña de usuario. El
Fin estado final: Iniciar sesión inicia sesión o cierra la sesión del usuario.
Función/Parámetro Descripción
IDENTIFICACIÓN Identificación de usuario: ID es válida o! Válida
VP Contraseña de usuario: PW es válido o !Válido
norte Recuento entero de errores de ID y contraseña
nmáx. Valor máximo de errores de ID y contraseña: n >= nMax se rechaza. Indicador de
Fallar recuento de errores o error de tiempo de espera: Fail = true es un error, Fail = false está bien.
Comenzar
Comenzar Sin transiciones de Inicio a Inicio

ID de verificación Verdadero Obtener identificación, n := 0; ID y contraseña !Válido
ComprobarPW Sin transiciones de Inicio a CheckPW

Fin Sin transiciones de Inicio a Fin
ID de verificación
Comenzar Sin transiciones de CheckID a Inicio Sin

ID de verificación transiciones de CheckID a CheckID ID
ComprobarPW válida Obtener la contraseña
ComprobarPW !Identificación válida Obtener la contraseña
Fin Se acabó el tiempo Fallo := verdadero
ComprobarPW
Comenzar No hay transiciones de CheckPW a Start

ID de verificación (!PW válida - !ID válida) - n < nMax - !Tiempo de Obtener ID, n := n + 1; ID y contraseña !Válido
espera
ComprobarPW Sin transiciones de CheckPW a
CheckPW
Fin PW válida - ID válida - !Tiempo de espera Fallo: = falso, inicia sesión como usuario
Fin Tiempo de espera - (n >= nMax - (!PW válida - ! Fallo: = verdadero, corta al usuario
ID válida))
Fin
No hay transiciones desde el final a ningún estado

Ejercicio de verificación
Utilizando los métodos que acabamos de comentar, verifique el diseño de la
máquina de estados del cronómetro en la plantilla de estado en elrepartir .
Vuelva a emparejarse y tómese 20 minutos para verificar la exactitud de

la plantilla de estado para la máquina de estado del cronómetro.
20 minutos

Ejercicio: Diagrama de Estado
reiniciar
Cero En espera
iniciar/detener sostener
reiniciar sostener
Correr
reiniciar iniciar/detener
iniciar/detener iniciar/detener
Interrumpido

Comentarios del ejercicio
Este diseño de máquina de estados de cronómetro está incompleto.
La SST no especifica qué sucede cuando presionas

• mantener en cero
• restablecer en cero
• mantener cuando esté parado
Además, ¿son posibles las transiciones de Cero a En

espera o Parado, o de Parado a En espera?
Cuando estas transiciones y acciones estén definidas adecuadamente, la

máquina de estados también lo estará.

Plantilla de estado corregida
Cero Condición de inicio del sistema Cronómetro en
Correr funcionamiento y en pantalla Cronómetro en
En espera funcionamiento con pantalla en espera
Interrumpido Cronómetro detenido
Cero
Cero restablecer - mantener Detener el reloj, restablecer el reloj, borrar la
Correr iniciar/detener pantalla Iniciar reloj, mostrar reloj

Correr
Cero reiniciar Detener el reloj, restablecer el reloj, borrar la pantalla
En espera sostener Mantener la pantalla
Interrumpido iniciar/detener Detener el reloj, mantener la pantalla
En espera
Cero reiniciar Detener el reloj, restablecer el reloj, borrar la
Correr sostener pantalla Iniciar el reloj, mostrar el reloj
Interrumpido iniciar/detener Detener el reloj, mantener la pantalla
Interrumpido
Cero reiniciar Detener el reloj, restablecer el reloj, borrar la

Correr iniciar/detener pantalla Iniciar el reloj, mostrar el reloj
Interrumpido sostener Detener el reloj, mantener la pantalla

Mensajes para recordar
Una notación de diseño precisa le ayuda a producir diseños
claros y correctos.
UML proporciona información de diseño que no se encuentra en las plantillas

de PSP y las plantillas tienen información de diseño que no se muestra con los
métodos UML actuales.
Dado que las máquinas de estados son complejas, sus

implementaciones a menudo contienen errores.
Identifique las máquinas de estado en sus programas y utilice la plantilla de

estado para diseñarlas y verificarlas.
Los defectos de la máquina de estados son extremadamente difíciles de encontrar y corregir en las
pruebas.

Traducido del inglés al español - www.onlinedoctranslator.com

Verificación de diseño

octubre de 2006 PSP II - Verificación de diseño - 1

Esta conferencia proporciona un estudio de varios temas de

verificación de diseño.
• razones para la verificación del diseño
• métodos de verificación del diseño
- ejecución simbólica
- tablas de ejecución
- tablas de seguimiento y verificación de casos
- verificación de corrección
Se requiere práctica para utilizar de manera consistente y efectiva

estas técnicas de verificación.
© 2006 por la Universidad Carnegie Mellon octubre de 2006 PSP II - Verificación del diseño - 2
Necesidad de verificación del diseño -1
Es difícil eliminar muchos defectos de diseño simplemente realizando

cambios en el proceso.
Las listas de verificación y un proceso de revisión estructurado pueden mejorar el rendimiento
de la revisión del código.
Las revisiones de diseño con listas de verificación también son útiles, pero no
suficientes.
Un elemento de la lista de verificación,“¿Es correcta la lógica del módulo?no se

puede confirmar escaneando las plantillas de especificaciones.
Necesidad de verificación del diseño -2
Para mejorar el rendimiento de la revisión del diseño, debe utilizar métodos de

verificación disciplinados.
Un enfoque ordenado para la verificación del diseño es esencial

porque
• muchos defectos de diseño comunes son causados por
condiciones pasadas por alto
• situaciones que parecen improbables se vuelven más probables con
sistemas complejos y computadoras de alta potencia
• condiciones que inicialmente eran imposibles pueden volverse probables después
de que se modifica un programa
Beneficios de la verificación del diseño
Si sigue un procedimiento estructurado de verificación del diseño,

es más probable que
• ver condiciones pasadas por alto
• identificar riesgos rara vez expuestos
• reconocer posibles exposiciones futuras
Al registrar información durante cada revisión de diseño, puede

mejorar la eficacia de inspecciones de diseño posteriores.
Uso de la verificación de diseño
Se deben utilizar métodos de verificación del diseño durante

• diseño
• revisiones de diseño
• inspecciones de diseño
Verificar diseños con código fuente requiere mucho tiempo y es propenso a

errores.
Utilice métodos de verificación de diseño para centrarse en los tipos

de defectos que le causan más problemas en la prueba.
Utilice sus datos para decidir qué métodos de verificación son más
efectivos para usted.
Ejecución simbólica -1
Con ejecución simbólica
• el programa se representa simbólicamente
• el comportamiento del programa se examina analíticamente
Aunque no siempre es práctica, la ejecución simbólica

puede producir una verificación integral.
El enfoque es
• asignar símbolos algebraicos a las variables del programa
• reformular el programa como una o más ecuaciones usando
estos símbolos
• analizar el comportamiento de las ecuaciones
Ejecución simbólica -2
Algunas preguntas para hacer son
• ¿El programa converge en un resultado?
• ¿El programa se comporta correctamente con valores de entrada
tanto normales como anormales?
• ¿El programa siempre produce los resultados deseados?
Ejemplo de ejecución simbólica -1
Examine el siguiente segmento del programa.
comenzar
X := X + Y;
Y := X – Y;
X := X – Y;
fin
¿Cuál sería el resultado para varios valores de X e Y?
Nota: Este sencillo ejemplo simplemente ilustra cómo la ejecución

simbólica puede revelar una funcionalidad no obvia.
Ejemplo de ejecución simbólica -2
Los pasos del programa para este ejemplo son los siguientes.
# Instrucción X Y
Valores iniciales A B
1 X := X + Y A+B
2 Y := X - Y A
3 X := X - Y B
Valores finales B A
El resultado para las entradas A y B es B y A.
© 2006b y Universidad
a Crnegie Mellon octubre de 2006 PSP II - Verificación de diseño - 10
Ejecución simbólica: evaluación
Ventajas: pruebas simbólicas
• puede ser general
• normalmente implican menos trabajo que otros métodos
• a veces son la única forma práctica de realizar
una verificación exhaustiva
Desventajas: ejecución simbólica

• es difícil de usar, excepto para problemas algorítmicos y de
sustitución
• las pruebas son manuales y propensas a errores
• es difícil de usar con lógica compleja
Tablas de Ejecución -1
Una tabla de ejecución es una forma ordenada de rastrear la ejecución de un
programa.
• Es una verificación manual del flujo del programa.
• Comienza con las condiciones iniciales.
• Se selecciona un conjunto de valores variables.
• Se examina cada paso de ejecución.
• Se ingresa cada cambio en los valores de las variables.
• El comportamiento del programa se compara con la especificación.
Tablas de Ejecución -2
Las ventajas de las mesas de ejecución son que
• son simples
• dar resultados confiables
Las desventajas de las tablas de ejecución son que

• comprobar sólo un caso a la vez
• consumen mucho tiempo
• están sujetos a errores humanos
Procedimiento de la tabla de ejecución
Para utilizar una tabla de ejecución

1. identificar las variables clave del programa e ingresarlas en la parte
superior de la tabla
2. ingrese los pasos principales del programa
3. determinar e ingresar las condiciones iniciales
4. rastrear los valores de las variables a través de cada paso del programa
5. utilice copias adicionales de la tabla de ejecución para cada bucle
cíclico
Ejercicio de tabla de ejecución
En estoejercicio , utilice una tabla de ejecución para
verificar la corrección del programa LogIn.
Verifique un escenario de dos ciclos:

1. ID válida y contraseña válida
2. Error de tiempo de espera de ID y contraseña válida.
Supongamos nMáx = 3.
Forme pareja y tómese 20 minutos para realizar la verificación. Las tablas

de ejecución en blanco están en el cuaderno.
20 minutos
Tabla de ejecución de inicio de sesión -1
Ciclo Función: Iniciar sesión

# Instrucción Prueba IDENTIFICACIÓN VP Fallar norte
1 Inicializar: n := 0; ID: = !Válido; Contraseña := !Válido; Fallo := falso. Repita el F !Válido !Válido F 0
2 ciclo principal hasta que obtenga una ID y contraseña válidas o falle.
3 Obtener identificación de usuario.
4 Si no hay respuesta de ID en MaxTime, establezca Fallo: = verdadero. Verifique la
5 validez del documento de identidad. {Verificar estado de ID}
6 Obtener la contraseña.
7 Si no hay respuesta de contraseña en MaxTime, establezca Fallo: =
8 verdadero. Si la identificación es válida, verifique la validez de la contraseña.
9 {CheckPW state} Si PW !Valid o ID !Valid, pasa el contador n.
10 Si n excede nMax, establezca Fallo: = verdadero.
11 Hasta que ID y PW sean válidos o fallidos = verdadero.

12 De lo contrario, repita el bucle principal.
13 Si falla = verdadero, corta al usuario; de lo contrario, inicia sesión como usuario. {Estado final}
© 2006 por C
la Universidad Arnegie Mellon octubre de 2006 PSP II - Verificación del diseño - 16
Discusión sobre la tabla de ejecución de inicio de sesión
El programa tiene un error.
Dado que el diseño no requiere que ID se establezca en !Valid en

un nuevo ciclo, la implementación podría generar un error.
En el segundo ciclo, una PW válida podría finalizar la prueba con ID =

Válido, PW = Válida y Falla = verdadero.
Dependiendo de la implementación, esta omisión en el diseño podría resultar

en un inicio de sesión incorrecto.
Ciclo 1: DNI válido; !PW válida Función: Iniciar sesión

1 Inicializar: n := 0; ID: = !Válido; Contraseña := !Válido; Fallo := falso. Repita el F !Válido !Válido F 0
2 ciclo principal hasta obtener una ID válida y una contraseña o falla.
4 Si no hay respuesta de ID en MaxTime, establezca Fallo: = verdadero. Verifique F

5 la validez del documento de identidad. {Verificar estado de ID} Válido
6 Obtener la contraseña
7 Si no hay respuesta de contraseña en MaxTime, establezca Fallo: = F

8 verdadero. Si la identificación es válida, verifique la validez de la contraseña. t
9 {CheckPW state} Si PW !Valid o ID !Valid, pasa el contador n. t 1
10 Si n excede nMax, establezca Fallo: = verdadero. F
11 Hasta que ID y PW sean válidos o fallidos = verdadero. F
12 De lo contrario, repita el bucle principal. t
13 Si falla = verdadero, corta al usuario; de lo contrario, inicia sesión como usuario. {Estado final}
© 2006 por C
Ciclo 2: Tiempo de espera de identificación; Contraseña válida Función: Iniciar sesión

1 Inicializar: n := 0; ID: = !Válido; Contraseña := !Válido; Fallo := falso. Repita el

2 ciclo principal hasta que obtenga una ID y contraseña válidas o falle. Válido !Válido F 1
4 Si no hay respuesta de ID en MaxTime, establezca Fallo: = verdadero. Verifique t t

5 la validez del documento de identidad. {Verificar estado de ID}
6 Obtener la contraseña
7 Si no hay respuesta de contraseña en MaxTime, establezca Fallo: = F

8 verdadero. Si la identificación es válida, verifique la validez de la contraseña. t Válido
9 {CheckPW state} Si PW !Valid o ID !Valid, pasa el contador n. F
10 Si n excede nMax, establezca Fallo: = verdadero. F
11 Hasta que ID y PW sean válidos o fallidos = verdadero. t
12 De lo contrario, repita el bucle principal.
13 Si falla = verdadero, corta al usuario; de lo contrario, inicia sesión como usuario. {Estado final} V/F
© 2006 por C
Comprobación de casos
La verificación de casos implica los siguientes cinco pasos. 1.

Examinar el programa para determinar sus categorías de
comportamiento.
2. Para estas categorías, identifique los casos a verificar.
3. Verifique los casos para asegurarse de que cubran todas las situaciones
posibles.
4. Examinar el comportamiento del programa para cada caso.
5. Una vez verificados todos los casos, se ha verificado el
comportamiento del programa.
Tablas de seguimiento
Las tablas de seguimiento son similares a las tablas de ejecución, pero más
generales.
Las tablas de seguimiento examinan el comportamiento general del programa,

en lugar de verificar casos individuales.
Uso de tablas de seguimiento
• ejecución simbólica
• verificación de casos
Procedimiento de tabla de seguimiento
El procedimiento de la tabla de seguimiento es el mismo que el de la

tabla de ejecución, más tres pasos.
1. Identifique las variables clave del programa e introdúzcalas en la
parte superior de la tabla.
2. Ingrese los pasos principales del programa.
3. Identificar posibilidades de ejecución simbólica.
4. Defina todos los casos posibles y seleccione aquellos a
verificar.
5. Determine e ingrese las condiciones iniciales.
6. Rastree los valores de las variables en cada paso del programa.
7. Utilice copias adicionales de la tabla de seguimiento para cada bucle cíclico.
8. Para bucles de varios ciclos, agrupe los pasos intermedios si
sus resultados son obvios.
Ejemplo de tabla de seguimiento
La rutina ClearSpaces borra los espacios iniciales y finales de una

cadena de entrada y establece el valor de estado.
Espacios claros Entrada vacía→ (devolver vacío) y Estado: = 0 o

(Entrada; Estado)
Entrada = 1 espacio→ (devolver vacío) y Estado: = 1 o
Entrada >= 2 espacios→ (devolver vacío) y Estado: = 2 o
La entrada tiene caracteres que no son espacios.→ (volver recortado

entrada) y Estado := 3
El siguiente ejemplo omite la prueba Longitud = 0 y borra los espacios

finales. Está en el libro de texto, Tabla 12.5 (página 264).
© 2006 por ca Universidad Renégie Mellon octubre de 2006 PSP II - Verificación del diseño - 23
Casos de tabla de seguimiento -1
Los parámetros de ejecución simbólica son los siguientes.

• longitud de la cadena: Longitud > 0
• espacios iniciales: L
• caracteres que no sean espacios: N
• espacios finales: T
Los casos posibles son

• L o N o T = 1 mientras que los demás = 0
• L o N o T > 1 mientras que los demás = 0
• L o N o T = 0 mientras que los demás > 0
•LyNyT>0
Casos de mesa de seguimiento -2
Una prueba exhaustiva comprobaría todos los casos.
También verificaría cualquier limitación en los valores límite

superiores de L, N y T.
Una estrategia común de tabla de seguimiento es elegir un conjunto

específico de valores para cada caso y luego generalizar el resultado.
El siguiente ejemplo de espacios finales muestra la

aproximación con L y N y T > 0.
Ejemplo de espacio final -1
Ciclo 1: L = 1, N = 2, T = 1 ClearSpaces(var Entrada: cadena; Estado: int)
# Instrucciones Condición Aporte Estado de longitud
Longitud: = longitud (entrada)

1 'AB' 4 0
Estado: = 0
2 repetir
3 si Entrada[Longitud] = ' '
4 Longitud := Longitud - 1
5 si Estado < 2 Estado:=Estado+1
6 más Estado: = 3
hasta Estado=3 o Longitud=0
Ejemplo de espacio final -2
Al utilizar una tabla de seguimiento, es esencial determinar con
precisión qué haría la computadora en cada paso.
En este ejemplo, el valor de Entrada[Longitud] es indeterminado

porque el último carácter de la cadena tiene una Longitud - 1.
Esto es un defecto.
Después de corregir este defecto, la tabla de seguimiento queda como se muestra en la
siguiente diapositiva.
Ejemplo de tabla de seguimiento: ciclo 1

1 'AB' 4 0
Estado: = 0
2 repetir
3 si Entrada[Longitud-1] = ' ' verdadero
4 Longitud := Longitud - 1 3
5 si Estado < 2 Estado:=Estado+1 verdadero 1
6 más Estado: = 3
7 hasta Estado=3 o Longitud=0 FALSO
Ejemplo de tabla de seguimiento: ciclo 2

1
Estado: = 0
2 repetir 'AB' 3 1
3 si Entrada[Longitud-1] = ' ' FALSO
6 más Estado: = 3 3
7 hasta Estado=3 o Longitud=0 verdadero
Discusión sobre la tabla de seguimiento
Primero, verifique cuidadosamente las condiciones iniciales para asegurarse de

que estén establecidas.por el programa.
En segundo lugar, vuelva a verificar la tabla de seguimiento para detectar errores
y omisiones.
Luego, después de completar cada caso, verifique el comportamiento de

diferentes valores de parámetros.
Por ejemplo, en la siguiente diapositiva se muestra el paso Estado := 3

para el caso de la tabla de seguimiento con T espacios finales.
Ejemplo de tabla de seguimiento: ciclo T
Ciclo T: L = 1, N = 2, T = T ClearSpaces(var Entrada: cadena; Estado: int)

1
Estado: = 0
2 repetir 'AB…' 3 2
3 si Entrada[Longitud-1] = ' ' FALSO
6 más Estado: = 3 3
7 hasta Estado=3 o Longitud=0 verdadero
Verificación de la corrección del programa
Los métodos de verificación de la corrección tratan los programas

como teoremas matemáticos.
Estos métodos son particularmente útiles durante el diseño y la

revisión del diseño.
Dado que la verificación de programas a menudo implica un razonamiento

sofisticado, es importante comprobar su trabajo cuidadosamente.
Verificación de corrección
Para verificar un programa
• identificar todos los casos del programa
• considere cada pregunta de verificación mientras revisa
cada constructo no trivial
• cuando la respuesta no sea obvia, utilice una tabla de seguimiento
para evaluar las condiciones que debe satisfacer el programa
Si bien este enfoque de verificación funciona con la mayoría de las construcciones de

diseño, en esta conferencia solo se describen los “bucles while”.
Las pruebas de bucles repetir hasta y for se describen en el libro

de texto (páginas 271 - 277).
Mientras verificación de bucle -1
Se supone que WhileLoop tiene la siguiente forma.
mientras mientras prueba
comenzar
Parte de bucle
fin
Mientras verificación de bucle -2
Un bucle while es correcto si todas las siguientes preguntas

pueden responderse con "sí".
• Pregunta 1: ¿Se garantiza la terminación del bucle para cualquier
argumento de WhileTest?
• Pregunta 2: Cuando WhileTest es verdadero, ¿WhileLoop =
LoopPart seguido de WhileLoop?
• Pregunta 3: Cuando WhileTest es falso,
¿WhileLoop = identidad?
Ejemplo de bucle while -1
Suponiendo n > 0, calcule n!
f=1
yo = 1
mientras yo != n {no soy igual a n}
comenzar
yo = yo + 1
f = f * yo
fin
Pregunta 1: ¿Se garantiza la terminación del bucle para cualquier
argumento de WhileTest?
Sí, el bucle termina cuandoyo = norte.Desdeipasos

dentro del bucle, terminará siempre quenorte > 0.
Pregunta 2: Cuando WhileTest es verdadero, ¿WhileLoop

= LoopPart sigue a WhileLoop?
Sí, los incrementos de LoopPartiy conjuntosFigual ajoder yo, entoncesF

sigue siendo igual a¡i!
Nota: Las condiciones iniciales aseguran quef = yo!inicialmente.
Pregunta 3: Cuando WhileTest es falso, ¿WhileLoop =
identidad?
Sí, cuando WhileTest es falso, el ciclo termina sin más

cambios en ninguna variable, por lo queyo = nortey f = yo!
Por lo tanto, podemos deducir quef = norte!según sea necesario.
Otro ejemplo de bucle While -1
dado un valorXy una matrizun[0 .. n-1]que está ordenado en orden
ascendente, verifique que el siguiente algoritmo de búsqueda
binaria encuentre el índice más pequeñoital queX≤ai].
yo = 0
j = norte
mientras yo != j
comenzar
k = (i + j) div 2
si a[k] < x
yo = k
demás
j=k
fin
Otro ejemplo de bucle while -2
La especificación informal está incompleta.
• ¿Qué debería pasar sinorte = 0(matriz vacía)?
• ¿Qué debería pasar six > a[n-1]?
Podemos formalizar la especificación como:
Condición previa
-s -{1 .. n-1} • a[s-1] ≤ a[s]
(la matriz está ordenada)
-k -{0 .. i-1} • x>a[k] -

Poscondición -k -{i .. n-1} • x ≤ a[k] - i ≥
(resultado de operación deseado) 0-
yo ≤ norte
Entonces
• six > a[n-1]entonces el resultado deseado esyo = norte

• sinorte = 0entonces el resultado deseado esyo = 0
© 2006 por ca Universidad Renégie Mellon octubre de 2006 PSP II - Verificación del diseño - 40
Otro ejemplo de bucle while -3
Para utilizar la verificación de casos, debemos considerar casos en los que
• Xes igual al primer elemento de la matriz
• Xes igual a cualquier elemento intermedio de la matriz
• Xes igual al elemento final de la matriz
• Xno es igual a ningún elemento
Aquí, miramosXno es igual a ningún elemento.
Deja que la matriza= <2, 3, 5, 7> connorte=4 yX=4.
La tabla de seguimiento de WhileLoop
Ciclo: 1 - 4: a = <2, 3, 5, 7>, n = 4, x = 4 Función: Búsqueda binaria

# Instrucción V/F i j k i+j X Alaska]
Inicializar i, j 0 4 0 4
1 Mientras yo <> j t
2 k := (i + j) div 2 Si a[k] 2 4 5
3 < x, i := k De lo F
4 contrario j := k 2
6 k := (i + j) div 2 Si a[k] 1 2 3
7 < x, i := k De lo t 1
8 contrario j := k
10 k := (i + j) div 2 Si a[k] 1 3 3
11 < x, i := k De lo t 1
12 contrario j := k
14 k := (i + j) div 2 Si a[k] 1 3 3
15 < x, i := k De lo F 1
dieciséis contrario j := k
Discusión de verificación
El algoritmo no logra terminar para este conjunto de entradas.
Una tabla de seguimiento revelará defectos de diseño, pero no

sugiere cómo solucionarlos.
La corrección del algoritmo es reemplazaryo = kconyo = k + 1.
Con este cambio, el siguiente paso sería responder las tres preguntas
de WhileLoop, con una tabla de seguimiento si es necesario.
Comentarios: Verificación del programa
Si se hacen correctamente, estos métodos de verificación pueden garantizar la

corrección del programa.
El dominio de estos métodos de verificación requiere habilidad y

práctica.
La prueba de terminación de bucle es fundamental porque los bucles sin

fin son difíciles de identificar con otros métodos.
Si bien a menudo puede responder las preguntas de verificación mediante

inspección, en caso de duda, verifique los resultados con una tabla de
seguimiento.
UML y verificación -1
Los diseños gráficos pueden ser difíciles de verificar y, a menudo, requieren
cuidados especiales.
Los diagramas UML pueden y deben comprobarse para comprobar su coherencia.
Los nombres de todas las clases, operaciones y atributos también

deben definirse y utilizarse de forma coherente.
Los gráficos de estado UML se pueden verificar como se muestra antes, pero el
estado y las condiciones de transición deben ser explícitos.
UML y verificación -2
La ejecución en diagramas de secuencia UML se puede rastrear si los
diagramas son suficientemente detallados.
De manera similar, cada mensaje enviado entre objetos debe estar

respaldado por un enlace transitable definido en un diagrama de clases.
Algunas herramientas UML pueden simular la ejecución de modelos UML,

pero estas herramientas deben usarse sólo después de otras técnicas de
revisión.
Mensajes para recordar
Mejorará significativamente el rendimiento de su revisión de diseño
utilizando métodos disciplinados de revisión de diseño.
Con programas complejos, el tiempo dedicado a verificar los diseños se

compensará con creces con el tiempo ahorrado en las pruebas.
Practique el uso de técnicas de verificación y luego seleccione las más

efectivas para encontrar los defectos que encuentre con más
frecuencia en las pruebas.
Traducido del inglés al español - www.onlinedoctranslator.com

Usando la PSP

octubre de 2006 PSP II - Cómo usar la PSP - 1

Trabajando en un equipo
¿Qué es el TSP?
Lanzando un equipo TSP
Trabajando en un proyecto TSP
Próximos pasos
Comentarios Concluyentes
© 2006 por la Universidad Carnegie Mellon octubre de 2006 PSP II - Cómo usar la PSP - 2
Trabajar en equipos
Los equipos exitosos son satisfactorios y raros.
Aunque muchos equipos se acercan a alcanzar sus objetivos comerciales

y de producto, a menudo lo hacen a expensas del equipo.
“Hay algo mágico en un equipo eficaz.

• Tiene una ética, una actitud y una energía que impregnan
todo lo que hace.
• Los compañeros se apoyan unos a otros.
• Saben intuitivamente cuándo y cómo ayudar.
• Se reúnen en el momento justo.
• Los integrantes son parte de un esfuerzo común.
• Tienen un sentido de pertenencia y un sentimiento de camaradería”.
- Introducción al proceso del software TEAM, Watts Humphrey
Esto es lo que llamamos un "equipo gelatinoso".

Equipos gelatinosos
Los equipos Jelled hacen el mejor trabajo.
El objetivo del TSP es construir y mantener equipos

gelatinizados.
Trabajo intelectual complejo
Para realizar un trabajo intelectual complejo y de alta calidad, los profesionales
del software deben
• comprender verdaderamente el problema
• encontrar el problema como un desafío interesante
• quiero resolver el problema
• tener la flexibilidad para resolver el problema a su manera
A los desarrolladores de software les gusta trabajar de esta manera.
Es muy gratificante trabajar en un equipo que

• comparte objetivos comunes
• trabaja cooperativamente para alcanzar sus objetivos
Cómo evolucionan los equipos exitosos
La capacidad de un equipo para trabajar en conjunto de manera efectiva se desarrolla con
el tiempo.
Los equipos generalmente comienzan con
• objetivos diversos
• no hay un sentido claro de responsabilidades
• ideas vagas sobre el producto a construir
• diferentes enfoques del trabajo
Con el tiempo, los miembros del equipo pueden llegar a un

entendimiento común de estos factores.
Sólo entonces podrán hacer su mejor trabajo.
Requisitos de los miembros del equipo
Si bien los miembros capacitados son esenciales, las habilidades técnicas por sí solas
no son suficientes.
Trabajo en equipo de alto rendimiento

• es interdependiente
• implica un compromiso compartido
Para trabajar de esta manera, los miembros del equipo deben

• ser personalmente disciplinado
• entender sus propias habilidades
• hacer compromisos realistas
¿Qué es el TSP?
El TSP es un marco y una estructura de proceso para
crear y guiar equipos de ingeniería.
El TSP contiene
• atrabajo en equipoproceso que construye objetivos,
compromisos y cohesión compartidos
• atrabajo en equipoproceso que guía los procesos y
prácticas de ingeniería del equipo
Un requisito previo para los equipos de TSP es el dominio de las habilidades

de ingeniería de software y procesos que se enseñan en el curso de PSP.
Construyendo equipos efectivos con el TSP
PSP TSP TSP

Desarrollo de habilidades Trabajo en equipo Trabajo en equipo
Objetivos del proyecto comunicación en equipo

Medidas personales
Roles de equipo Coordinación del equipo
Disciplina de proceso
Proceso de equipo Seguimiento del estado
Estimación y planificación
Plan de proyecto Análisis de riesgo
Gestión de la calidad
plan equilibrado Informes del proyecto
Equipo Equipo Equipo

Miembros Disciplinas Gestión
Autodirigido
Equipos de desarrollo
¿Qué hace el TSP?
El TSP establece un entorno que construye, desarrolla, utiliza y
apoya el trabajo en equipo autodirigido.
Un equipo autodirigido
• establece sus propios objetivos
• establece sus propios roles

• decide su propia estrategia de desarrollo
• define sus propios procesos
• desarrolla sus propios planes
• mide, gestiona y controla su propio trabajo
Los equipos autodirigidos son equipos consolidados y hacen el mejor

trabajo.
Apoyo de la gerencia
La gerencia aceptará que usted y sus compañeros de equipo
trabajen como un equipo autodirigido siempre que
• esforzarse por satisfacer sus necesidades
• informar periódicamente sobre su trabajo
• convencerlos de que sus planes son sólidos
• hacer un trabajo de calidad
• responder a las necesidades cambiantes

• acudir a ellos en busca de ayuda cuando la necesite
Si bien esto no es difícil para usted, requiere

• habilidad
• trabajo disciplinado
• orientación y apoyo
© 2006 por la Universidad Carnegie Mellon octubre de 2006 PSP II - Uso de la PSP - 11
Desarrollar las habilidades necesarias
La PSP te muestra cómo

• medir y gestionar su trabajo personal
• utilizar datos para hacer planes sólidos
• gestionar la calidad de su trabajo
• producir productos de calidad en cronogramas predecibles
Con el TSP, usted utiliza estas habilidades para convencer a la gerencia de

que apoye el trabajo en equipo autodirigido.
El lanzamiento de TSP le inicia en este camino.
Estructura y flujo del TSP
El lanzamiento de un TSP inicia cada fase
Lanzamiento
importante del proyecto.
El equipo construye un
entendimiento común del trabajo y Fase de desarrollo A
la forma de hacerlo.
Los miembros elaboran planes Post mortem

para guiar su trabajo.
Las fases posteriores comienzan con

el relanzamiento de TSP. Relanzar
Desarrollo
Fase B
Post mortem
El lanzamiento de TSP -1
El lanzamiento de TSP es un taller de cuatro días que involucra al

equipo y la gerencia.
Participan el líder del equipo y todos los miembros del equipo.
El taller de lanzamiento no es un curso; es parte del

proyecto.
Se planifican y realizan un seguimiento de los talleres de lanzamiento.
El lanzamiento de TSP -2
El lanzamiento de TSP realiza tareas esenciales.

• Sin el lanzamiento, estas tareas generalmente no se abordan
hasta bien avanzado el proyecto, si es que lo hacen.
• Entonces suele ser demasiado tarde para prevenir problemas.
• Estos problemas descubiertos tardíamente suelen provocar retrasos.
El taller de lanzamiento acelera la formación de equipos. Se construye

• una comprensión común del trabajo
• acuerdo sobre cómo hacer el trabajo
• compromiso con un plan de equipo
• apoyo de gestión al plan
• los productos necesarios para obtener soporte de gestión
Los productos de lanzamiento de TSP
Necesidades del negocio
Objetivos de gestión
Producto
requisitos
Cómo Qué
¿Qué? ¿Cómo? ¿Cuando? ¿OMS? ¿Bueno? ¿si?
Metas del equipo estrategia de equipo plan de horas de trabajo Roles de equipo Plan de calidad Riesgo
evaluación
Conceptual Proceso de equipo Horario Planes de tareas
diseño Mitigación de riesgos
Valor agregado Planos detallados planes
Planificado plan
productos Alterno
planes
Estimaciones de tamaño
y a
© 2006b Universidad Crnegie Mellon octubre de 2006 PSP II - Cómo usar la PSP - 16
Las reuniones del proceso de lanzamiento
Día 1 Dia 2 Día 3 Día 4
1. Establecer
7. Conducta
4. Construya la parte superior
9. Espera
producto y abajo y
riesgo gestión
negocio siguiente fase
evaluación revisar
objetivos planes
8. Prepárate
2. Asignar roles 5. Desarrollar
gestión Lanzamiento
y definir la calidad
sesión informativa y Post mortem
objetivos del equipo plan
informe de lanzamiento
3. Producir 6. Construir fondo

desarrollo arriba y Nuevos equipos:
proceso y equilibrado proceso TSP

estrategia planes revisar
© 2006 por Universidad Renégie Mellon

California octubre de 2006 PSP II - Uso de la PSP - 17
Reunión de lanzamiento de TSP 1
La reunión 1 proporciona a los desarrolladores la información que

necesitan para elaborar su plan.
La reunión 1 suele estar dirigida por el entrenador de TSP.
El orden del día es el siguiente.

• Patrocinador: comentarios de apertura
• Presentaciones del entrenador y de los asistentes
• Coach: revisión de objetivos y agenda de la reunión
• Alta dirección: objetivos del proyecto
• Marketing/cliente: requisitos del proyecto
• Preguntas y discusión
Reunión 1 Estrategia -1
La gerencia generalmente describe los productos y cronogramas
necesarios.
Si bien esta “solución” suele ser agresiva, sólo representa una

forma posible de hacer el trabajo.
El equipo debe comprender las verdaderas necesidades de la gerencia

para abordarlas.
Ni siquiera dé a entender que cree que los objetivos de la dirección no

son realistas.
Su actitud debería ser: “Si eso es lo que quiere la dirección, haremos

todo lo posible para lograrlo”.
Reunión 1 Estrategia -2
En la reunión 1, el equipo debe hacer suficientes preguntas para
comprender qué necesita la administración.
En las reuniones 2 a 8, el equipo se esforzará por elaborar un plan

que satisfaga estas necesidades.
A estas reuniones sólo asisten el equipo, el líder del equipo y el

entrenador del TSP.
Luego, en la reunión 9, el equipo se reunirá con la gerencia y

otras partes invitadas para revisar el plan del equipo.
La reunión 2 tiene dos objetivos.

• obtener un acuerdo sobre los objetivos del equipo
• establecer los roles de los miembros del equipo
El líder del equipo generalmente dirige al equipo a través de la discusión de

objetivos, con la ayuda del entrenador de TSP.
• Se comienza con los objetivos establecidos por la gerencia.
• Luego revisa los objetivos implícitos pero no declarados.
• A continuación, acuerdan los objetivos del equipo.
• Finalmente, define las medidas de objetivos.
Una vez que se ponen de acuerdo sobre los objetivos, el líder del equipo y el
entrenador guían al equipo a través de la selección de roles.
Los roles de TSP -1
Los roles de TSP establecen responsabilidades para la operación del equipo.
Los roles de desarrollo son

• Gerente de interfaz del cliente: punto focal para
requisitos y problemas relacionados con el cliente.
• Gerente de diseño: establece estándares de diseño y guía
el trabajo de diseño.
• Gerente de implementación: define los estándares de
implementación y maneja los problemas de implementación.
• Gerente de pruebas: garantiza que los problemas de las pruebas se consideren
adecuadamente y maneja la planificación y coordinación de las pruebas.
Los roles de TSP -2
Las funciones de soporte del TSP son
• Gerente de planificación: ayuda al equipo a mantener, rastrear e
informar sobre el plan y su estado.
• Administrador de procesos: guía el trabajo de definición del proceso,
maneja los PIP y monitorea los datos del proceso.
• Gerente de calidad: revisa la calidad del proceso y del producto y
monitorea las inspecciones del equipo.
• Gerente de soporte: garantiza que las herramientas y ayudas de soporte
adecuadas estén disponibles y maneja los problemas de soporte.
El equipo asigna roles adicionales de seguridad,

protección, usabilidad, etc., si son necesarios.
El papel del líder del equipo
El líder del equipo normalmente no asume ningún rol en el equipo.
Las responsabilidades del líder del equipo son

• Proporcionar liderazgo al equipo: mantener la motivación, priorizar el
trabajo, guiar a los miembros del equipo.
• Mantener la comunicación del equipo: organizar reuniones semanales
y comunicar las necesidades y acciones de la gerencia.
• Obtener recursos: conseguir el personal necesario y proteger a los miembros
del equipo de demandas ajenas al proyecto.
• Informar a la gerencia: informar a la gerencia sobre el progreso y los
problemas del equipo y obtener ayuda cuando sea necesario
En todos los equipos, excepto en los muy pequeños, el líder del equipo no
tiene tiempo para hacer mucho o ningún trabajo de desarrollo.
Reunión 2 Productos
En la reunión 2, el equipo produce y documenta dos
productos.
los objetivos del equipo
• definir cada objetivo

• decidir sobre las medidas objetivo
• asignar a los miembros la responsabilidad de realizar el seguimiento del objetivo
• comparar las metas del equipo con los objetivos de la gerencia
Los roles del equipo

• el miembro asignado a cada rol del equipo
• cualquier rol adicional que el equipo considere necesario
En la reunión 3, el equipo
• define los productos a producir
• acuerda el diseño conceptual del producto
• desarrolla una estrategia de proyecto
• define el proceso de desarrollo
Con la guía del entrenador.

• el líder del equipo dirige al equipo en la definición de sus productos
• el líder del equipo también lidera al equipo en el establecimiento de la
estrategia de desarrollo
• el gerente de diseño lidera el esfuerzo para producir el
diseño conceptual
• el gerente de procesos lidera al equipo en la definición de sus
procesos de desarrollo
En la reunión 3, el equipo produce y documenta cuatro
productos.
La lista de productos planificados del proyecto.
El diseño conceptual del producto.
La estrategia de desarrollo del equipo.
El proceso de desarrollo del equipo.
En la reunión 4, el equipo desarrolla su plan de arriba hacia abajo para todo el

trabajo.
Ya sea que el trabajo dure cinco semanas o cinco años, el plan de arriba hacia
abajo del equipo cubre la entrega del producto final.
La duración del plan se define por la duración del compromiso

del equipo.
Para un proyecto de cinco años, si el compromiso es para

• una fase, el equipo hace un plan de una sola fase
• si el compromiso es por cinco años, el equipo elabora un plan de
cinco años
Agenda de la reunión 4
En la reunión 4, los equipos primero desarrollan una estimación detallada del tamaño del
producto.
Luego, en función del proceso definido, los miembros del equipo

definen las tareas del trabajo y estiman el tiempo para cada una.
Durante la reunión 4, el equipo a menudo descubre que no puede

satisfacer las necesidades de la gerencia con los recursos disponibles.
Luego, el equipo diseña planes alternativos con combinaciones variadas de

recursos, funciones y cronogramas.
En la reunión 4, el equipo produce los siguientes productos.
Estimaciones del tamaño del producto
Plan de horas de trabajo
el plan de horario
El plan del valor ganado
Uno o más planes alternativos si es necesario
Estimación del tamaño del proyecto
Los equipos de TSP normalmente documentan sus estimaciones de tamaño en una herramienta de
soporte de TSP.
Las estimaciones de tamaño se parecen a las siguientes:
Plan de recursos y tareas del equipo
La lista de tareas incluye el ensamblaje del producto, la fase del proceso, la tarea, la
asignación del equipo, el tamaño estimado y el tiempo de desarrollo.
En la reunión 5, el equipo elabora su plan de calidad.
Los miembros estiman los defectos inyectados a partir de tasas históricas

de inyección de defectos y tiempos de fase planificados.
También utilizan datos históricos de rendimiento para estimar los

defectos eliminados por fase.
El equipo discute y acuerda la estrategia y el

plan de gestión de calidad.
El producto de la reunión 5 es un plan de calidad con defectos del

producto entregado y defectos proyectados inyectados y
eliminados por fases.
Plan de calidad
Para realizar el plan de calidad, el equipo ingresa datos de inyección de

defectos y rendimiento y la herramienta de soporte TSP calcula los defectos
inyectados y eliminados por fase.
En la reunión 6, los miembros del equipo hacen planes personales para el

siguiente período del plan, normalmente de tres a cinco meses.
El director de planificación del equipo lidera este esfuerzo, bajo la

dirección del entrenador de TSP.
• quién se encargará de cada tarea
• planes de miembros para las tareas asignadas
• plan de equipo consolidado
El equipo revisa el plan consolidado y reequilibra la carga de trabajo de

los miembros del equipo si es necesario.
El encuentro son 6 productos.

• planes equilibrados para los miembros del equipo
• un plan de equipo general consolidado y planes alternativos
En la reunión 7, el equipo evalúa los riesgos percibidos del plan.
Un riesgo puede ocurrir o no, mientras que es seguro que ocurrirá un

problema.
El equipo decide qué riesgos rastrear y gestionar y qué

planes de mitigación se necesitan.
El producto de la reunión es una lista de los riesgos de cada

• clasificado según la probabilidad
• clasificado según la gravedad
• asignado a un miembro del equipo para su seguimiento
En la reunión 8, el equipo prepara la presentación del plan

de la reunión 9 a la gerencia.
La agenda típica de la reunión 9 es la siguiente.

• Un breve resumen de las conclusiones de la reunión.
• Una revisión del proceso de lanzamiento
• El resumen de los objetivos del equipo y de la dirección.
• Las asignaciones de roles de los miembros del equipo.
• La estrategia y el proceso de desarrollo.
• El plan y los principales planes alternativos.
• El plan de calidad
• Evaluación y mitigación de riesgos
• Preguntas y discusión
Estrategia de la Reunión 8
El líder del equipo generalmente presenta el plan y los miembros

del equipo participan según lo elija el equipo.
Es importante proporcionar información resumida del plan, pero

también tener los detalles disponibles si se solicita.
Los productos de la reunión 8 son

• transparencias para la presentación de la reunión 9
• copias de los materiales del plan
• las posibles preguntas de gestión y las respuestas acordadas por
el equipo
• una lista de la ayuda necesaria de la dirección para implementar el
plan
El equipo, el líder del equipo, el entrenador, la dirección y los visitantes

invitados asisten a la reunión 9.
El propósito de la reunión es
• describir el plan del equipo a la dirección
• responder a las preguntas de la gerencia
• obtener la aprobación de la gerencia del plan o de la alternativa
seleccionada
• identificar las acciones necesarias, quién las tomará y cuándo
El producto de la reunión suele ser un plan aprobado o las acciones

necesarias para obtener la aprobación.
Cuando la dirección no está de acuerdo con alguno de los planes,

normalmente deciden reconsiderar sus necesidades.
Estrategia de la Reunión 9
Es aconsejable comenzar la reunión 9 con una declaración como: "No

pudimos cumplir con precisión con sus requisitos, pero hemos
desarrollado varios planes alternativos que creemos que se aproximan
razonablemente".
Esto le dice a la gerencia qué esperar y les permite escuchar

en lugar de hurgar en cada posible debilidad del plan.
El equipo debe explicar cómo se hizo el plan.

• los datos utilizados
• las suposiciones hechas
• dónde tenían que adivinar
Post mortem del lanzamiento de TSP
La autopsia del lanzamiento es

• consolidar el plan y los datos de lanzamiento
• revisar el proceso de lanzamiento y producir PIP
• discutir temas abiertos y acordar cómo manejarlos
Los pasos finales del lanzamiento son

• asignar la responsabilidad del cuaderno del proyecto (a menudo el
director del proceso)
• asignar la responsabilidad del manejo de los PIP
• datos de lanzamiento de archivos en el cuaderno del proyecto
• enviar los datos del lanzamiento al SEI
Trabajando en un proyecto TSP
Una vez que tenga apoyo administrativo para lanzar un

equipo TSP, deberá conservar ese apoyo.
Esto requiere que usted y sus compañeros de equipo hagan cinco cosas.
• Sigue el proceso que hayas definido.
• Mantener los planes individuales y de equipo.
• Gestionar la calidad del producto.
• Realice un seguimiento e informe periódicamente de su progreso.
• Demostrar continuamente un alto rendimiento.
Siguiendo el proceso -1
Aunque usted mismo definió el proceso, probablemente será un
desafío seguirlo de manera constante.
Registrar datos sobre tiempo, tamaño y defectos lleva poco tiempo, pero es
fácil de olvidar.
Cuando lo olvide, simplemente ingrese su mejor estimación.
Sin buenos datos sobre tiempos, tamaños y defectos, no se puede gestionar

con precisión el cronograma del proyecto o la calidad del producto.
La historia demuestra que, sin una gestión precisa, los proyectos

de software suelen fracasar.
Siguiendo el proceso -2
La clave para seguir el proceso es reconocer que
cuanto más lo hagas, mejor lo lograrás.
Lo más emocionante es que, a medida que mejora la fidelidad de su

proceso, también lo hará su desempeño laboral.
Esto a su vez mejorará

• su orgullo por su trabajo
• la calidad de sus productos
• su credibilidad ante la dirección
• cómo la gerencia lo valora como empleado
Mantener el plan
Campos desafiantes y dinámicos como el software enfrentan cambios
constantes.
A medida que desarrollamos productos, aprendemos más sobre lo

que se necesita, cómo construirlo y cómo mejorarlo.
Para incorporar este aprendizaje continuo, debemos actualizar nuestros

planes.
Conserve copias de los planes antiguos, pero no dude en cambiarlos.
Si no lo hace, no podrá realizar un seguimiento ni informar sobre el

trabajo.
Seguimiento de la calidad del producto
Los datos de PSP proporcionan una gran cantidad de información que le ayudará
• gestionar la calidad de su trabajo mientras lo hace
• evaluar y mejorar la calidad de cada paso del proceso
• evaluar la calidad de sus productos a medida que los construye
• decidir qué productos tienen una calidad marginal y deben ser
reelaborados
Las medidas de calidad más útiles son el rendimiento, A/FR, tasas de

revisión, defectos/tamaño y PQI.
Datos de defectos por fase
Defectos reales inyectados en fase Porcentaje para el sistema de ensamblaje
Con los datos de PSP, las herramientas

de TSP pueden mostrar mucha Código
información útil.
Requisitos
Requisitos
Diseño de alto nivel
Diseño detallado
Un ejemplo es el porcentaje de Código
defectos reales o planificados Diseño detallado

Diseño de alto nivel
inyectados por fase.

Defectos reales eliminados en la fase Porcentaje para el ensamblaje SISTEMA
Otra es la distribución de defectos

eliminada por fase. Prueba de unidad
Inspección de requisitos
Revisión de código
Inspección de requisitos
Inspección DAN
Inspección DAN
Revisión DLD
Inspección DLD
Revisión de código
Prueba de unidad
Revisión DLD
Inspección DLD
© 2006 por CA Universidad Renégie Mellon octubre de 2006 PSP II - Uso de la PSP - 47
Perfiles de calidad de TSP seleccionados
Perfil de calidad para el montaje 1 Perfil de calidad para el montaje 2 Perfil de calidad para el montaje 3
Defectos de prueba = 0 Defectos de prueba = 0 Defectos de prueba = 0

Tiempo de diseño/código Tiempo de diseño/código Tiempo de diseño/código
1 1 1
0,8 0,8 0,8
0,6 0,6 0,6
0,4 0,4 0,4
Tiempo de revisión del diseño Tiempo de revisión del código Tiempo de revisión del diseño Tiempo de revisión del código Tiempo de revisión del diseño Tiempo de revisión del código
0,2 0,2 0,2
0 0 0
Defectos de prueba unitaria/KLOC Compilar defectos/KLOC

Defectos de prueba unitaria/KLOC Compilar defectos/KLOC Defectos de prueba unitaria/KLOC Compilar defectos/KLOC
PQI = 0,97 PQI = 0,88 PQI = 0,71

Perfil de calidad para el montaje 4 Perfil de calidad para el montaje 5 Perfil de calidad para el montaje 6
Defectos de prueba = 0 Defectos de prueba = 1 Defectos de prueba = 3

Tiempo de diseño/código Tiempo de diseño/código Tiempo de diseño/código
1 1 1
0,8 0,8 0,8
0,6 0,6 0,6
0,4 0,4 0,4
Tiempo de revisión del diseño Tiempo de revisión del código Tiempo de revisión del diseño Tiempo de revisión del código Tiempo de revisión del diseño Tiempo de revisión del código
0,2 0,2 0,2
0 0 0
Defectos de prueba unitaria/KLOC Compilar defectos/KLOC Defectos de prueba unitaria/KLOC Compilar defectos/KLOC
Defectos de prueba unitaria/KLOC Compilar defectos/KLOC
PQI = 0,59 PQI = 0,15 PQI = 0,04
© 2006 por CA Universidad Renégie Mellon octubre de 2006 PSP II - Uso de la PSP - 48
Seguimiento e informes del progreso
Los gerentes siempre tienen preguntas y cuanto menos saben,
más preguntan.
• ¿Se está quedando atrás el equipo?
• ¿Están todos trabajando duro?
• ¿Lograrán alcanzar el próximo hito?
• ¿Qué puedo hacer para mantenerlos a tiempo?
• ¿Qué puedo decirle a la alta dirección sobre el estado del proyecto?
Para ser un equipo autodirigido, necesita la confianza de la dirección.
Para mantener la confianza de la gerencia, responda estas preguntas

antes de que ellos piensen en hacerlas.
Esto requiere datos, análisis e informes periódicos.
Indicadores de progreso del proyecto
Las horas de trabajo semanales inadecuadas son a menudo una señal temprana de
que el equipo se está quedando atrás y necesita ayuda administrativa.
Horas acumuladas planificadas y reales por semana
500.0
450.0
400.0
350.0
Horas acumuladas
300.0
Horas planificadas acumuladas Horas
250.0 reales acumuladas Horas planificadas
acumuladas de referencia
200.0
150.0
100.0
50.0
0.0
3/1/2005
16/8/2004
30/8/2004
8/11/2004
6/12/2004
11/10/2004
25/10/2004
22/11/2004
20/12/2004
13/09/2004
27/09/2004
17/01/2005
31/01/2005
14/02/2005
Semanas
© 2006 por CA Universidad Renégie Mellon octubre de 2006 PSP II - Cómo usar la PSP - 50
Datos semanales del equipo
Los equipos de TSP revisan su estado, progreso y planes cada semana.
El informe resumido semanal proporciona todos los datos necesarios para determinar con
precisión el estado del proyecto y el ritmo de progreso.
Estos datos proporcionan la información que necesita para los informes de

gestión.
Demostrar rendimiento
El buen trabajo es satisfactorio, rentable y divertido, pero también
invisible.
Hoy en día, la mayoría de las organizaciones de desarrollo utilizan la

gestión de crisis.
Normalmente trabajan en las crisis e ignoran todo lo

demás.
Con el TSP, rara vez tendrá crisis y nunca tendrá sorpresas

en su agenda.
A menos que anuncie periódicamente sus éxitos, su

trabajo no se notará y perderá el apoyo de la dirección.
Los siguientes pasos
Una vez que completes elPSP para ingenierosPor supuesto, usted está
calificado para ser miembro del equipo TSP.
También puedes capacitarte para ser un instructor PSP autorizado y un

entrenador TSP.
Formación de instructores de PSP
El SEIFormación de instructores de PSPEl curso te enseña a

impartir los cursos PSP y TSP.
• el seminario ejecutivo de TSP
• Capacitación en gestión de TSP
• el curso de proceso personal
• los cursos de ingeniería PSP I y PSP II
Como instructor autorizado de PSP, puede obtener una licencia para

utilizar los materiales del curso SEI.
También debe proporcionar datos de los estudiantes y evaluaciones

de cursos para cada curso que imparte.
Requisitos de formación de instructores
Criterio para entrar
• completar una prueba previa escrita (libro abierto)

• enviar los datos de su estudiante de PSP al SEI para su evaluación
y garantizar que tiene un conocimiento básico del PSP
• experiencia previa en enseñanza o oratoria
Realizar el curso de capacitación de cinco días en el SEI dentro de los dieciocho

meses posteriores a la finalización delPSP para ingenieroscurso.
• presentar los datos de su PSP y un estudio de caso
• aprobar un examen de calificación (a libro cerrado)
Propósito del entrenamiento del entrenador
El SEIFormación de entrenadores TSPTe enseña a entrenar equipos de

TSP.
Es un curso de cinco días impartido en el SEI.
Para asistir debes

• ser un instructor de PSP autorizado por SEI
• tener un acuerdo de licencia TSP entre su
organización y CMU
Para calificar como entrenador de TSP, SEI debe observar cómo

lanza exitosamente un equipo de TSP.
Certificación PSP
Como profesional certificado de PSP, contará con evidencia
reconocida de su competencia profesional en ingeniería de
software.
Esto lo hará más atractivo como empleado potencial y

aumentará su estatura profesional.
Para conocer más sobre el proceso de certificación de PSP,

comuníquese con el SEI.
Comentarios Concluyentes
Con la capacitación de PSP, ahora tiene las habilidades y el conocimiento
para realizar ingeniería de software superior.
Estas habilidades conllevan responsabilidades.
Para cumplir con estas responsabilidades, es útil considerar sus

objetivos personales.
El profesional responsable
Como profesional responsable, es necesario
• encontrar y aprender nuevos métodos
• utilice estos métodos en su trabajo
• reconocer sus fortalezas y debilidades
• identificar áreas de mejora
• práctica práctica práctica
• dar a conocer los métodos que le resulten útiles
• aprender de la historia
Esto asegurará su continuo crecimiento y mejora

profesional.
¿Qué quiere de la ingeniería de software?
¿Cuáles son tus objetivos personales?
Sorprendentemente a menudo logramos nuestros objetivos de maneras que

no esperábamos, así que mantén la mente abierta y sigue buscando.
Como todos llegamos al mismo final, debemos concentrarnos en

la ruta.
Si ocasionalmente puedes alcanzar la excelencia, el viaje podría

valer la pena.

Ilovepdf Merged

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ilovepdf Merged

Cargado por

Copyright:

Formatos disponibles

Traducido del inglés al español - www.onlinedoctranslator.

Pittsburgh, Pensilvania 15213-3890

Proceso de software personalSM

Patrocinado por el Departamento de Defensa de EE. UU. ©

octubre de 2006 PSP II - Diseño de software II - 1

Diseño de máquinas de estados.

Verificando máquinas de estados

© 2006 Universidad Carnegie Mellon octubre de 2006 PSP II - Diseño de software II - 2

El proceso de diseño no puede ser

El proceso de diseño se puede estructurar para

© 2006 Universidad Carnegie Mellon octubre de 2006 PSP II - Diseño de software II - 3

Según datos de 8.100 programas de PSP, los programadores

La mayoría de los programadores saben escribir programas

© 2006 Universidad Carnegie Mellon octubre de 2006 PSP II - Diseño de software II - 4

8.100 programas Número de programa

UML se basa en notaciones desarrolladas por

La estandarización por parte del Object Management Group (OMG) ha

© 2006 Universidad Carnegie Mellon octubre de 2006 PSP II - Diseño de software II - 7

Se está desarrollando OCL (Object Constraint Language) para

© 2006 Universidad Carnegie Mellon octubre de 2006 PSP II - Diseño de software II - 8

© 2006 CarneUniversidad Gie Mellon octubre de 2006 PSP II - Diseño de software II - 9

Cada caso de uso describe una unidad de funcionalidad y

Un caso de uso describe secuencias de interacciones normales

La descripción de un caso de uso es una perspectiva externa, en la que el

Los diagramas de actividad UML también pueden describir detalles de uso.

© 2006 CarneUniversidad Gie Mellon octubre de 2006 PSP II - Diseño de software II - 10

Media y desviación estándar

© 2006 CarneUniversidad Gie Mellon octubre de 2006 PSP II - Diseño de software II - 11

Nombre del caso de uso:Media y desviación estándar

Meta:Calcula la media y la desviación estándar de un conjunto de números. Actor:

Condición previa:El conjunto de números se almacena en un archivo de texto.

Condición final exitosa:Se han impreso la media y la desviación estándar.

1. El estudiante ejecuta el programa.

4. El programa imprime la media y la desviación estándar de los números del

© 2006 CarneUniversidad Gie Mellon octubre de 2006 PSP II - Diseño de software II - 12

Los diagramas de secuencia asignan las acciones del caso de

Los diagramas de secuencia también especifican las interacciones

Los diagramas de secuencia describen el orden temporal de las

UML también proporciona diagramas de colaboración que describen

© 2006 CarneUniversidad Gie Mellon octubre de 2006 PSP II - Diseño de software II - 13

msd: : datos: archivo de datos

Nombre del archivo( )

Los diagramas de clases UML describen las relaciones

Los diagramas de clases UML también especifican los métodos y

© 2006 CarneUniversidad Gie Mellon octubre de 2006 PSP II - Diseño de software II - 15

© 2006 CarnUniversidad Egie Mellon octubre de 2006 PSP II - Diseño de software II - 16

El diagrama de estado UML describe todos los estados que

Un diagrama de estado identifica

© 2006 CarneUniversidad Gie Mellon octubre de 2006 PSP II - Diseño de software II - 17

© 2006 C. arneUniversidad Gie Mellon octubre de 2006 PSP II - Diseño de software II - 18

Requisitos del programa:

(Resumen) Diagramas de clases

Especificaciones del programa:

Diseño de alto nivel:

Requisitos del módulo:

© 2006 Universidad Carnegie Mellon octubre de 2006 PSP II - Diseño de software II - 19

Requisitos del módulo:

Especificaciones del módulo:

© 2006 Universidad Carnegie Mellon octubre de 2006 PSP II - Diseño de software II - 20

Los diagramas de secuencia y clases UML proporcionan información

Los diagramas de clases UML registran la firma del método, pero la

© 2006 Universidad Carnegie Mellon octubre de 2006 PSP II - Diseño de software II - 21