MODELOS Y CONTROL DE CALIDAD

SEMANA 6

Estándares de calidad
aplicados al software

Todos los derechos de autor son de la exclusiva propiedad de IACC o de los otorgantes de sus licencias. No está
permitido copiar, reproducir, reeditar, descargar, publicar, emitir, difundir, poner a disposición del público ni 1
ESTE
utilizarDOCUMENTO
los contenidos paraCONTIENE LAdeSEMANA
fines comerciales 6
ninguna clase.
 2
ESTE DOCUMENTO CONTIENE LA SEMANA 6
ÍNDICE
ESTÁNDARES DE CALIDAD APLICADOS AL SOFTWARE........................................................................ 5
OBJETIVOS ESPECÍFICOS ........................................................................................................................... 5
INTRODUCCIÓN ...................................................................................................................................... 5
1. MARCO DE MEJORA IDEAL................................................................................................................ 6
1.1. FASES QUE COMPONEN EL MARCO IDEAL....................................................................................... 6
1.1.1. INICIO ........................................................................................................................................ 7
1.1.2. DIAGNÓSTICO............................................................................................................................. 7
1.1.3. ESTABLECIMIENTO O PLANIFICACIÓN ............................................................................................. 7
1.1.4. EJECUCIÓN ................................................................................................................................. 8
1.1.5. APRENDIZAJE.............................................................................................................................. 9
2. EL PROCESO DE DESARROLLO DE SOFTWARE PERSONAL (PSP) ............................................................. 10
2.1. OBJETIVOS ............................................................................................................................... 10
2.2. MODELO COMO TÉCNICA PARA LA OBTENCIÓN DE DATOS ............................................................. 11
2.2.1. LÍNEA BASE DEL PROCESO PERSONAL (PSP0, PSP1) ......................................................................... 11
2.2.2. GESTIÓN PERSONAL DEL PROYECTO (PSP1, PSP1.1)......................................................................... 11
2.2.3. GESTIÓN PERSONAL DE LA CALIDAD (PSP2, PSP2.1)......................................................................... 13
2.2.4. PROCESO PERSONAL CÍCLICO (PSP3)............................................................................................. 14
3. PROCESO DE SOFTWARE PARA EQUIPOS (TSP)................................................................................... 14
3.1. OBJETIVOS ............................................................................................................................... 14
3.2. MODELO CONSTRUCCIÓN DE EQUIPOS DE TRABAJO EFICACES ........................................................ 15
3.2.1. LANZAMIENTO ......................................................................................................................... 16
3.2.2. ESTRATEGIA.............................................................................................................................. 16
3.2.3. PLANEACIÓN ............................................................................................................................ 16
3.2.4. REQUERIMIENTOS..................................................................................................................... 17
3.2.5. DISEÑO.................................................................................................................................... 17
3.2.6. IMPLEMENTACIÓN.................................................................................................................... 17
3.2.7. PRUEBAS.................................................................................................................................. 17
3.2.8. POST MORTEM ......................................................................................................................... 17
3.3. INTEGRACIÓN DE PSP - TSP ......................................................................................................... 18
COMENTARIO FINAL.......................................................................................................................... 19

3
ESTE DOCUMENTO CONTIENE LA SEMANA 6
REFERENCIAS ..................................................................................................................................... 20

ÍNDICE DE FIGURAS
Figura 1: Ciclo de vida modelo IDEAL .................................................................................................. 6
Figura 2: Cuadro de funcionalidad .................................................................................................... 12
Figura 3: Antecedentes desarrollos similares .................................................................................... 12
Figura 4: Fases del ciclo de vida de TSP ............................................................................................. 16
Figura 5: Cuadro comparativo TSP – PSP .......................................................................................... 18

ÍNDICE DE TABLAS
Tabla 1: Pasos línea base del proceso personal ................................................................................ 11
Tabla 2: Cálculo de componentes funcionales................................................................................... 13
Tabla 3: Formulario de registro de errores ........................................................................................ 13

4
ESTE DOCUMENTO CONTIENE LA SEMANA 6
ESTÁNDARES DE CALIDAD APLICADOS AL SOFTWARE

OBJETIVOS ESPECÍFICOS
 Analizar las fases que componen el marco de mejora ideal con el fin de proponer
iniciativas que contribuyan a su proceso de implementación.
 Aplicar el modelo de referencia PSP/TSP en el proceso de desarrollo de software.

INTRODUCCIÓN
La mejora del proceso de desarrollo de software dentro de una organización puede ser abordada
utilizando distintas estrategias, dependiendo de varios factores. Por ejemplo, el tamaño de la
organización, las competencias y conocimiento de los profesionales, también la experiencia y los
distintos tipos de proyectos de desarrollo de software que se realicen. De esta manera, una de las
formas es comenzar realizando un diagnóstico para entender el estado actual del proceso.
Posteriormente se identifican las brechas respecto al estado que se desearía alcanzar. Realizado lo
anterior, existen alternativas que permiten a la organización definir planes de mejora desde la
perspectiva personal de sus colaboradores, como también con una visión más corporativa. Dentro
de estas alternativas están los modelos IDEAL, PSP (proceso de desarrollo de software personal) y
TSP (proceso de desarrollo de software para equipos), que orientan a las organizaciones en sus
procesos de mejora. En el contenido de esta semana, se revisarán en detalle cada uno de estos
modelos.

5
ESTE DOCUMENTO CONTIENE LA SEMANA 6
 1. MARCO DE MEJORA IDEAL
Corresponde al modelo de referencia para normar el ciclo de vida en la mejora de procesos de
desarrollo de software, creado en el Instituto de Ingeniería de Software de la Universidad Carnegie
Mellon. Al igual que los modelos de calidad desarrollados para la industria del software, como los
vistos en las semanas anteriores, IDEAL ha tenido revisiones que le han permitido ampliar su
alcance y hoy es una herramienta que también puede utilizarse en cualquier proceso de mejora,
bajo un enfoque ingenieril y disciplinado (Piattini, 2012).

1.1. FASES QUE COMPONEN EL MARCO IDEAL

El modelo de proceso tiene una estructura que gobierna cada una de las actividades que se deben
realizar en un proceso de mejora. Está compuesto por cinco grandes fases que corresponden a:
inicio, diagnóstico, planificación, ejecución y aprendizaje. En cada una de ellas además se definen
actividades que se deben realizar. En la figura 1 se muestra el ciclo de vida de un proceso de
mejora.

Figura 1: Ciclo de vida modelo IDEAL

Fuente: adaptada de http://goo.gl/hteZEp

A continuación, se describe cada una de las fases indicadas en la figura, las cuales corresponden a
lo definido por el Software Engineering Institute (2009).

6
ESTE DOCUMENTO CONTIENE LA SEMANA 6
 1.1.1. INICIO

Corresponde al comienzo de una serie de actividades que se deben desarrollar previamente, antes
de iniciar las fases de diagnóstico y planificación. El alcance considera definir la infraestructura
requerida, los roles y responsabilidades que se deben establecer, como también los recursos que
se van a necesitar.

Uno de los entregables más relevantes de esta fase es la elaboración del plan de mejora de
procesos, en el cual se identifican las actividades propias de esta fase y las siguientes. Así también,
se revisa la aprobación del programa de mejora y sus objetivos, al igual que todo lo necesario para
llevarlo a cabo.

Respecto a la definición de objetivos, son declarados en una primera instancia como lineamientos
generales para posteriormente, describirlos con mayor detalle. Para realizar lo anterior, se debe
designar un grupo que dirija la gestión de las actividades y otro, que lidere los procesos de
ingeniería de software.

Finalmente, un tema que siempre debe ser contemplado en toda iniciativa es el ámbito de las
comunicaciones. Esto es, informar en la organización del inicio de la actividad. Lo cual también
abre una instancia para evaluar y determinar la preparación que internamente se requiere
desarrollar.

1.1.2. DIAGNÓSTICO

El diagnóstico da inicio al plan definido para realizar la mejora en el proceso de desarrollo de

software, en función de la visión que se ha definido en la organización, el plan de negocio, las
lecciones aprendidas de procesos anteriores y objetivos trazados en el mediano y largo plazo. En
esta fase, se establece además una línea base del estatus actual del proceso. Es decir, se hace un
“inventario” de las actividades realizadas y los procedimientos que las gobiernan. De este modo,
se genera una brecha respecto a las expectativas y se obtiene una idea más precisa de dónde
deben aplicarse los principales cambios a introducir con la mejora.

1.1.3. ESTABLECIMIENTO O PLANIFICACIÓN

Así como en la fase anterior se identificó una serie de aspectos del proceso de desarrollo que se
deben mejorar, en esta fase son priorizados de acuerdo a los criterios que la organización ha
establecido. Es decir, de una lista de mejoras sugeridas se debe establecer cuál o cuáles son más
beneficiosas en el proceso y, a la vez, cuáles responden a las necesidades que el negocio exige a la
organización de manera inmediata. Por esta razón, hay una profundización en el desarrollo de los
objetivos propuestos en el plan de mejora, transformándolos en objetivos más concretos y, en
consecuencia, medibles. Recordemos que una característica esencial en la definición de un
objetivo es que este pueda ser evaluado cuantitativamente. Por tanto, además, se deben definir
indicadores del proceso que ayuden a medir estos objetivos. Lo anterior deriva en la definición de

7
ESTE DOCUMENTO CONTIENE LA SEMANA 6
métricas para evaluar el proceso, siendo información de análisis que los grupos responsables de la
gestión y control del proceso de mejora deben ir evaluando.

Otro tema relevante de esta fase corresponde al plan de acción definido y que se aplica de
acuerdo a las mejoras que se han priorizado. Corresponde entonces al plan de trabajo orientado a
la implementación de las mejoras. Asimismo, para desarrollar el trabajo, los grupos que
intervienen deben ir generando documentación relativa al desarrollo de estas actividades. Esta se
conoce como plantillas, las cuales ayudan a estructurar el trabajo y seguir determinaos
procedimientos. Son creadas previamente, como parte de los artefactos requeridos.

En la etapa de preparación y establecimiento de las formas de trabajo se presenta la tarea de

estandarizarlas. Desde esa perspectiva, y pensando en dejar documentos que ayuden a la
organización a llevar a cabo estas iniciativas, surge documentación que forma parte de la mejora.
Por ejemplo, si se están refiriendo a plantillas, se pueden destacar:

 Minutas de reunión

 Plan de proyecto

 Carta Gantt tipo

 Documentos de inspección de trabajo

 Documentos de cierre de proyecto

1.1.4. EJECUCIÓN

En esta fase, se llevan a cabo todas las acciones que permiten implementar las mejoras
propuestas, priorizadas y previamente planificadas. Participan de esta fase todas las áreas que de
alguna u otra forma son incorporadas por el plan de mejoras propuestas. Se realizan pruebas y
mediciones y ajustes que van corrigiendo definiciones iniciales de los procesos. De esta forma, una
vez que los procesos han sido validados y aprobados por la organización, corresponde realizar el
plan de implantación, el cual considera los aspectos necesarios para que el resultado sea el
esperado. A continuación se cita algunos importantes:

 Aspectos comunicacionales que ayuden a difundir los cambios que se incorporarán y la

finalidad que se persigue al introducirlos. En este caso, objetivos de negocio y corporativos
que se abordarán. También en algunos casos es pertinente informar a clientes o
proveedores con el fin de alinear la relación sobre la base de criterios comunes.

 Aspectos de capacitación. Dados los cambios a introducir, será necesario entregar las
competencias necesarias a todas las áreas que son directamente involucradas.

8
ESTE DOCUMENTO CONTIENE LA SEMANA 6
  Aspectos de infraestructura. Necesario para poder realizar las actividades con la facilidad y
en forma fluida. Contando con todos los recursos físicos necesarios.

 Aspectos de tecnología. En el caso de que la mejora de procesos se apoye en el uso de

algún software o sistema de apoyo, es necesario preverlo y realizar todas las instalaciones
y actualizaciones requeridas.

1.1.5. APRENDIZAJE

Como en todo orden, el aprendizaje surge de la experiencia, de lo realizado, del entendimiento de

cómo un proceso funciona. Se identifican fortalezas y debilidades, se toma nota de aquello que
requiere ajustes y se pone énfasis en aquellos aspectos que se van consolidando. Es decir, el
aprendizaje conlleva muchas acciones y generación de conocimiento. Por ejemplo, se puede
evaluar si los objetivos definidos fueron logrados haciendo lo que se definió hacer. Esto permite
realizar mediciones y registrarlas como datos históricos para utilizarlos como elementos
comparativos cuando se requiera realizar nuevas mejoras. Esto es muy relevante, porque cuando
la organización ha definido metas, la información que se registre permitirá evaluar si se alcanzó lo
esperado. En un caso exitoso, conduce al fortalecimiento de lo realizado, sin embargo, si al realizar
la interpretación de estas mediciones se observan desviaciones respecto a lo esperado, entonces
proveen el antecedente requerido para reformular y replantear las metas del proceso. Finalmente,
indistintamente del resultado, será necesario evaluar también en qué grado de importancia
contribuyó o no la infraestructura, herramientas de software, plantillas o artefactos de trabajo,
capacitaciones y otros en el resultado final obtenido.

Entonces, luego del aprendizaje, la organización queda empoderada y con las herramientas
suficientes para pensar en un nuevo proyecto de mejoramiento de los procesos.

9
ESTE DOCUMENTO CONTIENE LA SEMANA 6
 2. EL PROCESO DE DESARROLLO DE SOFTWARE PERSONAL
(PSP)
Siempre en el contexto de introducir mejoras en los procesos de desarrollo de software que son
ejecutados en las organizaciones, se puede utilizar esta variante que basa sus métodos en el
modelo CMM1. Lo anterior, dado que facilita la aplicación de procesos de evaluación y mejora,
permitiendo implementar las prácticas de ingeniería de software, definidas en este modelo, pero a
nivel individual. Como por ejemplo, la planificación y seguimiento de proyectos, las revisiones e
inspecciones, el proceso de ingeniería del producto, el enfoque y medición cuantitativa del
proceso, la prevención de defectos, la evaluación de calidad, entre otros.

Cabe destacar el enfoque de cada modelo; por una parte CMM se enfoca en la mejora de las
capacidades de la organización y PSP lo hace en la mejora de los ingenieros de software, aplicando
el control y gestión de los procesos a nivel individual. De acuerdo a lo anterior, los ingenieros de
software desarrollan su trabajo sobre la base de un trabajo ordenado y disciplinado, siguen un
proceso definido y planificado, evaluando y midiendo, efectuando seguimiento de su trabajo,
gestionando la calidad del producto y aplicando la realimentación propia para mejorar sus
procesos.

2.1. OBJETIVOS
De acuerdo a las definiciones dadas por Pomeroy-Huff, Cannon, Chick, Mullaney y Nichols (2009),
se establecen los siguientes objetivos:

 Proporcionar principios al ingeniero de software para llevar un proceso personal

disciplinado

 Asistir a los ingenieros en la realización de planes precisos

 Definir las acciones que deben seguir los ingenieros para desarrollar productos de calidad

 Proporcionar fuentes de información (datos históricos que se van registrando) para ir

midiendo la mejora a nivel personal

 Determinar el impacto que produce la mejora del proceso en el rendimiento individual

Toda esta información aporta a la generación de nuevas líneas bases2, las cuales permiten medir
resultados y planificar nuevas mejoras.

1
Capability Maturity Model. Carnegie Melon University, Software Engineering Institute.
2
La línea base corresponde a un punto de referencia que agrupa una serie de conceptos de mejora.
Posteriormente, las comparaciones de los resultados se realizan en función de esta.

10
ESTE DOCUMENTO CONTIENE LA SEMANA 6
 2.2. MODELO COMO TÉCNICA PARA LA OBTENCIÓN DE DATOS

2.2.1. LÍNEA BASE DEL PROCESO PERSONAL (PSP0, PSP1)

Se establece una introducción a PSP y la línea base inicial. Esto es, información recopilada de otros
proyectos, referente a tamaño del software, tiempo empleado en su desarrollo y estadísticas de
errores encontrados. Son las tres medidas que se controlan a partir de la línea base. Los
ingenieros, en este nivel, pueden seguir utilizando sus métodos de trabajo pero siguiendo al
menos los siguientes pasos que establece el modelo.

Paso Fase Descripción

1 Planificar Planificar el trabajo y documentar el plan

2 Diseñar Diseñar el programa

3 Codificar Implementar el diseño

4 Compilar Compilar el programa y corregir los errores previamente registrados

5 Probar Realización de pruebas programa y corregir los errores previamente

registrados

6 Post mortem Registrar tiempos reales de tamaño (del producto de software), tiempos
empleados y defectos de la planificación.

Tabla 1: Pasos línea base del proceso personal

Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

2.2.2. GESTIÓN PERSONAL DEL PROYECTO (PSP1, PSP1.1)

Centrado en técnicas de gestión de proyectos a nivel individual, se incorporan métodos para la

estimación del esfuerzo, planificación y seguimiento de las actividades. El modelo utilizado para la
estimación del esfuerzo corresponde PROBE3 (Proxy – Base Estimating), con el cual los ingenieros
usan el tamaño relativo de otros desarrollos realizados anteriormente como referencia para
realizar sus estimaciones. En términos más simples, el método requiere que cada proyecto haya
quedado documentado y actualizado con los datos reales al ser finalizado. Por ejemplo, una
planilla Excel con las estimaciones y duraciones reales para cada actividad realizada en el
desarrollo y las diferentes fases de este. La determinación de estimaciones permitirá, a su vez,

3
Watts S. Humphrey, describe un proceso de estimación basada en datos históricos de la organización,
como parte de su proceso de software personal (PSP).

11
ESTE DOCUMENTO CONTIENE LA SEMANA 6
planificar el nuevo desarrollo y, consecuentemente, realizar las actividades de control y
seguimiento para medir el avance respecto al plan.

Figura 2: Cuadro de funcionalidad

Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

En la figura 2 se muestra un ejemplo de tres funciones que debe considerar una solución de
software. De acuerdo a lo que establece el modelo PROBE, el ingeniero recopilará antecedentes
históricos de este tipo de desarrollos. Al hacerlo, encontrará lo siguiente:

Figura 3: Antecedentes desarrollos similares

Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

Es decir, para implementar el “ingreso solicitud de crédito”, requiere tres componentes de

software: dos de lógica de negocio y un procedimiento almacenado. Por tanto, en la solución que
busca implementar, al menos deberá utilizar tal distribución. Por tanto, el cuadro de funcionalidad
quedará de la siguiente forma:

12
ESTE DOCUMENTO CONTIENE LA SEMANA 6
 Tabla 2: Cálculo de componentes funcionales
Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

En este caso, el ingeniero deberá estimar un total de 13 componentes funcionales en su

desarrollo. Y en cada caso, consultar las duraciones reales en el proceso de desarrollo de cada una
de ellas.

2.2.3. GESTIÓN PERSONAL DE LA CALIDAD (PSP2, PSP2.1)

Se incorporan métodos de revisiones personales respecto al diseño y codificación del software,
notaciones específicas para el diseño, plantillas, técnicas de verificación y métricas para gestionar
la calidad del proceso y producto. El enfoque se centra en la identificación y corrección de todos
los errores antes de realizar la compilación. Resulta útil en este caso crear una métrica de calidad
del trabajo, que muestre la cantidad de errores detectados versus los corregidos. Las revisiones,
cabe destacar, son realizadas por el mismo ingeniero sobre su trabajo y estas revisiones deben ser
bien definidas, estructuradas y deben hacerse sobre la base comparativa de datos históricos.

Formulario de registro de errores

Fecha N° Tipo Introducido en Eliminado en Tiempo de corrección (Horas)

18-08-2015 1 20 Código fuente Compilaciones 8

previas

Descripción Errores de sintaxis en función “Buscar cliente”

25-08-2015 2 30 Interfase Compilaciones 10

previas

Descripción Servicio web con errores de mensajes al responder un requerimiento

Tabla 3: Formulario de registro de errores

Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

En la tabla 3 se muestra un ejemplo de registro de detección y corrección de errores.

13
ESTE DOCUMENTO CONTIENE LA SEMANA 6
 2.2.4. PROCESO PERSONAL CÍCLICO (PSP3)

Como evolución natural en todo orden de mejoras, este proceso facilita el escalamiento a
proyectos de mayor envergadura, cuyo tamaño requiere un despliegue mayor de recursos y
actores para su materialización, sin dejar en un segundo plano aspectos de calidad y
productividad. Es por esta razón que los ingenieros entrenados en este modelo serán capaces de
reconocer distintos tipos de tamaño en los proyectos, utilizando las mejores prácticas y
aplicándolas de igual manera en cada caso. Por tanto, calidad y productividad no se sacrifican.

La productividad podemos entenderla como la cantidad de “producto de software” realizada en

una determinada medida de tiempo, o bien, respecto a una serie de recursos empleados para
producirla. En ambos casos, hay un valor máximo de productividad que se puede obtener. Más allá
de ese valor máximo, el trabajo no será productivo. Por ejemplo, dos ingenieros pueden ejecutar
un proyecto pequeño cuyo esfuerzo está dado por 360 horas/persona, tomando su ejecución una
duración de un mes. Es decir, 180 horas/persona cada uno.

Situación: Se dispone de cinco ingenieros para desarrollar el mismo proyecto

Pregunta: ¿cuánto tiempo tardarían?

Respuesta: tal vez, lo que se podría inferir es que lo realizarían en 72 horas (360 horas/persona
dividido por 5 ingenieros). ¿Es sensato pensar algo así?

En este caso, el aumentar la cantidad de “mano de obra” no necesariamente aumenta la

productividad. Es por esta razón que los ingenieros deben conocer el tamaño del proyecto de
desarrollo de software y luego realizar sus estimaciones de plazo conforme a un plan de desarrollo
calendarizado y con responsables bien definidos.

3. PROCESO DE SOFTWARE PARA EQUIPOS (TSP)

3.1. OBJETIVOS
De acuerdo a lo señalado por Roger S. Pressman (2010), se destacan los siguientes objetivos:

 Formar equipos capaces de hacer seguimiento a su trabajo, estableciendo metas,

empoderados de sus planes y procesos.

 Mostrar a los gerentes la forma de liderar sus equipos, asegurando su rendimiento

máximo.

 Acelerar el proceso de mejora del software.

14
ESTE DOCUMENTO CONTIENE LA SEMANA 6
 3.2. MODELO CONSTRUCCIÓN DE EQUIPOS DE TRABAJO EFICACES
El proceso de software para equipos tiene por objeto ayudar a constituir equipos para el
desarrollo de software de calidad. El marco de trabajo que propone está basado en el proceso de
desarrollo de software personal (PSP), con fases de desarrollo definidas y en las cuales los
productos de software se van generando en ciclos de iteración.

Por lo anterior, una de las características que propone este modelo es la objetividad y disciplina en
el trabajo en equipo. Por tanto, se establecen medidas de calidad del producto y la productividad.
De esta forma, se recogen las prácticas definidas en PSP y se complementa con la gestión de
equipos de trabajo.

Los lineamientos de TSP para los ingenieros de software están dirigidos a crear mejores equipos de
desarrollo, guiándolos en el aprendizaje y corrección de sus problemas. Así, el equipo se fortalece
y administra de mejor forma su trabajo, siempre sobre la base de los cuatro procesos básicos
definidos en el desarrollo de software (óp. cit.):

 Análisis

 Diseño

 Programación

 Prueba

El trabajo en equipo se propone sobre la base de los siguientes pilares:

 Formación del equipo de trabajo

 Gestión del equipo de trabajo

Estos pilares, a su vez, ayudan a los ingenieros a planificar su trabajo. Lo cual ciertamente resulta
beneficioso para el equipo y la organización, debido a que administran en forma eficiente la carga
de trabajo asignada. El efecto directo de lo anterior se manifiesta en la duración de los proyectos,
los cuales tienden a desarrollarse dentro de los plazos definidos y comprometidos con el cliente.

Al ser conocida la planificación al interior del equipo y estando también validada por todos —
incluyendo a los desarrolladores—, se fortalece el compromiso por parte de ellos con el proyecto y
en el desarrollo de una solución de calidad, lo cual maximiza la productividad del equipo.

A continuación, se desarrolla una descripción de cada una de las fases del ciclo de vida de TSP
(Piattini, 2012), el cual está representado como se muestra en la figura 4.

15
ESTE DOCUMENTO CONTIENE LA SEMANA 6
 Figura 4: Fases del ciclo de vida de TSP
Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

3.2.1. LANZAMIENTO

Se establecen los objetivos del proyecto y el equipo de trabajo para desarrollarlo. Dado que cada
integrante del equipo realizará funciones específicas, es necesario definir los roles y
responsabilidades respecto al desarrollo de cada una de las actividades. Esta definición inicial del
equipo no necesariamente es fija en el tiempo. Ya que una de las principales tareas del líder es
precisamente obtener el mayor provecho de cada una de las capacidades y competencias de cada
uno de los integrantes. Por tal razón y en beneficio del crecimiento y aprendizaje de los miembros
del grupo, se podrá ir rotando las funciones y responsabilidades. Pero siempre en función de darle
el mayor beneficio al cliente, a través de un producto de software de calidad.

3.2.2. ESTRATEGIA

Sobre la base de un diseño conceptual del producto, se establecerá la estrategia de desarrollo. De

esta forma, se determina el alcance en cada uno de los ciclos, de forma que al cabo de un par de
iteraciones se logre implementar toda la funcionalidad que la solución requiere. En esta fase, se
determina el tamaño y esfuerzo requerido respecto al producto que será desarrollado y, sobre
esta estimación, se elaborará la planificación y distribución de tareas.

3.2.3. PLANEACIÓN

16
ESTE DOCUMENTO CONTIENE LA SEMANA 6
La planificación es la herramienta que permite medir avances concretos en el desarrollo de un
producto de software. Es también el “termómetro” con el cual el cliente mide los avances del
producto que espera y, asimismo, para la organización, el plan en el cual se invierten recursos para
desarrollar una solución de calidad y ajustada a los plazos comprometidos. Por esta razón, se debe
realizar una buena estimación de los distintos componentes que conforman la solución, las tareas
que se requiere realizar y el plan de calidad que contiene los parámetros que se evaluarán.

3.2.4. REQUERIMIENTOS

La ingeniería de requerimientos es uno de los factores más importantes y determinantes a la hora

de medir el éxito de un proyecto. Por tanto, es una de las etapas del proyecto en la que se debe
invertir bastante esfuerzo para dejar establecido en forma clara el alcance y definición de la
solución. En esta fase no se puede dar cabida a ambigüedades, definiciones inconclusas y, sobre
todo, no puede implementarse una solución sin tener la aprobación funcional del usuario. Es decir,
antes de implementar una línea de código, la definición funcional debe estar acordada y validada
por todos quienes participan en el proyecto, en especial, el usuario.

3.2.5. DISEÑO

En esta fase del ciclo, se debe elaborar la especificación funcional y técnica de la solución, se
determinan los estándares de diseño, se desarrolla el plan de pruebas unitarias e integradas y se
definen los roles que funcionalmente soportará la solución.

3.2.6. IMPLEMENTACIÓN

En esta fase del ciclo, se implementa la solución (programación), se realizan las compilaciones y
pruebas unitarias. Tareas que desarrolla el equipo del proyecto, compuesto por los ingenieros de
softwares responsables del desarrollo.

3.2.7. PRUEBAS

Comienza el ciclo de iteraciones de pruebas y correcciones, con la participación del usuario, quien
finalmente aprobará la solución (caso ideal). Es común que surjan modificaciones a los
requerimientos previamente definidos, por lo cual es importante la formalidad y acuerdo entre las
partes. En este caso, lo importante es que sea controlado y acordado, para no salir del alcance
inicial. Al no hacerlo de esta forma, lo más probable es que se puedan generar desviaciones que
lleven a redoblar esfuerzos y aumentar los costos de la solución.

3.2.8. POST MORTEM

17
ESTE DOCUMENTO CONTIENE LA SEMANA 6
Como parte del aprendizaje, se evalúa el proyecto respecto a los indicadores de plazo, calidad,
cumplimiento de expectativas, funcionamiento del equipo, riesgos presentados y las formas como
se manejaron. Esta información es relevante para el desarrollo de proyectos futuros. Pasa a formar
parte de la base de información que va a requerir la organización para futuros proyectos de
mejora. Finalmente, con los antecedentes recopilados se hace una presentación del proyecto a los
interesados y se realiza el acta de cierre.

3.3. INTEGRACIÓN DE PSP - TSP

En la figura 5 se muestra un resumen de las características individuales de cada modelo. Tal como
se mencionó inicialmente, TSP es un complemento para PSP y se enfoca en mejorar la gestión y
administración de equipos de proyectos para el desarrollo de soluciones de software.

Figura 5: Cuadro comparativo TSP – PSP

Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

18
ESTE DOCUMENTO CONTIENE LA SEMANA 6
COMENTARIO FINAL

La utilización de los modelos orientados a mejorar los procesos de desarrollo de software, vistos
en el contenido de esta semana, son herramientas que facilitan el desarrollo de productos de
calidad y reducen los costos asociados a la corrección de errores, puesto que permiten realizar una
detección temprana, reduciendo así los tiempos y recursos invertidos en ello.

La incorporación metodológica de estos modelos en las organizaciones se debe adecuar a las

necesidades de negocio y la estrategia que se defina para implementarlos. Se debe considerar que
las organizaciones tienen realidades distintas y obedecen también a las necesidades que las
exigencias del negocio determinan.

19
ESTE DOCUMENTO CONTIENE LA SEMANA 6
REFERENCIAS

Piattini, M.; García, F.; García, I. y Pino, F. (2012). Calidad de sistemas de información. México:

Alfaomega Grupo Editor. Madrid: Ra-Ma.

Pantaleo, G. (2011). Calidad en el desarrollo de software. México: Alfaomega Grupo Editor.

Software Engineering Institute (2009). The IDEAL Model. Recuperado de: http://goo.gl/hteZEp

Pomeroy-Huff, M.; Cannon, R.; Chick, T.; Mullaney, J. y Nichols, W. (2009). The Personal Software

Process (PSP) Body of Knowledge, Version 2.0. Software Engineering Institute. Carnegie

Mellon University. Recuperado de: http://resources.sei.cmu.edu/library/asset-

view.cfm?assetid=8907

Pressman, R. (2010). Ingeniería de software, un enfoque práctico. 7.ª edición. España: Editorial

McGraw-Hill Interamericana S. A.

PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:

IACC (2016). Estándares de calidad aplicados al software. Modelos y Control de Calidad.

Semana 6.

20
ESTE DOCUMENTO CONTIENE LA SEMANA 6
 21
ESTE DOCUMENTO CONTIENE LA SEMANA 6