1

Prefacio
Cuando menciono el software a los altos ejecutivos, recibo muchas reacciones. La mayoría
están frustrados. Ellos Se quejan de compromisos perdidos, problemas de calidad y sorpresas
desagradables. Otros tienen Han estado menos involucrados. El software era un problema,
pero esos problemas se han manejado. Nadie menciona las oportunidades de negocio del
software. Ellos piensan en el software como un Mal, algo que hay que evitar si es posible. Si
bien la mayoría de los ejecutivos estaría de acuerdo

Parte de su negocio está creciendo muy rápidamente, nunca piensan en él como un activo o un
oportunidad. Mediante el uso de los métodos descritos en este libro, las organizaciones han
transformado su software Grupos. El primer equipo de Boeing redujo el tiempo de prueba en
un 94%; Un grupo de la fuerza aérea duplicó la productividad; un El proyecto Teradyne entregó
un gran producto sin defectos. Estas y otras organizaciones son Obteniendo resultados
sobresalientes. Sin embargo, todos empezaron con un enfoque de Oportunidades con el
software.

Amenaza u Oportunidad
El software es una tecnología verdaderamente increíble. Tiene un costo de producción cero,
puede ser distribuido En todo el mundo en segundos, no se desgasta ni deteriora, y es el más
económico y Flexible para implementar casi cualquier función compleja. En casi cualquier
campo de la ingeniería O la ciencia, más de la mitad del tiempo de un profesional típico se
gasta ahora en el uso, el desarrollo,

Mejorar o mantener el software. Por cualquier medida, el software es un gran negocio. Para
visualizar las oportunidades con el software, considere lo contrario: amenazas potenciales.
Tomar Fabricación, por ejemplo. Supongamos que su principal competidor domina una
tecnología que corta Los costos de fabricación por la mitad, eliminó los retrasos en la
distribución y proporcionó Gastado o deteriorado. Si no capitalizó rápidamente esa tecnología,
casi Sin duda estar en problemas. Por el contrario, piense en las oportunidades si su
organización domina esta Tecnología y sus competidores no. Si bien el software es
precisamente esa tecnología, pocos Las organizaciones lo ven como una oportunidad o como
una amenaza. La razón principal es que muchos Los ejecutivos no creen que sus organizaciones
hacen mucho trabajo de software y, de los que lo hacen, pocos Tener suficiente conocimiento
o experiencia de software para apreciar cómo contribuye a su negocio. Una vez que piensan
que los problemas del software están bajo control, hacen todo lo posible para evitar el tema.

Un número creciente de ejecutivos han encontrado que el software es un poderoso activo

comercial. Sin embargo, estos mismos ejecutivos también han encontrado que moverse en el
mundo moderno de El software diseñado requiere una transformación organizacional. Lo que
es más, tienen Descubrieron que deben llevar personalmente esta transformación. No es un
cambio simple y, como Todos los cambios, esta transformación implica algo más que decirle a
la gente qué hacer. La mejor manera Explicar lo que está involucrado es contar la historia de
cómo los métodos descritos en este libro fueron creado.
2

El viaje de la transformación Durante mis 27 años con IBM, uno de mis trabajos fue director de
programación. yo supervisé 4.000 profesionales de software en 15 laboratorios y 7 países. En
cuatro años, tomamos esta Organización del borde del caos a una operación sana, comercial.
El primer paso fue Establecer prácticas eficaces de ingeniería y gestión y exigir que estas
prácticas sean seguido. Para asegurar que estas prácticas fueron entendidas, enviamos 1.000
gerentes a una semana curso de entrenamiento. Los resultados fueron extraordinarios. Esta
organización nunca había Entregar un producto a tiempo. Una vez que los gerentes fueron
todos entrenados y siguiendo una disciplina Proceso de planificación y compromiso, la
organización no dejó de cumplir un solo compromiso Próximos dos años y medio.

Cuando me retiré de IBM, en 1986, miré la industria del software en general. Era obvio Que el
software era una tecnología crucial, pero también estaba claro que el mal estado del software
La práctica de la ingeniería restringió seriamente tanto la economía de los Estados Unidos
como la sociedad en general. Yo Hizo lo que yo llamé un "compromiso escandaloso". Mi
compromiso era transformar el mundo Del software. El objetivo era traer al mundo en general
las prácticas y principios que Había tenido tanto éxito en IBM.

Al retirarme de IBM, me uní al Instituto de Ingeniería de Software (SEI) de Carnegie Mellon

University y fue nombrado director del programa de proceso de software. El SEI acababa de Ha
sido establecida por el Departamento de Defensa de los Estados Unidos para mejorar el estado
de la práctica de software. Esta misión era completamente consistente con mi "compromiso
indignante", que era conseguir Todos los profesionales de software y sus gerentes para
planificar y rastrear su trabajo, Métodos técnicos, y medir y gestionar la calidad de este
trabajo. Estaba convencido de que si Lo hicieron, los resultados serían extraordinarios.

Junto con un pequeño equipo de profesionales de SEI de ideas afines, pronto Capability
Maturity Model (CMM) ® para guiar a las organizaciones en la adopción de una gestión de
sonido Prácticas. El CMM ha sido muy efectivo y es utilizado por miles de organizaciones
alrededor del mundo. El CMM es ahora un estándar internacional, y es utilizado por muchos
Sucursales del gobierno de los Estados Unidos para evaluar el trabajo de software interno y
evaluar y supervisar El trabajo de sus contratistas.

® Registrado en la Oficina de Patentes y Marcas de los Estados Unidos. Aunque el esfuerzo de

CMM fue y sigue siendo muy exitoso, pronto vi problemas. Los CMM proporciona una
excelente orientación de gestión, pero su principal impacto está en los Sus técnicos. La CMM
no afecta directamente al trabajo de los ingenieros, y la Ingenieros y sus equipos todavía
estaban luchando. No hay duda de que una mejor gestión Ayuda, pero pronto me di cuenta de
que hasta que cambiamos las prácticas de los profesionales de software Nosotros mismos,
nunca podríamos lograr una verdadera capacidad de ingeniería de software experto. Por lo
tanto, El siguiente desafío fue motivar a los grupos de ingeniería a hacer precisamente eso.
Quería que conocieran el Mejores métodos, pero también quería que practicaran estos
métodos todos los días. Los Técnicas que desarrollé para hacer esto se llaman el Proceso de
Software Personal (PSP) SM y el Equipo de Procesos de Software (TSP) SM. El desarrollo de
estos métodos se describe en los capítulos 6 y 7. SM Personal Software Process, PSP, Team
Software Process y TSP son marcas de servicio de Carnegie
3

Universidad de Mellon. La historia de cómo su organización puede capitalizar en estos

métodos se dice en el resto de este libro. Estos métodos están produciendo resultados
extraordinarios para otras organizaciones, y usted puede ver esto como una amenaza o una
oportunidad. Como me dijo un gerente de ingeniería en Teradyne, "Con el TSP, estamos tan
lejos de la competencia que nadie nos atrapará nunca". Ha sido mi experiencia que los
proyectos que utilizan el TSP pueden duplicar su productividad y Mejorar la calidad del
producto en un orden de magnitud. La inversión requerida es predominantemente La
formación y los costos de mentoría y estos costos suelen recuperarse dentro de 12 a 18 meses.
4

CAPITULO 1

“Every Business is a Software Business” -

Cada negocio es un negocio de software
Resumen y conclusiones:

Los siguientes cinco puntos principales se hacen en este capítulo:

1. El software es cada vez más importante para su negocio. Si no puede administrar

eficazmente su trabajo de software, tendrá problemas para gestionar cualquier otra cosa.

2. El primer principio de la gestión de software es reconocer que usted está en el software y

tratar la gestión de software como crítica.

3. El segundo principio de la gestión de software es que la calidad viene primero, incluso antes
el horario.

4. El tercer principio de la gestión de software es que, para producir consistentemente calidad

Software, usted debe tener disciplinado y motivado equipos profesionales.

5. Hay maneras conocidas de manejar el software, pero usted debe saberlas y usted debe
utilizar ellos. Este libro explica estos métodos, cómo introducirlos y cómo usarlos. Aunque las
prácticas de software de sonido no son difíciles, no son obvias. El PSP y TSP proporcionar un
marco general para guiar a los ingenieros, gerentes y ejecutivos a través de la y ejecutar un
negocio de software eficaz y productivo.
5

CAPITULO 2

“Why Projects Fail” - Por qué fallan los proyectos

Resumen y conclusiones:

Los siguientes tres puntos principales se hacen en este capítulo:

1. Los dos componentes clave de la gestión de software son una dedicación a la

consistentemente disciplinado trabajo de ingeniería.

2. Cuando fallan los proyectos de software, generalmente es porque un gerente no

insiste en que el trabajo se haga de la manera correcta.

3. Las cinco causas más comunes de fracaso del proyecto son horarios poco realistas, la
inadecuada dotación de personal, los cambios en los requisitos perjudiciales, el trabajo
de mala calidad y la creencia en magia Todos estos problemas podrían haberse evitado
si la administración hubiera insistido en planificado y disciplinado.
6

CAPITULO 3

Rational Management - Gestión Racional

Resumen y conclusiones

Con un estilo de gestión racional, tiene datos precisos sobre la organización y puede
hacer sanas y oportunas. Hay cuatro elementos para la gestión racional:

1. Establecer metas agresivas a largo plazo, pero romper estas metas en realistas y
mensurables metas a corto plazo.

2. Exigir planes detallados y completos, revisar estos planes, y luego negociar la

compromisos con las personas que harán el trabajo.

3. Insistir en hechos y datos, y utilizar estos hechos y datos para ejecutar el negocio.

4. Monitorear el trabajo y usar los datos actuales para anticipar y resolver problemas
futuros.
7

CAPITULO 4

Why Quality Pays - Por qué la calidad paga

Resumen y conclusiones

Los siguientes seis puntos principales se hacen en este capítulo:

1. El software defectuoso es caro e incluso puede poner en peligro la vida.

2. Los ingenieros de software inyectan defectos porque son humanos.

3. El costo de encontrar y corregir un defecto aumenta exponencialmente a medida

que avanza el desarrollo.

4. El ingeniero que desarrolló un programa es el mejor capaz de encontrar y corregir

sus defectos.

5. Los métodos efectivos de eliminación de defectos requieren entrenamiento

especial.

6. Si no gestiona la calidad del software, nadie lo hará.

8

CAPITULO 5

Leadership Goals - Objetivos de Liderazgo

Resumen y conclusiones

Los siguientes seis puntos principales se hacen en este capítulo:

1. Al establecer objetivos, hacerlos claros y medibles, asignarlos a personas específicas,

y seguimiento del rendimiento contra ellos.

2. Las metas que se miden se gestionan y las metas que se administran a menudo se
cumplen.

3. Los objetivos que no se miden y gestionen no se cumplirán, y el desempeño

deteriorarse.

4. Para mejorar el rendimiento de ingeniería, debe cambiar lo que la gente hace.

5. Para cambiar su comportamiento, los ingenieros deben saber cómo hacer planes
detallados, administrar calidad y uso eficiente de los métodos de trabajo.

6. Para mejorar realmente la organización, los ingenieros deben utilizar

constantemente los métodos ellos saben y los gerentes deben guiar, apoyar y
entrenarlos en hacerlo.
9

CAPITULO 6

“Changing Engineering Behavior” -

Cambiando el comportamiento de la
ingeniería
Resumen y conclusiones

Los siguientes cinco puntos principales se hacen en este capítulo:

1. Para que los ingenieros usen métodos disciplinados, sus gerentes deben estar de
acuerdo con los métodos y apoyar su uso.

2. Para cambiar realmente el comportamiento de ingeniería y gestión, los gerentes

deben ser responsable de implementar los cambios.

3. Si los ingenieros de software deben cambiar su comportamiento, deben creer que el

nuevo métodos funcionarán para ellos.

4. Cuando los ingenieros toman el curso PSP, usan métodos disciplinados de ingeniería
para escribir diez programas.

5. A partir de sus datos personales de PSP, los ingenieros ven que mediante el uso de
métodos disciplinados, ya no les permite escribir programas de alta calidad de forma
predecible de lo que les llevó a escribir programas anteriores.
10

CAPITULO 7

Building Motivated Teams - Construyendo Equipos Motivados

Resumen y conclusiones

Los siguientes seis puntos principales se hacen en este capítulo:

1. Construir un equipo comprometido, dar a sus miembros objetivos agresivos y hacer

que plan para alcanzar estos objetivos.

2. Revise el plan del equipo y haga que los ingenieros lo defiendan.

3. Si el plan del equipo no satisface sus necesidades, negociar con el equipo.

4. Una vez que tenga un plan que pueda aceptar y que el equipo haya acordado
cumplir, tener un equipo comprometido.

5. Con equipos motivados y comprometidos, los proyectos ofrecerán

consistentemente productos en sus horarios comprometidos y por los costos
planeados.

6. El Proceso de Software de Equipo (TSP) le muestra a usted ya su organización cómo

mantener equipos comprometidos.
11

CAPITULO 8

The Benefits of Teamwork - Los beneficios del trabajo en equipo

Resumen y conclusiones

Los siguientes siete puntos principales se hacen en este capítulo:

1. Los beneficios de la introducción del TSP son una mejor predictibilidad, un menor
tiempo de ciclo, reducción de costos de desarrollo, mejora de la calidad del producto y
reducción de la rotación de empleados.

2. Un programa inicial de introducción de TSP debería capacitar y lanzar dos o tres

equipos de prueba.

3. En paralelo con estos equipos iniciales, las organizaciones deben entrenar a sus
propios instructores PSP y entrenadores TSP.

4. Después de que los proyectos iniciales se pongan en marcha con éxito y la

organización tiene sus propios los instructores calificados PSP y TSP entrenadores,
debe ampliar el TSP a otros grupos.

5. Los costos totales de introducción del TSP se devuelven en aproximadamente cuatro

meses de uso completo del TSP y el el retorno de la inversión es del 291%.

6. A una tasa de interés anual del 6%, el ROI del valor actual a cinco años es del 397%.

7. El período acumulado de recuperación de la inversión para la introducción de TSP es

de aproximadamente dos años.
12

CAPITULO 9

Next Steps - Próximos pasos

Resumen y conclusiones

La gente a menudo argumenta que la transformación organizacional es difícil, pero no

lo es. Lo que es difícil es mantener un enfoque de gestión en el trabajo. Para asegurar
que su organización sea realmente cambiado, siga estos siete pasos:

1. Establecer una política de calidad.

2. Identificar un campeón de mejora.

3. Establecer metas precisas y mensurables, con un sistema de seguimiento y

revisiones frecuentes.

4. Mantener a los gerentes de línea responsables de transformar los grupos que

manejan.

5. Proporcionar recursos de mejora, tales como el establecimiento y la dotación de

personal de un grupo de procesos (SEPG).

6. Establecer prioridades.

7. Proporcionar supervisión continua y demostrar interés personal continuo en la

transformación. Al tomar estos pasos, requiera un plan de acción específico con
responsabilidades nombradas para cada acción y una fecha de seguimiento. El
software es una parte importante de su negocio, y será más importante en el futuro. Si
La gente de su software no cumple constantemente con sus compromisos con
productos de calidad, negocio sufrirá, e incluso podría fallar. Para administrar su
negocio y mantener una competitividad posición en su mercado, debe tener una
capacidad de software superior.

Este libro describe una estrategia para una transformación de software que ha
funcionado para otros organizaciones y seguramente trabajarán para la suya.
Tomando los siete pasos descritos en este capítulo, usted tendrá una capacidad
superior de software, y lo tendrá más pronto que usted el pensamiento era posible.
13

Apéndice A
El Proceso TSP
Resumen

En este apéndice se presentan los cinco puntos principales siguientes:

1. El proceso TSP está diseñado para construir y mantener equipos motivados y

comprometidos que constantemente hacer un trabajo de calidad.

2. Para que un equipo de TSP sea exitoso, el líder del equipo y todos los seleccionados
y entrenados con antelación.

3. Para que el lanzamiento sea exitoso, debe ser dirigido por un entrenador de
lanzamiento de TSP cualificado.

4. Este entrenador trabajará con la gerencia y el equipo para asegurar que el el trabajo
de preparación está hecho.

5. Sin una formación adecuada, el proceso TSP no funcionará.

14

Apéndice B

Lanzamiento de un proyecto TSP

Resumen

Los siguientes seis puntos principales se hacen en este apéndice:

1. El lanzamiento de TSP es el paso más importante en la construcción de equipos

2. Para que los equipos de TSP tengan éxito, usted o algún otro ejecutivo o gerente
senior debe asistir a las reuniones de apertura y cierre.

3. Si no puede asistir a estas reuniones o no tiene tiempo para permanecer en la

reunión completa, envíe un ejecutivo que puede.

4. En la reunión de apertura, debe explicar las razones para la introducción del TSP y la
beneficios que el negocio espera.

5. Si esta es la primera vez que la organización ha utilizado el TSP, destaque su

importancia y este proyecto ayudará a los esfuerzos de mejora de la compañía.

6. Al comentar los requisitos del proyecto, sea sincero con el equipo. Hacer una plan
óptimo, los ingenieros deben entender las necesidades reales del proyecto. Solo
entonces hacen los trade-offs necesarios para producir un plan y un producto
superiores.
15

Apéndice C

Revisar un plan de proyecto

Resumen

Los siguientes ocho puntos principales se hacen en este apéndice:

1. Cuando los ingenieros hayan completado el lanzamiento del TSP, presentarán su

plan reunión final de la gerencia.

2. Un ejecutivo o gerente senior debe asistir a esta reunión.

3. El propósito de la revisión del plan es convencerle de que el equipo ha hecho un y

un plan realista para hacer el trabajo.

4. Siga la Lista de Verificación de la Evaluación del Plan para revisar el plan del equipo.

5. Al realizar esta revisión, pregunte sobre el diseño conceptual, la estimación del

tamaño, la productividad estimación, plan de calidad y evaluación del riesgo.

6. Al hacer una revisión exhaustiva, usted se satisface de que el plan fue hecho con
competencia y requieren que los ingenieros lo defiendan.

7. Una vez que los ingenieros hayan defendido su plan y lo hayan aceptado, serán
altamente motivados para cumplir su compromiso con usted.

8. Cierre la revisión con un breve resumen de su decisión sobre el plan y una revisión
de las acciones pendientes.
16

Apéndice D

La revisión trimestral del proyecto

Resumen y conclusiones

Los siguientes ocho puntos principales se hacen en este apéndice:

1. El objetivo de la revisión trimestral es motivar a los equipos a hacer su mejor

trabajo.

2. Realizar la primera revisión del proyecto de uno a dos meses después de que el
proyecto haya sido lanzado.

3. Al llevar a cabo la revisión, use la lista de verificación de la revisión trimestral del

TSP.

4. Las revisiones de TSP se llevan a cabo en etapas, con las primeras etapas de en la
planificación y seguimiento.

5. Si es necesario, repita las preguntas de la etapa inicial hasta que los resultados sean
satisfactorios.

6. Una vez que al menos algunos de los ingenieros hayan demostrado competencia en
la fase inicial, pasar a las preguntas de la etapa estándar. Estas preguntas se analizan
en el Apéndice E.

7. Al final de la revisión, solicite un resumen de las acciones a tomar, y verifique que

alguien se asigna a cada elemento de acción.

8. Cierre la reunión resumiendo los temas principales que usted explorará en el

próximo revisión, y agradecer al equipo y líder del equipo por sus esfuerzos.
17

Apéndice E

La revisión de la etapa estándar

Resumen y conclusiones

Los siguientes ocho puntos principales se hacen en este apéndice:

1. El objetivo de la revisión de la etapa estándar es mantener un equipo continuo y

centrarse en la calidad.

2. Al realizar una revisión de la etapa estándar, siga la Lista de verificación de la

revisión trimestral.

3. En la etapa estándar, el enfoque es primero en los datos de defecto y luego en la

calidad medida.

4. Si hay más de unos pocos problemas con la recopilación de datos sobre defectos,
antes de pasar a las otras preguntas.

5. Cuando los equipos han satisfecho los criterios de la etapa estándar, motivarlos a
utilizar sus datos para la mejora comparada.

6. La mejora comparativa debe continuar indefinidamente.

7. Al final de la revisión, solicite un resumen de las acciones a tomar, y verifique que

alguien está asignado para manejar cada uno.

8. Cierre la reunión resumiendo los principales temas que buscará en la próxima

revisión, y agradecer al equipo y líder del equipo por sus esfuerzos.
18

Apéndice F

Retorno de la inversión
Resumen y conclusiones

Los siguientes ocho puntos principales se hacen en este apéndice:

1. La mejora del proceso es una inversión, y debe evaluarse de la misma manera que

Otras inversiones.

2. Los cálculos del ROI se basan en los ahorros en tiempo de prueba y las reducciones
de defectos logrados por las organizaciones que han utilizado el TSP.

3. La estrategia de instalación de TSP requiere que los ejecutivos y los altos directivos
seminario de estrategia TSP.

4. Los próximos pasos son seleccionar los equipos iniciales, entrenar a los ingenieros y
gerentes, y lanzar los equipos.

5. Después de que los equipos iniciales están trabajando eficazmente, más equipos son
entrenados y lanzados.

6. Los instructores internos de PSP y los entrenadores de TSP también deben ser
entrenados para nuevos empleados, equipos de lanzamiento y orientación y apoyo de
coaching.

7. Para un ejemplo de organización con 100 ingenieros de software, el valor actual de 5

años costos y ahorros son $ 2.805.810 y $ 11.151.963 respectivamente, lo que, con un
6% anual tasa de interés, dan un ROI de 397%.

8. Con una tasa de interés anual del 10%, los costos y ahorros comparables son de $
2,524,350 y 9.277.230, con un ROI de 368%.