Tecnológico Nacional De

México
Instituto Tecnológico de Acapulco

Carrera: Ingeniería en Sistemas Computacionales

Materia: Gestión de Proyectos de Software

Profesora: Dra. Carolina Astudillo Hernández

Tema 3: Planificación del Proyecto

Integrantes de equipo:
Flores Carmona Diana Arlett (15321057)
Morales Flores Jose Manuel (15321136)
Valenzuela Barrientos Carlos Jair (15321214)

Horario: 08:00 – 09:00

Ciclo Escolar: Agosto – Diciembre 2018

Índice
Introducción ......................................................................................................................... 1
3.1.- Objetivo del proyecto. .................................................................................................. 1
3.2.- Estimaciones de tiempo. ............................................................................................. 6
3.3.- Estimaciones de costos. .............................................................................................. 8
3.4.- Estimación de personal requerido. ............................................................................ 13
3.5.- Análisis de riesgos. ................................................................................................... 15
3.5.1.- Tipos de riesgos. ................................................................................................. 15
3.5.2.- Identificación, impacto y proyección del riesgo. .................................................. 16
3.5.3.- Evaluación del riesgo. ......................................................................................... 17
3.5.4.- Estrategias frente al riesgo.................................................................................. 17
3.6.- Análisis de la viabilidad del proyecto. ........................................................................ 18
Conclusiones ..................................................................................................................... 38
Bibliografía......................................................................................................................... 40
Introducción
Una de las labores más difíciles en la administración de proyectos de software es la de la
planificación de proyectos. Como administrador, uno debe dividir el trabajo en partes iguales
y asignar dichas tareas a cada uno de los integrantes del equipo de trabajo, se deben
anticipar ante problemáticas y preparar posibles soluciones ante estas. La planeación (que
debió ser creada desde un inicio) se usa para comunicar al equipo de trabajo y a los clientes
cómo es que se realizará el trabajo y para ayudar a evaluar el avance de este.
La planeación se presenta durante tres etapas en un ciclo de vida del proyecto:

 En la etapa de propuestas: Cuando se presenta una licitación con vistas a obtener

un contrato para desarrollar o proporcionar un sistema de software. En esta etapa
es necesario un plan para ayudarle a decidir si cuenta con los recursos para
completar el trabajo y a calcular el precio que debe cotizar al cliente.
 Durante la fase de inicio: Cuando debe determinar quién trabajará en el proyecto,
cómo se dividirá el proyecto en incrementos, cómo se asignarán los recursos a través
de su compañía, etcétera. Aquí, se cuenta con más información que en la etapa de
la propuesta y, por lo tanto, se pueden afinar las estimaciones iniciales.
 A lo largo del proyecto: Cuando el plan se modifica a la luz de la experiencia
obtenida y la información del monitoreo del avance del trabajo. Se aprende más
acerca del sistema a implementar y de las capacidades del equipo de desarrollo.

La falta de planificación es la causa principal del deslizamiento de la programación, el

exceso de costos, la mala calidad y los altos costos de mantenimiento del software. Se
requiere una planificación cuidadosa tanto del proceso de desarrollo como de los productos
de trabajo para evitar estos problemas. A menudo se dice que la planificación temprana es
imposible porque la información precisa sobre los objetivos de los proyectos, las
necesidades de los clientes y las limitaciones de los productos no está disponible al
comienzo de un proyecto de software, pero un objetivo importante de la fase de planificación
es cumplir los objetivos, necesidades y limitaciones. La dificultad de la planificación no debe
desalentar esta actividad tan importante.
Un producto de software se entiende mejor a medida que avanza a través del análisis,
diseño e implementación; sin embargo, un proyecto de software no debe ser comisionado
hasta que haya suficiente información disponible para permitir una planificación preliminar.
Debe reconocerse que los planes preliminares se modificarán a medida que evolucionen
los productos de trabajo; La planificación de cargos es uno de los aspectos clave de la
planificación exitosa.

3.1.- Objetivo del proyecto.

Cada entidad hecha por el hombre es primero un concepto en la mente de alguien. Los
sistemas de computación, al igual que otros productos de tecnología, se desarrollan en
respuesta a las necesidades percibidas. Las fuentes de ideas de productos de software

pág. 1
incluyen los requisitos del cliente generados externamente, los requisitos organizativos
internos, los planes de marcado y los planes de misión de la organización. La mayoría de
las organizaciones de desarrollo de software son muy selectivas al decidir qué productos
desarrollar; No todos los objetivos de oportunidad son explotados. La decisión de proceder
se basa generalmente en el resultado de un estudio de viabilidad.

El primer paso para planificar un software es preparar, en la terminología del cliente, una
declaración concisa del problema a resolver y las restricciones que existen para su solución.
La declaración del problema definitivo debe incluir una descripción de la situación actual y
los objetivos que debe alcanzar el nuevo sistema.

Tenga en cuenta que el problema del cliente, desde el punto de vista del cliente, es quizás
un problema de nómina, un problema de inventario. o un problema de control de tráfico
aéreo, y no un problema de canales DMA (Direct Memory Access o Acceso Directo a
Memoria), algoritmos de clasificación o bases de datos relacionales.
La definición del problema requiere una comprensión profunda del dominio del problema y
del entorno del problema. Las técnicas para obtener este conocimiento incluyen entrevistas
con los clientes, observación de tareas problemáticas y el desempeño real de las tareas por
parte del planificador. El planificador debe ser altamente experto en las técnicas de
definición de problemas, ya que los diferentes representantes de los clientes pueden no
estar familiarizados con las capacidades que puede ofrecer una computadora en su
situación, y los representantes más pequeños rara vez son capaces de formular sus
problemas de una manera que resulte lógica.

A veces, los sistemas informáticos se crean para remediar un síntoma en lugar de la causa
raíz de un problema. Esto ocurre cuando se comprende el verdadero problema, pero no se
puede resolver debido a circunstancias económicas, políticas o sociales, o cuando el cliente
no puede comunicar el verdadero problema, o cuando el planificador no entiende la
explicación del problema del cliente.

El segundo paso en la planificación de un software es determinar la idoneidad de una

solución computarizada, además de ser rentable, una solución computarizada. Además de
ser rentable, un nuevo producto de software debe proporcionar los mismos servicios e
información que el sistema anterior usando menos tiempo y personal, o debe proporcionar
servicios e información que no eran prácticos sin el nuevo sistema, un sistema que desplaza
a numerosos trabajadores puede ser económica y técnicamente viable, pero puede no ser
social o políticamente aceptable para el cliente.

Habiendo determinado, al menos de manera preliminar, que una solución computarizada

para el problema es apropiada, la atención se centra en los roles que deben desempeñar
los principales subsistemas del sistema informático. Un sistema de cómputo es una lista de
subsistemas de personas, subsistemas de hardware y subsistemas de software más las
interconexiones entre subsistemas. Los subsistemas de personas incluyen operadores,
personal de mantenimiento y usuarios finales. Los subsistemas de hardware incluyen el
pág. 2
hardware de computación y los dispositivos periféricos, y pueden incluir otros dispositivos
como sensores de control de procesos y actuadores o radares y antenas de seguimiento.
Los subsistemas de software incluyen el software que se desarrollará más el software
existente que se puede usar "tal cual" o en versión modificada.

Se deben identificar las funciones que debe realizar cada subsistema principal, se debe
establecer la interacción entre los subsistemas y se deben determinar las limitaciones
operativas y de desarrollo para cada subsistema principal. Las restricciones especifican
números y tipos de equipos, números y niveles de habilidades del personal, y
características del software tales como rendimiento, precisión y nivel de confiabilidad. La
asignación precisa de funciones entre hardware, software y personas puede ser un análisis
detallado. Sin embargo, debe intentarse la definición preliminar de las funciones principales
del subsistema.

Dada una declaración concisa del problema y una indicación de las restricciones que
existen para su solución, se pueden formular objetivos preliminares y requisitos. Las metas
son objetivos para el logro y sirven para establecer el marco para un proyecto de desarrollo
de software. Los objetivos se aplican tanto al proceso de desarrollo como a los productos
de trabajo, y los objetivos pueden ser cualitativos o cuantitativos:

Algunos objetivos se aplican a cada proyecto y cada producto. Por ejemplo, cada producto
de software debe ser útil, confiable, comprensible y rentable. Cada proceso de desarrollo
debe entregar los productos de trabajo a tiempo y dentro de las estimaciones de costos, y
debe proporcionar al personal con oportunidad de aprender nuevas habilidades. Otros
objetivos, como la facilidad de transporte, la entrega temprana de las capacidades de los
subconjuntos y la facilidad de uso por parte de los no programadores, dependen de la
situación particular.

Los requisitos especifican las capacidades que un sistema debe proporcionar para resolver
un problema. Los requisitos incluyen requisitos funcionales, requisitos de rendimiento y
requisitos para el hardware, firmware, software e interfaces de usuario. Los requisitos
también pueden especificar estándares de desarrollo y estándares de garantía de calidad
tanto para el proyecto como para el producto. Los requisitos deben ser cuantificados
siempre que sea posible.

Los requisitos cuantificados pueden utilizarse como base para las pruebas de aceptación
del sistema entregado. Los requisitos cualitativos a menudo carecen de significado y
pueden dar lugar a malentendidos y desacuerdos entre los desarrolladores y los clientes.

Es difícil cuantificar los requisitos en la fase de planificación porque, por lo general, no está
claro qué se necesita para resolver el problema o qué se puede lograr dentro de las
restricciones de la solución. Sin embargo, se debe hacer todo lo posible para formular
requisitos significativos y para establecer los métodos que se utilizarán para verificar cada
requisito.

pág. 3
Los objetivos y requisitos de alto nivel a menudo se pueden expresar en términos de
atributos de calidad que el sistema debe poseer. Estos atributos de calidad de alto nivel
pueden a su vez expresarse en términos de atributos que pueden integrarse en los
productos de trabajo. Por ejemplo, la confiabilidad se puede expresar en términos de
precisión, robustez, integridad y consistencia del código fuente. Cada uno de estos términos
se puede definir cuidadosamente en términos de atributos más específicos del código
fuente. Por ejemplo, la precisión se puede definir como la medida en que los resultados
producidos por el código son lo suficientemente precisos para satisfacer su uso previsto.
Esto puede traducirse en requisitos específicos para cualquier problema particular.

Es importante que se establezcan criterios de aceptación de alto nivel para el sistema

durante la fase de planificación. La falta de criterios de aceptación cuantificados y
claramente establecidos puede llevar a un malentendido grave entre el cliente y el
desarrollador. Los criterios de aceptación deben iniciarse en términos que puedan
verificarse mediante métodos bien definidos, como la inspección, el análisis o la prueba que
se realizará en los productos de trabajo resultantes.
Los planes describen los mecanismos que se utilizarán para alcanzar los objetivos y los
requisitos. Por ejemplo, el objetivo de entregar productos de trabajo a tiempo se puede
expresar en términos de alcanzar cada hito del proyecto a tiempo. Un ciclo de vida de
producto de software de hito; los ejemplos de hitos incluyen la finalización del análisis de
requisitos, la finalización del diseño y la integración y prueba exitosa de todos los
componentes del sistema.

Para poder planificar para alcanzar cada hito en la fecha prevista, se deben responder
preguntas como las siguientes:

 ¿Cuántos hitos son apropiados?

 ¿Cuándo ocurren?
 ¿Qué recursos se requieren para alcanzar cada hito?
 ¿Quién será responsable de lograr los hitos?
 ¿Qué debe ser cierto para permitir el logro de cada hito?
 ¿Exactamente qué constituirá el logro de cada hito?
La consideración de estas preguntas conducirá a temas como los modelos de ciclo de vida,
las estimaciones de costos y los niveles de personal del proyecto.

Los objetivos expresan los fines o los propósitos que se esperan alcanzar con el estudio
del problema planteado. Por tal razón, se dice que los objetivos constituyen la finalidad de
la investigación. Estos deben responder a la pregunta: ¿qué se pretende alcanzar con la
investigación?

Los objetivos son las guías de estudio durante el proceso de la investigación, son la razón
de ser y hacer en la misma y deben mostrar una relación clara y consistente con la

pág. 4
descripción del problema, y específicamente con las preguntas, hipótesis o ambas
cuestiones, que se quieren resolver.
Características de los objetivos: deben ser precisos, concisos, medibles y alcanzables.

 Precisos: significa que se deben expresar de forma clara, con lenguaje sencillo,
evitando ambigüedades.
 Concisos: se deben formular de la manera más resumida posible, sin rodeos,
utilizando solo las palabras necesarias.
 Medibles: deben expresarse de modo tal que permitan medir las cualidades o
características que caracterizan el objeto de investigación.
 Alcanzables: deben existir posibilidades reales de lograr los objetivos planteados.

Clasificación de los objetivos: En investigaciones médicas generalmente hacemos uso

de un objetivo general y de objetivos específicos. Se recomienda formular un solo objetivo
general global, coherente con el problema planteado, y varios objetivos específicos que
conducirán a lograr el objetivo general.

 Objetivo general o principal: constituye el propósito central del proyecto. En

esencia abarca todo el problema e informa de conjunto para qué se hace la
investigación.
 Objetivos específicos: son precisiones o pasos ulteriores que hay dar para alcanzar
o consolidar el objetivo general. Poseen un mayor nivel de exactitud y permiten
delimitar los métodos que se emplean para conseguirlo.

Con frecuencia se cometen errores al formular los objetivos, entre los que podemos citar el
confundir los objetivos con el método o incluir un procedimiento como parte de este.

Un proyecto es, ni más ni menos, la búsqueda de una solución inteligente al planteamiento

de un problema tendiente a resolver, entre tantos, una necesidad humana. Cualquiera que
sea la idea que se pretende implementar, la inversión, la metodología o la tecnología por
aplicar, ella conlleva necesariamente la búsqueda de proposiciones coherentes destinadas
a resolver las necesidades de la persona humana.

El proyecto surge como respuesta a una “idea” que busca la solución de un problema
(reemplazo de tecnología obsoleta, abandono de una línea de productos) o la manera de
aprovechar una oportunidad de negocio. Ésta por lo general corresponde a la solución de
un problema de terceros, por ejemplo, la demanda insatisfecha de algún producto, o la
sustitución de importaciones de productos que se encarecen por el flete y los costos de
distribución en el país.

Si se desea evaluar un proyecto de creación de un nuevo negocio, ampliar las instalaciones

de una industria, o reemplazar su tecnología, cubrir un vacío en el mercado, sustituir
importaciones, lanzar un nuevo producto, proveer servicios, crear polos de desarrollo,
aprovechar los recursos naturales, sustituir producción artesanal por fabril o por razones de
Estado y seguridad nacional, entre otros, ese proyecto debe evaluarse en términos de
pág. 5
conveniencia, de manera que se asegure que resolverá una necesidad humana eficiente,
segura y rentablemente. En otras palabras, se pretende dar la mejor solución al “problema
económico” que se ha planteado, y así conseguir que se disponga de los antecedentes y la
información necesarios para asignar racionalmente los recursos escasos a la alternativa de
solución más eficiente y viable frente a una necesidad humana percibida.

El objetivo de la planificación del proyecto de software es proporcionar un marco conceptual

que permita al gerente hacer estimaciones razonables de recursos, costo y calendario.
Además, las estimaciones deben intentar definir los escenarios de mejor caso y peor caso,
de modo que los resultados del proyecto puedan acotarse. Aunque hay un grado inherente
de incertidumbre, el equipo de software se embarca en un plan que se haya establecido
como consecuencia de dichas tareas. Por tanto, el plan debe adaptarse y actualizarse
conforme avanza el proyecto.

3.2.- Estimaciones de tiempo.

La calendarización del proyecto de software es una acción que distribuye el esfuerzo
estimado a través de la duración planificada del proyecto, asignando el esfuerzo a tareas
específicas de ingeniería del software. Sin embargo, es importante observar que el
calendario evoluciona con el tiempo. Durante las primeras etapas de la planificación del
proyecto se desarrolla un calendario macroscópico. Este tipo de calendario identifica las
principales actividades de marco conceptual de proceso y las funciones de producto a las
cuales se aplican. Conforme el proyecto avanza, cada entrada en el calendario
macroscópico se desglosa en un calendario detallado. Aquí, acciones y tareas de software
específicas (requeridas para lograr una actividad) se identifican y calendarizan.

La calendarización para proyectos de ingeniería de software puede verse desde dos

perspectivas más bien diferentes. En la primera, ya se estableció una fecha final (e
irrevocable) para liberar un sistema basado en computadora. La organización de software
se restringe para distribuir el esfuerzo dentro del marco temporal prescrito. La segunda
visión de la calendarización del software supone que se han discutido límites cronológicos
burdos, pero que la fecha final la establece la organización de ingeniería del software. El
esfuerzo se distribuye para hacer mejor uso de los recursos y se define una fecha final
después de un cuidadoso análisis del software. Por desgracia, la primera situación se
encuentra con mucha más frecuencia que la segunda.

La calendarización de un proyecto de software no difiere enormemente de la de cualquier

esfuerzo de ingeniería multitarea. Por tanto, las herramientas y técnicas generalizadas de
calendarización de proyecto pueden aplicarse con pocas modificaciones para proyectos de
software.

Cuando se crea un calendario de proyecto de software, se comienza con un conjunto de

tareas (la estructura de distribución del trabajo). Si se usan herramientas automatizadas, la
distribución del trabajo se ingresa como una red o esbozo de tareas. Luego se ingresan

pág. 6
esfuerzo, duración y fecha de inicio para cada tarea. Además, las tareas pueden asignarse
a individuos específicos.

Como consecuencia de esta entrada se genera un cronograma, también llamado gráfico de

Gantt. Es posible desarrollar un cronograma para todo el proyecto. Alternativamente,
pueden generarse gráficos separados para cada función del proyecto o para cada individuo
que trabaje en el proyecto.

Si se desarrolló de manera adecuada, el calendario del proyecto se convierte en un mapa

de caminos que define las tareas e hitos que se van a monitorear y controlar conforme el
proyecto avance.

El control lo emplea un gerente de proyecto de software para administrar los recursos del
proyecto, enfrentar los problemas y dirigir al personal del proyecto. Si las cosas van bien
(es decir, si el proyecto avanza conforme el calendario y dentro de presupuesto, las
revisiones indican que se realiza progreso real y que se alcanzan los hitos), el control es
ligero. Pero cuando ocurren problemas, debe ejercerse el control para reconciliar los
elementos discordantes tan rápidamente como sea posible. Después de diagnosticar un
problema pueden enfocarse recursos adicionales sobre el área problemática: puede
reasignarse al personal o redefinirse el calendario del proyecto.

Cuando se enfrentan a severa presión debido a la fecha límite, los gerentes experimentados
en ocasiones usan un calendario de proyecto y técnica de control llamado time-boxing
(encuadre temporal). La estrategia time-boxing reconoce que el producto completo no
puede entregarse en la fecha límite preestablecida. Por tanto, se elige un paradigma de
software incremental y se establece un calendario para cada entrega incremental.

Las tareas asociadas con cada incremento se encuadran en el tiempo. Esto significa que el
calendario para cada tarea se ajusta trabajando en reversa desde la fecha de entrega hasta
el momento del incremento. Alrededor de cada tarea se pone un “recuadro”. Cuando una
tarea llega a la frontera de su encuadre temporal (más o menos 10 por ciento), el trabajo
se detiene y comienza la siguiente tarea.

Con frecuencia, la reacción inicial ante el enfoque time-boxing es negativa: “Si el trabajo no
se termina, ¿cómo puedo avanzar?”. La respuesta se encuentra en la forma en la que se
logra el trabajo. Para cuando se llega a la frontera del encuadre temporal, es probable que
90 por ciento de la tarea esté completa. El restante 10 por ciento, aunque importante, puede:

 Demorarse hasta el siguiente incremento.

 Completarse más tarde si se requiere.
En lugar de quedarse “atascado” en una tarea, el proyecto avanza hacia la fecha de entrega.

La calendarización es la culminación de una actividad de planificación que es un

componente principal de la administración de proyectos de software. Cuando se combina

pág. 7
con los métodos de estimación y análisis de riesgos, establece un mapa de caminos para
el gerente del proyecto.

La calendarización comienza con la descomposición del proceso. Las características del

proyecto se usan para adaptar un conjunto de tareas adecuado para el trabajo que se va a
realizar. Una red de tareas muestra cada tarea de ingeniería, su dependencia de otras
tareas y su duración proyectada. La red de tareas se usa para calcular la ruta crítica, un
cronograma y otra información del proyecto. Al usar el calendario como guía, puede
monitorearse y controlar cada paso en el proceso de software.

El esfuerzo total del proyecto es sensible al tiempo del calendario disponible para la
finalización del proyecto. Varios investigadores han estudiado la cuestión del tiempo de
desarrollo óptimo, y la mayoría de ellos coinciden en que los proyectos de software
requieren un esfuerzo más total si el tiempo de desarrollo es comprimido o expandido desde
el momento óptimo.

3.3.- Estimaciones de costos.

La estimación del costo de un software es una de las tareas más difíciles y propensas a
errores en la ingeniería de software. Es difícil hacer un costo exacto durante la fase de
planificación del desarrollo de software debido a la gran cantidad de factores desconocidos
en ese momento, pero las prácticas de contratación a menudo requieren un compromiso
de costo firme como parte del estudio factible. Esto, junto con la naturaleza competitiva del
negocio, es un factor importante que contribuye al coste extenso y a la planificación de los
proyectos de software.

En reconocimiento de este problema, algunas organizaciones utilizan una serie de

estimaciones de costos. Se prepara una estimación preliminar en la revisión de requisitos
del software y la estimación final se presenta en la revisión de diseño preliminar. Cada
estimación es un refinamiento de la anterior, y se basa en la información adicional obtenida
como resultado de actividades de trabajo adicionales. En ocasiones, en la revisión se
presentan varias opciones de productos y costos asociados. Esto permite al cliente elegir
una solución rentable de una gama de soluciones posibles.

Los clientes a veces financian la fase de análisis y el diseño preliminar a veces es otorgado
a múltiples organizaciones de desarrollo de software por parte del cliente, quien luego elige
una organización para desarrollar el producto de software sobre la base de las
competencias de análisis y diseño preliminar.

Hay muchos factores que influyen en el costo de un producto de software. Los efectos de
la mayoría de estos factores, y por lo tanto el costo de un esfuerzo de desarrollo o
mantenimiento, son difíciles de estimar. Los principales factores de costo son las
habilidades individuales del personal del proyecto y su familiaridad con el área de
aplicación; la complejidad del producto; el tamaño del producto; el tiempo disponible el nivel

pág. 8
requerido de confiabilidad; el nivel de tecnología utilizado; y la disponibilidad, la familiaridad
y la estabilidad del sistema utilizado para desarrollar el producto.

Hay tres categorías generalmente reconocidas de productos de software: programas de

aplicaciones, que incluyen procesamiento de datos y programas científicos; programas de
utilidad, como compiladores, editores de vínculos y sistemas de inventario; y programas a
nivel de sistema, como sistemas de administración de base de datos, sistemas operativos
y sistemas en tiempo real. Las aplicaciones se desarrollan en el entorno proporcionado por
un compilador de lenguaje (como Fortran o Pascal). La interacción con el sistema operativo
se limita a las instrucciones de control de trabajo y a las facilidades de soporte de ejecución
proporcionadas por el procesador de lenguaje. Los programas de utilidades están escritos
para proporcionar los entornos de procesamiento de usuarios y hacer un uso sofisticado de
las instalaciones del sistema operativo. Los programas de sistemas interactúan
directamente con el hardware. Normalmente implican el procesamiento simultáneo y las
restricciones de sincronización.

Uno de los errores comunes en la estimación del número de instrucciones de origen en un

producto de software es subestimar la cantidad de código de limpieza requerido. El código
de limpieza es esa porción del código que maneja la entrada/salida, la comunicación de
usuario interactiva, la ingeniería de interfaz humana y la comprobación de errores y el
manejo de errores. El código de limpieza a menudo asciende a más del 50% y a veces
hasta el 90% del código fuente en un producto de software. Normalmente es más fácil
calcular la cantidad de código necesario para manipular datos y realizar cálculos que
estimar la cantidad de código de limpieza. Las estimaciones basadas en el valor anterior
pueden ser erróneas cuando se utilizan para estimar las líneas totales del código fuente.

Dentro de la mayoría de las organizaciones, las estimaciones de costos de software se

basan en el desempeño anterior. Se utilizan datos históricos para identificar los factores de
coste y determinar la importancia relativa de varios factores dentro del entorno de dicha
organización. Esto, por supuesto, significa que los datos de costos y productividad deben
ser recogidos en los proyectos actuales para estimar los futuros.

Las estimaciones de costos pueden ser de “Arriba-Abajo (Top-Down)” o “Abajo-Arriba

(Bottom-Up)”. La estimación Top-Down se centra primero en el costo del nivel del sistema,
como los recursos informáticos y el personal requerido para desarrollar el sistema, así como
el costo de la configuración. Los costes de personal se calculan examinando el coste de
proyectos anteriores similares.

La estimación de costos Bottom-Up primero estima el costo para desarrollar cada módulo
o subsistema. Esos costos se combinan para llegar a una estimación general. La estimacion
de Top-Down tiene la ventaja de enfocarse en el costo del sistema, pero puede pasar por
alto varios factores técnicos en algunos de los módulos que se desarrollarán. La estimación
Botton-Up enfatiza el costo asociado con el desarrollo de componentes individuales del
sistema, pero puede no dar cuenta de los costos de nivel del sistema, como la

pág. 9
administración de configuración y el control de calidad. En la práctica, ambas estimaciones
deben ser desarrolladas, comparadas, e iteradas para eliminar diferencias.

La técnica de estimación de costes más utilizada es el criterio experto (Expert Judgment).

Esta depende de la experiencia, el fondo y el sentido de negocio de una o más personas
clave en la organización.

La mayor ventaja de la opinión experta, es decir, la experiencia, también puede ser una
responsabilidad. El experto puede estar seguro de que el proyecto es similar a uno anterior,
pero puede haber sobrecargado algunos factores que hacen que el nuevo proyecto sea
significativamente diferente. O, el experto que hace la estimación puede no tener
experiencia con un proyecto similar al actual.

Para compensar estos factores, los grupos de expertos a veces preparan un presupuesto
de consenso. Esto tiende a minimizar los descuidos individuales y la falta de familiaridad
con proyectos particulares, y neutraliza los sesgos personales y el deseo (quizás
subconsciente) de ganar el contrato a través de una estimación excesivamente optimista.
La desventaja principal de la estimación del grupo es el efecto que la dinámica interpersonal
del grupo puede tener en los individuos en el grupo. Los miembros del grupo pueden ser
menos que francos debido a las consideraciones políticas, la presencia de figuras de la
autoridad en el grupo, o la dominación de un miembro demasiado asertivo del grupo. La
técnica de Estimación de Costo Delphi se puede utilizar para superar estas desventajas.

La técnica Delphi fue desarrollada por Rand Corporation en 1948 para ganar el consenso
experto sin introducir los efectos secundarios adversos de la reunión del grupo. La técnica
de Delphi se puede adaptar a la estimación del coste de software de la manera siguiente:

 Un coordinador proporciona a cada estimador el documento de "definición del

sistema" y un formulario para registrar una estimación de costos.
 Los estimadores estudian la definición y completan sus estimaciones de forma
anónima. Pueden hacer preguntas al coordinador, pero no discuten sus estimaciones
entre sí.
 El coordinador prepara una distribución de un resumen de las respuestas de los
estimadores, e incluye cualquier nota de racionalidad inusual por los estimadores.
 Las estimaciones completan otra estimación, de nuevo anónimamente, utilizando el
resultado de la estimación anterior. Las estimaciones que difieren
considerablemente del grupo pueden ser formuladas de forma anónima para
justificar sus estimaciones.
 El proceso es iterado por tantas rondas como sea necesario. No se permite ninguna
discusión en grupo durante todo el proceso.

El siguiente enfoque es una variación de la técnica de Delphi estándar que aumenta la

comunicación mientras que preserva el anonimato:

pág. 10
  El coordinador proporciona a cada estimador una "definición del sistema" y un
formulario de estimación.
 Los estimadores estudian la definición, y el coordinador llama a una reunión de grupo
para que los estimadores puedan discutir asuntos con el coordinador uno con el otro.
 Estimaciones completan sus estimaciones anónimamente.
 El coordinador prepara un resumen de las estimaciones, pero no reconoce ningún
fundamento.
 El coordinador convoca a una reunión de grupo para centrarse en cuestiones en las
que las estimaciones varían ampliamente.
 Los estimadores completan otra estimación, de forma anónima. El proceso es iterado
por tantas veces como sea necesario.

Es posible que varias rondas de estimaciones no conduzcan a una estimación de consenso.

En este caso, el coordinador debe discutir los temas relacionados con cada estimador para
determinar las razones de las diferencias. El coordinador puede tener que reunir
información adicional y presentarla a los estimadores para resolver las diferencias en el
punto de vista.

El juicio de expertos y el consenso de grupo son técnicas de estimación del fondo. El

método de estructura de ruptura de trabajo (Work Breakdown Structure, WBS) es una
herramienta de estimación de fondo. Una estructura de ruptura de trabajo es una tabla
jerárquica que explica las partes individuales de un sistema. Un gráfico de WBS puede
indicar que el producto jerarquizara la jerarquía de procesos.

La jerarquía del producto identifica los componentes del producto e indica la manera en que
los componentes están interconectados. Una tabla WBS de procesos jerárquica identifica
las actividades de trabajo y las relaciones entre dichas actividades.

Algunos planificadores utilizan tanto la estructura de desglose del trabajo del producto como
del proceso para la estimación de costos. Las principales ventajas de la técnica WBS se
encuentran en la identificación y la contabilidad de diversos factores de procesos y
productos, y en la explicación explícita de los costos que se incluyen en la estimación.

El juicio de expertos, el consenso de grupo y las estructuras de desglose del trabajo (WBS)
son las técnicas de estimación de costos más utilizadas. Muchas organizaciones utilizan
los tres enfoques y repiten las estimaciones hasta que se hayan resuelto las diferencias.

Los estimadores de costos algorítmicos calculan el costo estimado de un sistema de

software y la suma de los costos de los módulos y subsistemas que conforman el sistema.
Los modelos algorítmicos son, por lo tanto, estimadores Bottom-Up.

El mantenimiento del software normalmente requiere del 40 al 60 por ciento del esfuerzo
total del ciclo de vida dedicado a un producto de software. Las actividades de
mantenimiento incluyen agregar mejoras al producto, adaptar el producto a nuevos
entornos de procesamiento y corregir problemas.

pág. 11
Las mayores preocupaciones sobre el mantenimiento durante la fase de planificación de un
proyecto de software son estimar el número de programadores de mantenimiento que serán
necesarios y especificar las instalaciones necesarias para el mantenimiento.

Un estimador ampliamente utilizado del personal de mantenimiento es el número de líneas

de código fuente que puede mantener un programador individual. El programador de
mantenimiento típico en una instalación de procesamiento de datos de negocios mantiene
32K instrucciones de código fuente. Para software a tiempo real y aeroespacial, los
números en el rango de 8K a 10K son más típicos.

Una estimación de la cantidad de personal de software a tiempo completo que se necesita

para el mantenimiento del software se puede determinar al dividir la cantidad estimada de
instrucciones del código fuente que se mantendrá por la cantidad estimada de instrucciones
que puede mantener un programador de mantenimiento.

Cuando se presenta una licitación para obtener un contrato, hay que calcular el precio que
se propondrá al cliente para el desarrollo del software. Como punto de partida para calcular
este precio, se requiere presentar una estimación de los costos para completar el trabajo
del proyecto. La estimación incluye calcular cuánto esfuerzo se requiere para terminar cada
actividad y, a partir de ello, calcular el costo total de las actividades. Siempre habrá que
calcular los costos del software de manera objetiva, con la finalidad de predecir con
precisión el costo para el desarrollo del software. Una vez que se tiene una estimación
razonable de los probables costos, entonces es posible calcular el precio que se cotizará al
cliente.

Al estimar los costos del esfuerzo de un proyecto de software, no sólo se multiplican los
sueldos del personal involucrado por el tiempo invertido en el proyecto, sino que también
hay que tener en cuenta todos los costos generales de la organización (espacio de oficinas,
administración, etcétera) que deben cubrirse con el ingreso del proyecto. Los costos se
estiman al calcular dichos costos generales y sumar una proporción a los costos de cada
ingeniero que trabaja en un proyecto.

Existen tres principales parámetros que se deben usar al calcular los costos de un proyecto
de desarrollo de software:

 Costos de esfuerzo (los costos de pagar a los ingenieros y administradores de

software);
 Costos de hardware y software, incluido el mantenimiento;
 Costos de viajes y capacitación.
En principio, el precio de un producto de software a un cliente es simplemente el costo del
desarrollo más las ganancias para el diseñador. Sin embargo, en la práctica, la relación
entre el costo del proyecto y el precio cotizado al cliente no es tan simple. Cuando se calcula
un precio, hay que hacer consideraciones más amplias de índole organizacional,
económica, política y empresarial. Debe pensarse en los intereses de la empresa, los

pág. 12
riesgos asociados con el proyecto y el tipo de contrato que se firmará. Esto puede hacer
que el precio se ajuste al alza o baja. Dadas las precisiones organizacionales implicadas,
decidir sobre un precio de proyecto debe ser una actividad grupal que incluya al personal
de marketing y ventas, así como altos ejecutivos y administradores de proyecto.

Como el costo de un proyecto sólo está débilmente relacionado con el precio cotizado a un
cliente, “cotizar para ganar” es una estrategia usada comúnmente. Cotizar para ganar
significa que una compañía tiene alguna idea del precio que el cliente espera pagar y hace
una apuesta por el contrato con base en el precio esperado por el cliente. Esto puede
parecer no ético y poco práctico en los negocios, pero tiene ventajas tanto para el cliente
como para el proveedor del sistema.

Un costo de proyecto se acuerda sobre la base de un borrador de propuesta. Entonces las

negociaciones tienen lugar entre cliente y consumidor para establecer la especificación
detallada del proyecto. A esta especificación la restringe el costo acordado. El comprador y
el vendedor deben convenir cuál es la funcionalidad aceptable del sistema. En muchos
proyectos el factor fijo no está constituido por los requerimientos del proyecto, sino por el
costo. Los requerimientos pueden cambiar para que el costo no se supere.

3.4.- Estimación de personal requerido.

El número de personal requerido a lo largo de un proyecto de desarrollo de software no es
constante. Por lo general, la planificación y el análisis son realizados por un pequeño grupo
de personas, el diseño arquitectónico por un diseño más grande, pero aún pequeño, y
detallado por un mayor número de personas. La implementación y las pruebas del sistema
requieren el mayor número de personas. La fase temprana de mantenimiento puede
requerir personal numeroso, pero el número debe disminuir en poco tiempo. En ausencia
de una mejora importante de la adaptación, el número de personal para el mantenimiento
debe seguir siendo pequeño

Las personas que trabajan en una organización de software son los activos más
importantes. Cuesta mucho dinero reclutar y retener al buen personal, así que depende de
los administradores de software garantizar que la organización obtenga el mejor
aprovechamiento posible por su inversión. En las compañías y economías exitosas, esto se
logra cuando la organización respeta a las personas y les asigna responsabilidades que
reflejan sus habilidades y experiencia.

Es importante que los administradores de proyecto de software comprendan los conflictos

técnicos que influyen en el trabajo del desarrollo de software. Sin embargo, por desgracia,
los buenos ingenieros de software no necesariamente son buenos administradores de
personal. Los ingenieros de software con frecuencia tienen grandes habilidades técnicas,
pero pueden carecer de habilidades más sutiles que les permitan motivar y dirigir a un
equipo de desarrollo de proyecto. Como administrador de proyecto, usted deberá estar al
tanto de los problemas potenciales de administrar personal y debe tratar de desarrollar
habilidades de gestión de recursos humanos.

pág. 13
Existen cuatro factores críticos en la gestión de personal:

 Consistencia: Todas las personas en un equipo de proyecto deben recibir un trato

similar. Nadie espera que todas las distinciones sean idénticas, pero las personas
podrían sentir que sus aportaciones a la organización se menosprecian.
 Respeto: Las personas tienen distintas habilidades y los administradores deben
respetar esas diferencias. Todos los miembros del equipo deben recibir una
oportunidad para aportar. Desde luego, en algunos casos, usted encontrará que las
personas simplemente no se ajustan al equipo y no pueden continuar, pero es
importante no adelantar conclusiones sobre esto en una etapa temprana del
proyecto.
 Inclusión: Las personas contribuyen efectivamente cuando sienten que otros las
escuchan y que sus propuestas se toman en cuenta. Es importante desarrollar un
ambiente laboral donde se consideren todas las visiones, incluso las del personal
más joven.
 Honestidad: Como administrador, siempre debe ser honesto acerca de lo que está
bien y lo que está mal en el equipo. También debe ser honesto respecto a su nivel
de conocimiento técnico y voluntad para comunicar al personal más conocimiento
cuando sea necesario. Si trata de encubrir la ignorancia o los problemas, con el
tiempo, éstos saldrán a la luz y perderá el respeto del grupo.

Como administrador de proyecto, usted necesitará motivar a las personas con quienes
trabaja, de manera que éstas contribuyan con lo mejor de sus habilidades. Motivación
significa organizar el trabajo y el ambiente laboral para alentar a los individuos a
desempeñarse tan efectivamente como sea posible. Si las personas no están motivadas,
no estarán interesadas en la actividad que realizan. Así que trabajarán con lentitud, y será
más probable que cometan errores y que no contribuyan con las metas más amplias del
equipo o la organización.

El planificador comienza por evaluar el ámbito del software y seleccionando las habilidades
requeridas para completar el desarrollo. Se especifican tanto la posición organizacional (por
ejemplo, gerente, ingeniero de software ejecutivo) como la especialidad (por ejemplo,
telecomunicaciones, base de datos, cliente-servidor). Para proyectos relativamente
pequeños (algunos persona-meses), un solo individuo puede realizar todas las tareas de
ingeniería de software y consultar especialistas según lo requiera. Para proyectos más
grandes, el equipo de software puede dispersarse geográficamente a través de algunas
ubicaciones diferentes. Por tanto, se debe especificar la ubicación de cada recurso humano.
El número de personas requeridas para un proyecto de software puede determinarse sólo
después de hacer una estimación del esfuerzo de desarrollo (por ejemplo, persona-meses).

En proyectos muy grandes, las diferencias en la capacidad individual del programador

tenderán a promediar hacia fuera, pero en los proyectos que utilizan cinco o menos
programadores, las diferencias individuales en capacidad pueden ser significativas. Un
proyecto de software grande es obviamente más costoso de desarrollar que uno pequeño.
pág. 14
3.5.- Análisis de riesgos.
El riesgo de un proyecto se define como la variabilidad de los flujos de caja reales respecto
de los estimados. Cuanto más grande sea esta variabilidad, mayor es el riesgo del proyecto.
Así, el riesgo se manifiesta en la variabilidad de los rendimientos del proyecto, puesto que
se calculan sobre la proyección de los flujos de caja.

La incertidumbre caracteriza a una situación donde los posibles resultados de una

estrategia no son conocidos y, en consecuencia, sus probabilidades de ocurrencia no son
cuantificables. La incertidumbre, por tanto, puede ser una característica de información
incompleta, de exceso de datos, o de información inexacta, sesgada o falsa.

Una diferencia estricta entre riesgo e incertidumbre identifica al riesgo como la dispersión
de la distribución de probabilidades del elemento en estudio o los resultados calculados,
mientras que la incertidumbre es el grado de falta de confianza respecto a que la distribución
de probabilidades estimadas sea la correcta.

3.5.1.- Tipos de riesgos.

Los riesgos del proyecto amenazan el plan del proyecto, es decir, si los riesgos del proyecto
se vuelven reales, es probable que el calendario del proyecto se deslice y que los costos
aumenten. Los riesgos del proyecto identifican potenciales problemas de presupuesto,
calendario, personal (tanto técnico como en la organización), recursos, participantes y
requisitos, así como su impacto sobre un proyecto de software.
Los riesgos técnicos amenazan la calidad y temporalidad del software que se va a producir.
Si un riesgo técnico se vuelve una realidad, la implementación puede volverse difícil o
imposible. Los riesgos técnicos identifican potenciales problemas de diseño,
implementación, interfaz, verificación y mantenimiento. Además, la ambigüedad en la
especificación, la incertidumbre técnica, la obsolescencia técnica y la tecnología “de punta”
también son factores de riesgo. Los riesgos técnicos ocurren porque el problema es más
difícil de resolver de lo que se creía.
Los riesgos empresariales amenazan la viabilidad del software que se va a construir y con
frecuencia ponen en peligro el proyecto o el producto. Los candidatos para los cinco
principales riesgos empresariales son:

 Construir un producto o sistema excelente que realmente no se quiere (riesgo de

mercado).
 Construir un producto que ya no encaje en la estrategia empresarial global de la
compañía (riesgo estratégico).
 Construir un producto que el equipo de ventas no sabe cómo vender (riesgo de
ventas).
 Perder el apoyo de los administradores debido a un cambio en el enfoque o en el
personal (riesgo administrativo).
 Perder apoyo presupuestal o de personal (riesgos presupuestales).

pág. 15
Es extremadamente importante observar que la categorización simple de riesgos no
siempre funciona. Algunos de ellos son simplemente impredecibles por adelantado.

3.5.2.- Identificación, impacto y proyección del riesgo.

La identificación de riesgos es un intento sistemático por especificar amenazas al plan del
proyecto (estimaciones, calendario, carga de recursos, etc.). Al identificar los riesgos
conocidos y predecibles, el gerente de proyecto da un primer paso para evitarlos cuando
es posible y para controlarlos cuando es necesario.
Existen 2 tipos de riesgos: Los riesgos genéricos son una amenaza potencial a todo
proyecto de software. Los riesgos específicos del producto pueden identificarse solamente
por quienes tienen clara comprensión de la tecnología, el personal y el entorno específico
del software que se construye. Para identificar los riesgos específicos del producto, examine
el plan del proyecto y el enunciado de ámbito del software, y desarrolle una respuesta a la
siguiente pregunta: ¿qué características especiales de este producto pueden amenazar el
plan del proyecto?

La fuerza aérea estadounidense publicó un escrito que contiene excelentes lineamientos

para la identificación y reducción de los riesgos de software. El enfoque de la fuerza aérea
requiere que el gerente del proyecto identifique los promotores de riesgo que afectan los
componentes de riesgo de software: rendimiento, costo, apoyo y calendario. En el contexto
de este análisis, los componentes de riesgo se definen en la forma siguiente:

 Riesgo de rendimiento: grado de incertidumbre de que el producto satisfará sus

requisitos y se ajustará al uso pretendido.
 Riesgo de costo: grado de incertidumbre de que el presupuesto del proyecto se
mantendrá.
 Riesgo de apoyo: grado de incertidumbre de que el software resultante será fácil
de corregir, adaptar y mejorar.
 Riesgo de calendario: grado de incertidumbre de que el calendario del proyecto se
mantendrá y de que el producto se entregará a tiempo.

El impacto de cada promotor de riesgo sobre el componente de riesgo se divide en una de

cuatro categorías de impacto: despreciable, marginal, crítico o catastrófico.
La proyección del riesgo, también llamada estimación del riesgo, intenta calificar cada
riesgo en dos formas:

 La posibilidad o probabilidad de que el riesgo sea real.

 Las consecuencias de los problemas asociados con el riesgo, en caso de que ocurra.
Usted trabaja junto con otros gerentes y personal técnico para realizar cuatro pasos de
proyección de riesgo:

 Establecer una escala que refleje la probabilidad percibida de un riesgo.

 Delinear las consecuencias del riesgo.
pág. 16
  Estimar el impacto del riesgo sobre el proyecto y el producto.
 Valorar la precisión global de la proyección del riesgo de modo que no habrá malos
entendidos.

La intención de estos pasos es considerar los riesgos de manera que conduzcan a una
priorización. Ningún equipo de software tiene los recursos para abordar todo riesgo posible
con el mismo grado de rigor. Al priorizar los riesgos es posible asignar recursos donde
tendrán más impacto.

3.5.3.- Evaluación del riesgo.

Tres factores afectan las probables consecuencias si ocurre un riesgo: su naturaleza, su
ámbito y su temporización. La naturaleza del riesgo indica los problemas probables si
ocurre. Por ejemplo, una interfaz externa pobremente definida en el hardware cliente (un
riesgo técnico) impedirá el diseño y las pruebas tempranas, y probablemente conducirá más
tarde a problemas de integración de sistema en un proyecto. El ámbito de un riesgo combina
la severidad (¿cuán serio es?) con su distribución global (¿cuánto del proyecto se afectará
o cuántos participantes se dañarán?). Finalmente, la temporización de un riesgo considera
cuándo y por cuánto tiempo se sentirá el impacto. En la mayoría de los casos se quiere que
las “malas noticias” ocurran tan pronto como sea posible, pero en algunos, mientras más
se demoren, mejor.
La exposición al riesgo global, ER, se determina usando la siguiente relación: ER = P x C

Donde P es la probabilidad de ocurrencia para un riesgo y C es el costo para el proyecto si

ocurre el riesgo.

La exposición al riesgo puede calcularse para cada riesgo en la tabla de riesgo, una vez
hecha la estimación del costo del riesgo. La exposición al riesgo total para todos los riesgos
puede proporcionar los medios para ajustar la estimación del costo final para un proyecto.
También puede usarse para predecir el aumento probable en recursos de personal
requeridos en varios puntos durante el calendario del proyecto.

El equipo del proyecto debe revisar la tabla de riesgos a intervalos regulares, reevaluar
cada riesgo para determinar cuándo nuevas circunstancias cambian su probabilidad e
impacto. Como consecuencia de esta actividad, acaso sea necesario agregar nuevos
riesgos a la tabla, eliminar algunos riesgos que ya no son relevantes e incluso cambiar las
posiciones relativas de otros.

3.5.4.- Estrategias frente al riesgo.

Para incluir el efecto del factor riesgo en la evaluación de proyectos de inversión se han
desarrollado diversos métodos o enfoques que no siempre conducen a un resultado
idéntico. La información disponible es, uno de los elementos determinantes en la elección
de uno u otro método.

pág. 17
El criterio subjetivo es uno de los métodos comúnmente utilizados. Se basa en
consideraciones de carácter informal de quien toma la decisión, sin incorporar
específicamente el riesgo del proyecto, salvo en su apreciación personal. Se ha intentado
mejorar este método sugiriendo que se tengan en cuenta la expectativa media y la
desviación estándar del VAN (Valor Absoluto Neto), lo cual, aunque otorga un carácter más
objetivo a la inclusión del riesgo, no logra incorporarlo en toda su magnitud. De igual
manera, el análisis de fluctuaciones de los valores optimistas, más probables y pesimistas
del rendimiento del proyecto, sólo disminuye el grado de subjetividad de la evaluación del
riesgo, sin eliminarla.

Los métodos basados en mediciones estadísticas son quizá los que logran superar de mejor
manera, aunque no definitivamente, el riesgo asociado con cada proyecto. Para ello,
analizan la distribución de probabilidades de los flujos futuros de caja para presentar a quien
tome la decisión de aprobación o rechazo los valores probables de los rendimientos y de la
dispersión de su distribución de probabilidad.

Un método diferente de inclusión del riesgo en la evaluación es el del ajuste a la tasa de

descuento. Con este método, el análisis se efectúa sólo sobre la tasa pertinente de
descuento, sin entrar a ajustar o evaluar los flujos de caja del proyecto.

Frente a las desventajas respecto del método del ajuste a la tasa de descuento y con
similares beneficios de orden práctico, está el método de la equivalencia a certidumbre.
Según este criterio, quien decide está en condiciones de determinar su punto de indiferencia
entre flujos de caja por percibir con certeza y otros, obviamente mayores, sujetos a riesgo.

Otro de los criterios que debe evaluarse es el de los valores esperados. Este método,
conocido comúnmente como análisis del árbol de decisiones, combina las probabilidades
de ocurrencia de los resultados parciales y finales para calcular el valor esperado de su
rendimiento. Aunque no incluye directamente la variabilidad de los flujos de caja del
proyecto, ajusta los flujos al riesgo en función de la asignación de probabilidades.

3.6.- Análisis de la viabilidad del proyecto.

La confiabilidad del software se puede definir como la probabilidad que un programa
Realizará una función requerido bajo condiciones indicadas por un período de tiempo
indicado. La fiabilidad puede expresarse en términos de exactitud, robustez, integridad y
consistencia del código fuente. Las características de la confiabilidad pueden ser
incorporadas en un producto de software, pero hay un coste asociado al aumento del nivel
de esfuerzo de análisis, diseño, implementación, verificación y validación que debe ser
ejercido para asegurar alta confiabilidad.

El nivel de fiabilidad deseado debe establecerse la fase de planificación considerando el

costo de los fallos de software. En algunos casos, la falla del producto puede causar sólo
inconvenientes leves al usuario, mientras que el fracaso de otros productos puede incurrir
en una alta pérdidas financieras o riesgo para la vida humana.

pág. 18
Los objetivos de las actividades de verificación y validación son evaluar y mejorar la calidad
de los productos generados durante el desarrollo y la modificación del software. Los
atributos de calidad de interés incluyen corrección, integridad, consistencia, confiabilidad,
utilidad, facilidad de uso, eficiencia, conformidad con los estándares y rentabilidad general.

Hay dos tipos de verificación: la verificación del ciclo de vida y la verificación formal. La
verificación del ciclo de vida es el proceso de determinar el grado en que los productos de
trabajo de una fase determinada del ciclo de desarrollo cumplen con las especificaciones
establecidas durante las fases anteriores. La verificación formal es una demostración
matemática rigurosa de que el código fuente cumple con sus especificaciones. La validación
es el proceso para determinar el cumplimiento de los requisitos.

 Verificación: "¿Estamos construyendo el producto correctamente?"

 Validación: "¿Estamos construyendo el producto correcto?"
La alta calidad no se puede lograr a través de la prueba del código fuente solo. Aunque un
programa debe estar totalmente libre de errores, rara vez es el caso de productos de
software grandes. Incluso si los errores en el código fuente fueran la única medida de
calidad, las pruebas por sí solas no pueden garantizar la ausencia de errores en un
programa. Una máxima conocida indica que el número de errores que quedan en un
programa es proporcional al número ya descubierto. Esto se debe a que uno tiene más
confianza en los programas sin errores detectados después de las pruebas y menos
confianza en un programa con un largo historial de correcciones. La mejor manera de
minimizar el número de errores en un programa es capturar y eliminar los errores durante
el análisis y el diseño, para que se introduzcan pocos errores en el código fuente. La
validación y la verificación son conceptos generalizados, ni un conjunto de actividades que
se realizan estrictamente después de la implementación.

La verificación y la validación implican la evaluación de los productos de trabajo para

determinar la conformidad con las especificaciones. Las especificaciones incluyen los
requisitos, la documentación de diseño, varias pautas de estilo, estándares de lenguaje de
implementación, estándares de proyecto, estándares de organización y expectativas de los
usuarios, así como las meta-especificaciones de los formatos y las anotaciones utilizadas
en las distintas especificaciones del producto. Los requisitos deben ser examinados para
determinar su conformidad con las necesidades del usuario, las restricciones ambientales
y los estándares de notación. La documentación de diseño debe verificarse con respecto a
los requisitos y las convenciones de notación, y el código fuente debe ser examinado para
determinar su conformidad con los requisitos, la documentación de diseño, las expectativas
del usuario y los diversos estándares de implementación y documentación. Además, los
documentos de respaldo (manual del usuario, plan de prueba, principios de operación, etc.)
deben examinarse para verificar su exactitud, integridad, coherencia y cumplimiento de las
normas.

pág. 19
Los errores se producen cuando cualquier aspecto de un producto de software es
incompleto, incoherente o incorrecto. Tres categorías principales de errores de software
son errores de requisitos, errores de diseño y errores de implementación. Los errores en
los requisitos se deben a una declaración incorrecta de las necesidades del usuario, al no
especificar completamente los requisitos funcionales y de rendimiento, a las inconsistencias
entre los requisitos y a los requisitos inviables.

Los errores de implementación son los errores realizados en la traducción de las

especificaciones de diseño en código fuente. Pueden ocurrir errores de implementación en
las declaraciones de datos, en referencias de datos, en lógica de flujo de control, en
expresiones computacionales, en interfaces de subprogramas y en operaciones de
entrada/salida.
La calidad de los productos de trabajo generados durante el análisis y el diseño puede ser
evaluado y mejorado utilizando procedimientos sistemáticos de aseguramiento de calidad,
por guias e inspecciones, y por controles automatizados para la consistencia y la integridad.
Las técnicas para evaluar y mejorar la calidad del código fuente incluyen procedimientos
sistemáticos de aseguramiento de la calidad, guias e inspecciones análisis estático,
ejecución simbólica, pruebas unitarios y pruebas de integración sistemática. Las técnicas
de verificación formal pueden utilizarse para mostrar, de manera rigurosa, que un programa
fuente cumple con sus requisitos; la verificación formal también puede utilizarse para guiar
la síntesis sistemática de los programas de origen.

El aseguramiento de la calidad es un patrón planificado y sistemático de todas las acciones

necesarias para proporcionar la confianza adecuada de que el artículo o producto cumple
con los requisitos técnicos establecidos. El objetivo del grupo de aseguramiento de calidad
del software es proporcionar la seguridad de que los procedimientos, herramientas y
técnicas utilizadas durante el desarrollo y la modificación del producto son adecuados para
proporcionar el nivel de confianza deseado en los productos de trabajo.

A menudo, el personal de garantía de calidad del software es de actividades de seguridad,

y permite que el personal de garantía de calidad se convierta en su disciplina. En algunas
organizaciones, el personal de calidad funciona en una capacidad de asesoramiento,
mientras que en otros el grupo de garantía de calidad desarrolla activamente estándares,
herramientas y técnicas, y examina todos los productos de trabajo para la conformidad con
las especificaciones.
Preparación de un Plan de Garantía de Calidad del Software para cada proyecto de
software es una responsabilidad primordial del grupo de calidad del software. Los temas de
un Plan de Garantía de la Calidad del Software incluyen:

 Propósito y alcance del plan.

 Documentos referenciados en el plan.
 Estructura organizativa, tareas que deben realizarse y responsabilidades específicas
relacionadas con calidad de producto.
pág. 20
  Documentos que se preparará y verificará la adecuación de la documentación.
 Normas, prácticas y convenciones que se utilizaran.
 Revisiones y auditorías a realizar.
 Un plan de administración de configuración que identifica elementos de producto de
software, controles e implementa cambios, y registros e informes cambiaron el
estado.
 Prácticas y procedimientos a seguir en informes, seguimiento y resolución de
problemas de software.
 Herramientas y técnicas específicas que se utilizará para apoyar las actividades de
garantía de calidad.
 Métodos e instalaciones que se utilizará para mantener y almacenar versiones
controladas de los programas de identificación.
 Métodos e instalaciones que se utilizará para proteger los medios físicos de los
programas informáticos
 Provisiones para garantizar la calidad del software desarrollado por proveedores y
subcontratistas.
 Métodos e instalaciones que se utilizará para recoger, mantener y retener registros
de aseguramiento de calidad.
Otros deberes realizados por personal de garantía de calidad incluyen:

 Desarrollo de políticas, prácticas y procedimientos estándar.

 Desarrollo de herramientas de prueba y otros seguros de calidad.
 Rendimiento de las funciones de aseguramiento de la calidad descritas en el Plan
de Garantía del Software para cada proyecto.
 Rendimiento y documentación de pruebas de aceptación del producto final para
producto de software.

Más específicamente, un grupo de control de calidad del software puede realizar las
siguientes funciones:

 Durante el análisis y el diseño, se prepara un Plan de Verificación y un Plan de

Pruebas de Aceptación. El plan de verificación describe los métodos que se utilizarán
para verificar que los requisitos están satisfechos por los documentos de diseño y
que el código fuente es coherente con las especificaciones de requisitos y la
documentación de diseño, El Plan de Prueba Código Fuente es un componente
importante del Plan de Verificación de Software. El Plan de Prueba de Aceptación
incluye casos de prueba de resultados esperados y capacidades demostradas por
cada caso de prueba. A menudo el personal de garantía de calidad Trabajará con el
cliente para desarrollar un Plan de Prueba única de Aceptación. En otros casos, el
cliente desarrollará un Plan de Prueba de Aceptación independiente del Plan de
Garantía de Calidad. En cualquier caso, un Plan de Prueba de Aceptación debe ser
desarrollado por personal de garantía de calidad.

pág. 21
  Durante la evolución del producto, las Auditorías En Proceso se realizan para
verificar la consistencia y la integridad de los productos de trabajo. Los artículos a
auditar para la consistencia incluyen especificaciones de interfaz para hardware,
software y personas; diseño interno versus especificaciones funcionales; código
fuente versus documentación de diseño; y requerimientos funcionales versus
descripciones de prueba. En la práctica, sólo ciertas porciones críticas del sistema
pueden ser sometidas a auditorías intensivas.
 Antes de la entrega del producto, se realizan una Auditoría Funcional y una Auditoría
Física. La Auditoría Funcional reconfirma que todos los requisitos han sido
cumplidos. La Auditoría Física verifica que el código fuente y todos los documentos
asociados son completos, consistentes internamente, consistentes entre sí, y listos
para la entrega. Un Resumen de Verificación del Software está preparado para
describir los resultados de todas las revisiones, auditorías y pruebas realizadas por
personal de garantía de calidad durante todo el ciclo de desarrollo.

El personal de garantía de calidad a veces se encarga de los arreglos para guias,

inspecciones y revisiones importantes del hito. Además, el personal de garantía de calidad
a menudo realiza el proyecto post mortem, escribe el documento legado del proyecto y
proporciona retención a largo plazo de los registros del proyecto. La organización de
garantía de calidad también puede servir como un punto focal para la recolección, análisis
y tasas de error, otros factores que influyen en la calidad y productividad.

Normalmente, el grupo de control de calidad trabajará con el grupo de desarrollo para

derivar el Plan de Pruebas de Código Fuente. Un plan de prueba para el código fuente
especifica los objetivos de las pruebas (por ejemplo, para lograr un funcionamiento libre de
errores bajo condiciones establecidas durante un período de tiempo indicado), los criterios
de finalización de la prueba (para descubrir y corregir un número predeterminado de
errores, para lograr un porcentaje especificado de cobertura de ruta lógica), el plan de
integración del sistema (estrategia, horario, personas responsables), métodos que se
utilizaran en módulos particulares (guias, inspecciones, análisis estático, pruebas
dinámicas, verificación formal), y determinados resultados de pruebas y resultados
esperados.

Hay cuatro tipos de pruebas que el código fuente debe satisfacer: pruebas de función,
pruebas de rendimiento, pruebas de estrés y pruebas de estructura. Las pruebas de función
y pruebas de rendimiento están basadas en las especificaciones de requisitos; están
diseñadas para demostrar que el sistema satisface sus requerimientos. Por lo tanto, el plan
de prueba puede ser tan bueno como los requisitos, que a su vez deben ser frases en
términos cuantificados y comprobables.

Las pruebas funcionales especifican condiciones de funcionamiento típicas, valores de

entrada típicos y resultados esperados típicos. Las pruebas de función también prueban el
comportamiento sólo dentro, encendido y justo más allá de los límites funcionales. Ejemplos
de pruebas de límites funcionales incluyen la prueba de una rutina de raíz cuadrada real
pág. 22
con números positivos pequeños, cero y números negativos; o probando una rutina de
inversión de matriz en una matriz de uno por uno.

Las pruebas de rendimiento están diseñadas para verificar el tiempo de respuesta bajo
diversas cargas, porcentaje del tiempo de ejecución invertido en varios segmentos del
programa, rendimiento de procesamiento, utilización de memoria primaria y secundaria, y
tasas de tráfico en los canales de datos y enlaces de comunicación.

Las pruebas de estrés están diseñadas para sobrecargar un sistema de varias maneras.
Ejemplos de pruebas de estrés incluyen intentar firmar más que el número máximo de
terminales permitidos, procesar más que el número permitido de identificadores o niveles
estáticos, o desconectar un vínculo de comunicación.

Las pruebas de estructura se refieren a examinar la lógica de proceso interna de un sistema

de software. Las rutinas particulares llamadas y las rutas lógicas recorridos a través de las
rutinas son los objetos de interés. La meta de la prueba de estructura es atravesar un
número especificado de trayectorias a través de cada rutina en el sistema para establecer
la minuciosidad de la prueba.

Un enfoque típico para las pruebas de estructura es aumentar las pruebas funcionales, de
rendimiento y de estrés con casos de prueba adicionales para lograr el nivel deseado de
cobertura de prueba. Por lo tanto, las pruebas de estructura no se pueden diseñar hasta
que el sistema sea implementado y sometido al plan de pruebas predefinido.

Cada caso de prueba en el Plan de Pruebas de Código Fuente deberá proporcionar la

siguiente información:

 Tipo de prueba (función, funcionamiento, estructura).

 Configuración máquina.
 Suposiciones de pruebas.
 Los requisitos que se están probando.
 Estímulos de prueba exactos.
 Resultado esperado.

En algunos casos, el personal de garantía de calidad trabajará con el desarrollo para derivar
el Plan de Pruebas de Código Fuente. En otros casos, el grupo de garantía de calidad sólo
verificará la adecuación del plan de prueba para el código fuente. En cualquier caso, el plan
de prueba es un importante producto de trabajo del proceso de diseño, y como todos los
productos de trabajo, debe ser desarrollado de una manera sistemática y evaluado por el
grupo de garantía de calidad.

Se pueden utilizar guías e inspecciones para examinar sistemáticamente los productos de

trabajo durante todo el ciclo de vida del software. Requisitos, especificaciones de diseño,
planes de prueba, código fuente, principios de operación, manuales del usuario, y
procedimientos de mantenimiento son algunos de los elementos que se pueden examinar
de esta manera. En una sesión de guía, el material que está siendo examinado es
pág. 23
presentado por un revisor y evaluado por un equipo de revisores. El revisor "atraviesa" el
producto de trabajo, y los revisores plantean preguntas sobre temas de preocupación. Una
guía no es una revisión de proyecto, sino que es más bien un examen profundo de los
productos de trabajo seleccionados por individuos calificados para ofrecer opiniones
expertas. Inspecciones difieren de las guías en un equipo de inspectores capacitados,
trabajando a partir de las listas de comprobación de los artículos a examinar, realizar
inspecciones de los productos de trabajo.

Un equipo de guía (walkthrough) por lo general consiste en un revisor y tres a cinco

revisores. En proyectos de uno o dos personas puede no ser rentable para ensamblar un
equipo de revisión; sin embargo, la técnica de guía (walkthrough) puede ser beneficiosa
con solamente uno o dos revisores. En este caso, una guía formaliza el proceso de explicar
tu trabajo a un colega.

Los miembros de un equipo de guía (walkthrough) pueden incluir al líder del proyecto, otros
miembros del equipo del proyecto, un representante del grupo de garantía de calidad, un
escritor técnico, y otro personal técnico que tenga un interés en el proyecto. Los clientes y
los usuarios deben ser incluidos en las guías durante los requisitos y las fases preliminares
de diseño, pero por lo general se excluyen de las siguientes sesiones de guía (walkthrough).
Los administradores de nivel superior no deben asistir a las guías. Las sesiones de
caminatas deben estar en una atmósfera abierta y no defensiva. La presencia de un
vicepresidente o gerente de departamento puede inhibir el proceso de revisión.

El objetivo de una guía es descubrir y hacer notar las áreas problemáticas. Los problemas
no se resuelven durante la sesión de guía. Se resuelven por el revisor después de la sesión
de guía. Se debe utilizar una reunión de seguimiento o memorando de seguimiento para
informar a los revisores de las acciones tomadas. El revisor puede trabajar con uno o más
revisores para resolver problemas, pero es la responsabilidad del revisor asegurar que los
problemas anotados durante la guía estén resueltos.
Se deben observar varias directrices para obtener el máximo beneficio de las guías:

 El trabajo de todos debe ser revisado sobre una base programada. Este enfoque
asegura que todos los productos de trabajo sean revisados, proporcione un vehículo
de comunicación entre los miembros del equipo y disminuya la amenaza a los
revisores individuales. En particular, se debe revisar el trabajo técnico del líder del
proyecto. Una actitud abierta y no defensiva del líder del proyecto puede establecer
un ambiente saludable para las revisiones.
 Se debe poner énfasis en detectar errores. No se debe utilizar una sesión de guía
para corregir errores. El revisor debe tener en cuenta los errores para la resolución
subsecuente. Para este fin, un miembro del equipo de revisión debe ser designado
secretaria de registro para la sesión.
 Deberían abordarse cuestiones importantes. Aunque a veces es difícil distinguir
entre temas importantes y menores, las sesiones de guía no deberían degenerarse

pág. 24
 en discusiones detalladas de problemas menores. Por ejemplo, se podrían abordar
cuestiones importantes de la eficiencia del código, pero deberían evitarse cuestiones
de menor importancia del estilo de codificación. Algunos asuntos se discuten mejor
en privado después del guía. Un revisor debe ser designado como moderador para
mantener una atmósfera positiva y mantener el guía enfocado en asuntos
importantes.
 Las sesiones de guía deben estar limitadas a 2 horas. Un plazo de tiempo definido
asegura que la reunión no se arrastrará durante varias horas. Esto ayuda a limitar el
alcance del material a examinar, refuerza el énfasis en temas importantes, y
proporciona incentivo para la participación activa de los revisores.

El uso satisfactorio de las guías depende fuertemente de establecer una atmósfera positiva
y no amenazante para las sesiones de guía. El líder del proyecto, los programadores senior,
y el moderador de guía deben recibir entrenamiento especial en técnicas de guía y
dinámicas de grupo para asegurar el ajuste psicológico correcto. Otros factores que
contribuyen al éxito de las guías incluyen enfatizar la detección de problemas importantes,
limitar la duración de cada guía y programar las guías para cada miembro del equipo de
forma regular.

El tiempo suficiente para las guías se debe asignar en el horario del proyecto. Sesiones de
guía deben considerarse como parte de la carga de trabajo normal de cada participante, en
lugar de como un compromiso de sobrecarga. El tiempo que se gasta en las guías es
ampliamente pagado por numerosos beneficios: los errores se capturan en el momento más
temprano posible, cuando son más fáciles y menos costosos de arreglar; se mejora la
comunicación del equipo de proyecto; el personal del proyecto aprende nuevas técnicas
unas de otras y el personal nuevo aprende rápidamente los detalles del proyecto; la
motivación es mejorada; los productos de trabajo se ven como documentos públicos; y los
miembros del equipo obtienen una mayor satisfacción del trabajo de su trabajo.
No se deben usar guías como vehículos para la evaluación de los empleados. Durante un
período de tiempo, el líder del proyecto observará fortalezas y debilidades en el miembro
del equipo. En muchos casos, las asignaciones de proyectos pueden ser ajustadas para
aprovechar las habilidades de cada individuo. En algunos casos, los miembros del equipo
aprenderán de sus colegas y superarán las debilidades iniciales. En algunos casos, puede
ser necesario reasignar o despido de personal no apto. En cualquier caso, estas acciones
deben basarse en observaciones de numerosos factores durante un período de tiempo, y
no en el desempeño de una persona en una o dos sesiones de caminata.

Las inspecciones, como las guías, se pueden utilizar a lo largo del ciclo de vida del software
para evaluar y mejorar la calidad de los diversos productos de trabajo. Los equipos de
inspección constan de uno a cuatro miembros capacitados para sus tareas. Los inspectores
trabajan desde las listas de comprobación de los elementos de inspección. Las
inspecciones se realizan de manera similar a los tutoriales, pero se impone más estructura
en las sesiones, y cada participante tiene un papel definido que desempeñar.
pág. 25
El diseño y las inspecciones de código fueron descritos por primera vez por Fagan (FAG76).
En el experimento de Fagan, se realizaron tres inspecciones separadas: un diseño
siguiente, pero antes de la implementación; una implementación siguiente, pero antes de la
prueba unitario; y una prueba de unidad siguiente. La inspección después de la prueba
unitario no se consideró rentable para descubrir errores; por lo tanto, no se recomienda.

Según Fagan, un equipo de inspección se compone de cuatro personas, que desempeñan

el papel de moderador, diseñador, implementador y tester. Los artículos a inspeccionar en
una inspección de diseño pueden incluir la integridad del diseño con respecto al usuario y
requerimientos funcionales, integridad interna y consistencia en la definición y uso de la
terminología, y corrección de las interfaces entre módulos. Los elementos que se
inspeccionan en una inspección de código pueden incluir interfaces de subprograma, lógica
de decisión, referencia de datos, expresiones computacionales, declaraciones de E/S,
comentarios, flujo de datos y uso de memoria.

Por ejemplo, los elementos examinados en la categoría de interfaces de subprograma

podrían incluir:

 ¿Están de acuerdo los números de los parámetros reales y los parámetros formales?
 ¿coinciden los atributos de tipo de los parámetros reales y formales?
 ¿La unidad dimensional de los parámetros actuales y formales coinciden?
 ¿Son correctos los números, los atributos y el orden de los argumentos a las
funciones incorporadas?
 ¿Se pasan las constantes como argumentos modificables?
 ¿Son coherentes las definiciones y uso de variables globales entre los módulos?

El análisis estático es una técnica para evaluar las características estructurales del código
fuente, las especificaciones del diseño, o cualquier representación notacional que se ajusta
a reglas sintácticas bien definidas. La discusión actual está restringida al análisis estático
del código fuente. En análisis estático se refiere a la estructura del programa, pero el código
no se ejecuta. Debido a que el análisis estático se refiere a la estructura del programa, es
particularmente útil descubrir prácticas de codificación cuestionables y salidas de normas
de codificación, además de detectar errores estructurales como variables no inicializadas y
desajustes entre parámetros reales y formales.
El análisis estático puede realizarse manualmente utilizando técnicas de inspección o guía;
sin embargo, el término "análisis estático" se utiliza con mayor frecuencia para indicar el
examen de la estructura del programa por una herramienta automatizada. Un analizador
estático normalmente construirá una tabla de símbolos y un gráfico de flujo de control para
cada subprograma, así como un gráfico de llamadas para todo el programa. La tabla de
símbolos contiene información sobre cada variable: sus atributos de tipo, la instrucción
donde se declara, las instrucciones que se establecen en un nuevo valor, las instrucciones
donde se utilizan para proporcionar valores.

pág. 26
Dado un gráfico de flujo de control y una tabla de símbolos que contiene, para cada variable
en un subprograma, el número de instrucción donde se declaran, establecen y se utilizan
las variables, un analizador estático puede determinar la información de flujo de datos,
como variables no inicializadas (en algunas rutas de control o en todas las rutas), variables
que se declaran, pero nunca se utilizan, y variables que se establecen, pero no se utilizan
posteriormente.

Los analizadores estáticos suelen producir listas de errores, prácticas de codificación

cuestionables (anomalías), y salidas de normas de codificación. Por ejemplo, una variable
que no se ha inicializado en todas las rutas es un error estructural. Una variable definida
pero no utilizada en cualquier ruta de control posterior, o una variable declarada pero nunca
utilizada, no es un error, pero es una anomalía que puede ser sintomática de un error.
Hay limitaciones prácticas y teóricas al análisis estático. Una limitación práctica importante
implica la evaluación dinámica de las referencias de la memoria en tiempo de
funcionamiento. En lenguajes de programación de nivel superior, los subíndices de arreglos
y las variables de puntero proporcionan referencias dinámicas de memoria basadas en
cálices anteriores realizados por el programa. Los analizadores estáticos no pueden evaluar
los subíndices o los valores de puntero; es así imposible distinguir entre los elementos de
matriz o los miembros de una lista usando técnicas de análisis estático. Las pruebas
dinámicas se utilizan típicamente para obtener información que es difícil o imposible de
obtener mediante técnicas de análisis estático.

Las limitaciones teóricas principales se imponen en el análisis estático por teoría de

decidibilidad. Los resultados de decidibilidad pueden ser expresados de varias maneras y
tener muchas implicaciones profundas. Una expresión afirma que, dada un programa
arbitrario escrito en un lenguaje de programación de propósito general (uno capaz de
simular una máquina de Turing), es imposible examinar el programa de una manera
algorítmica y determinar si una instrucción elegida arbitrariamente en el programa será
ejecutada cuando el programa funciona en datos de entrada elegidos arbitrariamente.

Las principales limitaciones teóricas se imponen en el análisis estático por la teoría de

decidibilidad. Los resultados de decidibilidad pueden expresarse de varias maneras y tienen
muchas implicaciones profundas. Una frase indica que, dado un programa arbitrario escrito
en un lenguaje de programación de propósito general (uno capaz de simular una máquina
de Turing), es imposible examinar el programa de manera algorítmica y determinar si se
ejecutará una declaración elegida arbitrariamente en el programa cuando el programa
opera sobre datos de entrada elegidos arbitrariamente.

Por "manera algorítmica" queremos decir que es imposible escribir un programa de

computadora para realizar esta tarea para todos los programas posibles. El término
"arbitrario" se usa para significar que hay programas y datos para los cuales el análisis no
es posible; sin embargo, existen programas y datos para los cuales el análisis no es posible.
Además, no existe una forma algorítmica de identificar todos los programas y datos para

pág. 27
los cuales es posible el análisis; De lo contrario, el problema de detención para las máquinas
de Turing sería solucionable.

Por lo tanto, la teoría de decidibilidad establece que no es posible escribir un analizador

estático que examine un programa arbitrario y datos de entrada arbitrarios y determine si el
programa ejecutará una instrucción de detención particular, llamará a una subrutina
particular o ejecutará una instrucción de E / S particular, o ramificará a una etiqueta dada.
Por lo tanto, es imposible realizar un análisis estático en un programa arbitrario y derivar
automáticamente un conjunto de datos de entrada que impulsarán el programa a lo largo
de una ruta de control particular. Sin embargo, es posible establecer restricciones en los
programas para que los problemas indecibles se vuelvan decidibles. Por ejemplo, se
garantiza que un programa de línea recta sin sentencias de bifurcación ejecutará todas las
sentencias del programa en cada ejecución (excluyendo el desbordamiento, etc.), y se
puede usar el análisis estático para determinar si un programa contiene sentencias de
bifurcación.

Al restringir los programas para que tengan solo condiciones de ruta lineal, el problema de
derivar automáticamente datos de prueba para conducir programas a lo largo de rutas de
ejecución particulares puede resolverse mediante análisis estático, ejecución simbólica y
técnicas de programación lineal. Sin embargo, el requisito para condiciones de trayectoria
lineal es una restricción severa para colocar en programas y programadores.

La ejecución simbólica es una técnica de validación en la que a las variables de entrada de

una unidad de programa se les asignan valores simbólicos en lugar de valores literales. Un
programa se analiza mediante la propagación de los valores simbólicos de las entradas en
los operandos en expresiones. Las expresiones simbólicas resultantes se simplifican en
cada paso del cálculo, de modo que todos los cálculos y decisiones intermedios se
expresan siempre en términos de las entradas simbólicas. Por ejemplo, la evaluación de
una instrucción de asignación resulta en la asociación de una expresión simbólica con la
variable de la izquierda. Cuando esa variable se usa en expresiones posteriores, se usa el
valor simbólico actual. De esta manera, todos los cálculos y decisiones se expresan como
valores simbólicos de las entradas.

El análisis estático se utiliza para investigar las propiedades estructurales del código fuente.
Los casos de prueba dinámicos se utilizan para investigar el comportamiento del código
fuente ejecutando el programa en los datos de prueba. Como antes, usamos el término
"unidad de programa" para denotar una rutina o una colección de rutinas implementadas
por un programador individual. En un sistema de pozo, una unidad de programa es un
programa independiente o una unidad funcional de un sistema más grande.

Las pruebas de unidad comprenden el conjunto de pruebas realizadas por un programador

individual antes de la integración de la unidad en un sistema más grande. La situación se
ilustra de la siguiente manera:
Codificación y depuración → Pruebas de unidad → Pruebas de integración
pág. 28
Una unidad de programa (program unit) suele ser lo suficientemente pequeña para que el
programador que la desarrolló pueda probarla con gran detalle, y ciertamente con mayor
detalle de lo que será posible cuando la unidad esté integrada en un producto de software
en evolución.

Hay cuatro categorías de pruebas que un programador normalmente realiza en una unidad
de programa:

 Pruebas funcionales.
 Pruebas de rendimiento.
 Pruebas de estrés.
 Pruebas de estructura.

Los casos de prueba funcionales implican ejercer el código con valores de entrada
nominales para los que se conocen los resultados esperados, así como valores de límite
(valores mínimos, valores máximos y valores dentro y fuera de los límites funcionales) y
valores especiales, como entradas relacionadas lógicamente, matrices 1 x 1, la matriz de
identidad, archivos de elementos idénticos y archivos vacíos.

Las pruebas de rendimiento determinan la cantidad de tiempo de ejecución empleado en

varias partes de la unidad, el rendimiento del programa, el tiempo de respuesta y la
utilización del dispositivo por parte de la unidad del programa. Se puede realizar una cierta
cantidad de ajuste de rendimiento durante la prueba de la unidad; sin embargo, se debe
tener precaución para evitar gastar demasiado esfuerzo en el ajuste fino de una unidad de
programa que contribuye poco al rendimiento general de todo el sistema. Las pruebas de
rendimiento son más productivas a nivel de subsistema y sistema.

Las pruebas de estrés son aquellas pruebas diseñadas para romper intencionalmente la
unidad. Se puede aprender mucho sobre las fortalezas y limitaciones de un programa al
examinar la manera en que se rompe una unidad de programa.
Las pruebas de estructura están relacionadas con el ejercicio de la lógica interna de un
programa y el paso por caminos de ejecución particulares. Algunos autores se refieren
colectivamente a las pruebas funcionales, de rendimiento y de estrés como pruebas de
"caja negra", mientras que las pruebas de estructura se conocen como pruebas de "caja
blanca" o "caja de vidrio". Las principales actividades en las pruebas estructurales son
decidir qué rutas realizar, derivar datos de prueba para ejercer esas rutas, determinar el
criterio de cobertura de prueba que se utilizará, ejecutar los casos de prueba y medir la
cobertura de prueba lograda cuando se ejercen los casos de prueba.

Se debe establecer un criterio de cobertura de la prueba (o finalización de la prueba) para

la prueba de la unidad, porque las unidades del programa generalmente contienen
demasiados caminos para permitir una prueba exhaustiva.

Incluso si fuera posible probar con éxito todas las rutas a través de un programa, la prueba
de ruta no garantizaría la corrección, ya que el programa puede tener rutas faltantes y
pág. 29
errores de cálculo que no se detectaron en los casos de prueba específicos elegidos. Un
error de ruta faltante ocurre cuando una declaración de bifurcación y los cálculos asociados
se omiten accidentalmente. Los errores de ruta faltantes solo pueden ser detectados por
casos de prueba funcionales derivados de las especificaciones de requisitos. Por lo tanto,
las pruebas basadas únicamente en la estructura del programa no pueden detectar todos
los errores potenciales en un programa fuente. La corrección accidental ocurre cuando un
caso no detecta un error computacional.

La depuración es el proceso de aislar y corregir las causas de errores conocidos. El éxito

en la depuración requiere habilidades de resolución de problemas altamente desarrolladas.
Los métodos de depuración más utilizados incluyen la inducción, la deducción y el
retroceso. La depuración por inducción implica los siguientes pasos:
1. Recoge la información disponible. Enumere los hechos conocidos sobre el fracaso
observado y los hechos conocidos relacionados con casos de prueba exitosos.
¿Cuáles son los síntomas observados? ¿Cuándo ocurrió el error? ¿Bajo qué
condiciones ocurrió? ¿En qué se diferencia el caso de falla de los casos exitosos?
2. Busca patrones. Examine la información recopilada en busca de condiciones que
diferencien el caso de falla de los casos exitosos.
3. Formar una o más hipótesis. Derive una o más hipótesis de las relaciones
observadas. Si no hay hipótesis evidentes, vuelva a examinar la información
disponible y recopile información adicional, tal vez ejecutando más casos de prueba.
Si surgen varias hipótesis, clasifíquelas en el orden de más probable a menos
probable.
4. Probar o refutar cada hipótesis. Vuelva a examinar la información disponible para
determinar si la hipótesis explica todos los aspectos del problema observado. No
pase por alto la posibilidad de que pueda haber múltiples errores. No continúe con
el paso 5 hasta que se complete el paso 4.
5. Implementar las correcciones apropiadas. Realice las correcciones indicadas por su
evaluación de las diversas hipótesis. Realice las correcciones a una copia de
respaldo del código, en caso de que las modificaciones no sean correctas.
6. Verificar la corrección. Vuelva a ejecutar el caso de falla para asegurarse de que la
corrección corrija el síntoma observado. Ejecute casos de prueba adicionales para
aumentar su confianza en la solución. Vuelva a ejecutar los casos de prueba exitosos
anteriormente para asegurarse de que su solución no haya creado nuevos
problemas. Si la solución tiene éxito, haga que la copia de la revisión sea la versión
principal del código y elimine la copia anterior. Si la solución no tiene éxito, vaya al
paso 1.
La depuración por deducción procede de la siguiente manera:

 Enumere las posibles causas de la falla observada.

 Usa la información disponible para eliminar varias hipótesis.
 Elaborar las hipótesis restantes.
pág. 30
  Probar o refutar cada hipótesis.
 Determine las correcciones apropiadas.
 Verificar las correcciones.

La depuración por retroceso implica trabajar hacia atrás en el código fuente desde el punto
en que se observó el error en un intento de identificar el punto exacto donde ocurrió el error.
Puede ser necesario ejecutar casos adicionales para recopilar más información. Las
técnicas para recopilar la información necesaria se describen en los párrafos siguientes.

Las técnicas tradicionales de depuración utilizan volcados de volcado de salida de

diagnóstico, rastreos selectivos en valores de datos y flujo de control, y puntos de
interrupción dependientes de instrucciones. Las herramientas modernas de depuración
utilizan puntos de interrupción controlados por aserciones e historiales de ejecución.

Las declaraciones de salida de diagnóstico se pueden incrustar en el código fuente como

declaraciones de comentarios con formato especial que se activan mediante una opción de
traductor especial. La salida de diagnóstico de estas declaraciones proporciona capturas
de los componentes seleccionados del estado del programa, a partir de los cuales el
programador intenta inferir el comportamiento del programa. El estado del programa incluye
los valores asociados con todos los símbolos actualmente accesibles y cualquier
información adicional, como la pila de programas y el contador de programas, necesarios
para continuar la ejecución desde un punto particular en la secuencia de ejecución del
programa.

Un basurero de capturas es una representación a nivel de máquina del estado parcial o

total del programa en un punto particular de la secuencia de ejecución. Un basurero de
capturas estructurado es una representación a nivel de fuente de estado parcial o total de
un programa. Los nombres y valores actuales de los símbolos disponibles en el momento
de la instantánea.

Un servicio de rastreo enumera los cambios en los componentes de estado seleccionados.

En su forma más simple, una traza imprimirá todos los cambios en los valores de datos
para todas las variables y todos los cambios en el flujo de control. Una traza selectiva
rastreará variables específicas y controlará el flujo en regiones específicas del texto fuente.

Una instalación tradicional de punto de interrupción interrumpe la ejecución del programa y

transfiere el control al terminal del programador cuando la ejecución alcanza una instrucción
de "interrupción" especificada en el código fuente. Normalmente, el programador puede
examinar el estado del programa, cambiar los valores de los componentes del estado,
establecer nuevos puntos de interrupción y reanudar la ejecución en modo normal o en
modo de un solo paso, tal vez comenzando en otra ubicación de instrucción.

Un historial de ejecución es un registro de eventos de ejecución recopilados de un programa

en ejecución. Normalmente, el historial se almacena en una base de datos para la ejecución
post mortem después de que el programa haya terminado la ejecución. Un servicio de

pág. 31
rastreo utiliza el historial de ejecución para rastrear el flujo de control y el flujo de datos tanto
hacia adelante como hacia atrás en el tiempo de ejecución. Las dependencias del flujo de
control y del flujo de datos se pueden rastrear hacia adelante o hacia atrás en el tiempo de
ejecución desde la posición actual en el historial de ejecución. La interpretación del historial
de ejecución en orden inverso proporciona la ilusión de que el programa se está ejecutando
hacia atrás en el tiempo de ejecución. Esto permite el análisis de cómo un cómputo en
particular estuvo influenciado por eventos previos. Esta capacidad es extremadamente
valiosa para depurar y probar condiciones de error no repetibles como las que surgen en el
procesamiento en tiempo real de eventos externos.

El Sistema de Monitoreo y Depuración Extensible (Extendable Debugging and Monitoring

System: EXDAMS) y el Sistema de Modelado Semántico Interactivo (Interactive Semantic
Modeling System: SGSI) son dos ejemplos de facilidades de prueba y depuración que
incorporan una colección de historial de ejecución y capacidad de visualización.

El esquema ISMS utiliza un preprocesador para realizar un análisis estático del programa
fuente e instrumentar el código fuente con llamadas de subrutinas que recopilan el historial.
El analizador estático crea un modelo de programa y lo almacena en la base de datos del
programa. El modelo del programa contiene una copia del texto de origen no documentado,
una tabla de símbolos para los identificadores del programa, un modelo de ejecución del
programa y una tabla de referencia cruzada para interconectar el modelo de ejecución con
el texto de origen. El historial de ejecución está interconectado con el modelo de ejecución,
que a su vez se refiere al texto de origen. De esta manera, el comportamiento del programa
se puede presentar al usuario en términos de nivel de fuente.

En un sistema de historial de ejecución, el usuario no puede interactuar directamente con

el programa en ejecución, sino que examina el comportamiento del programa interrogando
a la base de datos post mortem. Esta incapacidad para interactuar con el programa en
ejecución caracteriza las diferencias entre los dos enfoques fundamentales para la
depuración y las pruebas de unidad: interpretación y recopilación de historial.

El estado de ejecución de un programa en cualquier punto dado en el tiempo de ejecución

consiste en los valores asociados con los símbolos actualmente accesibles más la
información de flujo de control necesaria para continuar la ejecución desde ese punto. En
el enfoque del historial de ejecución, solo los cambios en el estado de ejecución se registran
a medida que se ejecuta el programa. Este enfoque se toma para reducir la sobrecarga
irrazonable en el tiempo de ejecución y el espacio de memoria que se requeriría para
mantener una copia completa de la ejecución de cada paso en la secuencia de ejecución.
Un estado de ejecución se reconstruye a partir de un historial incremental de cambios
comenzando al principio del historial, el estado inicial y explorando el historial a los cambios
que ocurren hasta el punto deseado en el tiempo de ejecución. Se pueden derivar otros
estados de ejecución explorando hacia adelante o hacia atrás a través del historial de
ejecución desde ese punto, modificando el estado según corresponda.

pág. 32
Los méritos relativos de los intérpretes y las historias de ejecución son evidentes. Un
historial de ejecución contiene un conjunto completo de estados de ejecución en forma
incremental. Por lo tanto, se puede recopilar información de resumen, los cambios en los
estados de ejecución se pueden rastrear hacia adelante o hacia atrás en el tiempo de
ejecución, se pueden verificar aserciones arbitrariamente complejas sin planificación previa,
y se puede proporcionar un análisis de flujo de retorno.

Por otro lado, el usuario no puede detener la ejecución en un punto arbitrario, cambiar el
estado de ejecución de varias maneras y continuar la ejecución como sea posible en un
sistema interpretativo como ALADDIN. Sin embargo, los intérpretes sufren la desventaja de
no mantener información histórica. Cuando se utiliza un intérprete, puede ser necesario
volver a ejecutar todo el programa para verificar una afirmación que involucre múltiples
estados del programa, recopilar estadísticas de resumen o determinar el flujo de control y
las dependencias del flujo de datos. Muchos sistemas interpretativos, incluido ALADDIN,
mantienen un registro histórico de los últimos 10 o 20 estados de ejecución, lo que alivia
parcialmente, pero no resuelve totalmente, este problema.
Las pruebas del sistema implican dos tipos de actividades: pruebas de integración y
pruebas de aceptación. Las estrategias para integrar componentes de software en un
producto funcional incluyen la estrategia de abajo hacia arriba, la estrategia de arriba hacia
abajo y la estrategia de sándwich. Se requiere una planificación y planificación cuidadosas
para garantizar que los módulos estarán disponibles para la integración en el producto de
software en evolución cuando sea necesario. La estrategia de integración determina el
orden en que los módulos deben estar disponibles y, por lo tanto, ejerce una gran influencia
en el orden en que se escriben, depuran y prueban los módulos.

Las pruebas de aceptación implican la planificación y ejecución de pruebas funcionales,

pruebas de rendimiento y pruebas de estrés para verificar que el sistema implementado
cumple con sus requisitos. Las pruebas de aceptación suelen ser realizadas por las
organizaciones de garantía de calidad y / o de clientes. Dependiendo de las circunstancias
locales, el grupo de desarrollo puede o no participar en las pruebas de aceptación.

La integración de abajo hacia arriba (Bottom-Up) es la estrategia tradicional utilizada para

integrar los componentes de un sistema de software en un conjunto funcional. La
integración Bottom-Up consiste en pruebas unitarias de todo el sistema. Las pruebas
unitarias tienen el objetivo de descubrir errores en los módulos individuales del sistema. Los
módulos se prueban aislados unos de otros en un entorno artificial conocido como "arnés
de prueba" que consiste en el programa del controlador y los datos necesarios para ejercer
los módulos. La prueba de unidad debe ser lo más exhaustiva posible para garantizar que
se haya evaluado el caso representativo manejado por cada módulo. La prueba de la unidad
se facilita mediante una estructura del sistema que se compone de un módulo pequeño y
sin apretar.

pág. 33
Un subsistema consta de varios módulos que se comunican entre sí a través de interfaces
bien definidas. Normalmente, un subsistema implementa un segmento importante del
sistema total. El propósito principal de las pruebas de subsistemas es verificar el
funcionamiento de las interfaces entre los módulos en el subsistema. Se deben probar las
interfaces de control y de datos. Los sistemas de software grandes pueden requerir varios
niveles de pruebas de subsistemas; Los subsistemas de nivel inferior se combinan
sucesivamente para formar subsistemas de nivel superior. En la mayoría de los sistemas
de software, las pruebas exhaustivas de las capacidades de los subsistemas no son
factibles debido a la complejidad combinatoria de las interfaces del módulo; por lo tanto, los
casos de prueba deben ser elegidos cuidadosamente para ejercer las interfaces de la
manera deseada.

La prueba del sistema se refiere a las sutilezas en las interfaces, la lógica de decisión, el
flujo de control, los procedimientos de recuperación, el rendimiento, la capacidad y las
características de temporización de todo el sistema. Se requiere una planificación
cuidadosa de las pruebas para determinar el alcance y la naturaleza de las pruebas del
sistema que se realizarán y para establecer los criterios según los cuales se evaluarán los
resultados.

Las desventajas de las pruebas de abajo hacia arriba (Bottom-Up) incluyen la necesidad de
escribir y depurar los arneses de prueba para los módulos y subsistemas, y el nivel de
complejidad que resulta de la combinación de módulos y subsistemas en unidades más
grandes y más grandes. El caso extremo de complejidad resulta cuando cada módulo se
prueba de forma aislada y todos los módulos se vinculan y ejecutan en una única ejecución
de integración. Este es el enfoque "big bang" para las pruebas de integración. El principal
problema con la integración “Big Bang” es la dificultad de aislar las fuentes de errores.

Las pruebas de aprovechamiento (Test harnesses) proporcionan entornos de datos y

secuencias de llamada para las rutinas y subsistemas que se están probando de forma
aislada. La preparación un “Test Harness” puede representar el 50% o más del esfuerzo de
codificación y depuración de un producto de software.

La integración descendente (Top-Down) comienza con la rutina principal y una o dos rutinas
inmediatamente subordinadas en la estructura del sistema. Después de que este
"esqueleto" de nivel superior se haya probado a fondo, se convierte en el arnés de prueba
para sus rutinas inmediatamente subordinadas. La integración de arriba a abajo requiere el
uso de apéndices de programa para simular el efecto de las rutinas de nivel inferior a las
que llaman quienes están siendo probados.
La integración descendente ofrece varias ventajas:

 La integración del sistema se distribuye a lo largo de la fase de implementación. Los

módulos se integran a medida que se desarrollan.
 Las interfaces de nivel superior se prueban primero y con mayor frecuencia.

pág. 34
  Las rutinas de nivel superior proporcionan un arnés de prueba natural para rutinas
de nivel inferior.
 Los errores se localizan en los nuevos módulos e interfaces que se están agregando.
Si bien puede parecer que la integración de arriba a abajo es siempre preferible, hay
muchas situaciones en las que no es posible adherirse a una estrategia de integración y
codificación de arriba a abajo. Por ejemplo, puede ser difícil encontrar datos de entrada de
nivel superior que ejerzan un módulo de nivel inferior de una manera particular deseada.
Además, el sistema en evolución puede ser muy costoso de ejecutar como un arnés de
prueba para nuevas rutinas; puede que no sea rentable volver a vincular y volver a ejecutar
un sistema de 50 o 100 rutinas cada vez que se agregue una nueva rutina. Con frecuencia,
se pueden ahorrar cantidades importantes de tiempo de máquina probando los subsistemas
en forma aislada antes de insertarlos en la estructura descendente en evolución. En algunos
casos, puede que no sea posible usar apéndices de programas para simular módulos por
debajo del nivel actual (por ejemplo, controladores de dispositivos, controladores de
interrupciones), puede ser necesario probar primero ciertos módulos críticos de nivel bajo.
La estrategia de prueba de sándwich puede ser preferida en estas situaciones.

La integración de Sándwich es predominantemente de arriba hacia abajo (Top-Down), pero

se utilizan técnicas de abajo hacia arriba en algunos módulos y subsistemas. Esta mezcla
alivia muchos de los problemas encontrados en las pruebas puras descendentes y conserva
las ventajas de la integración descendente a nivel de subsistema y sistema.

Las herramientas automatizadas utilizadas en las pruebas de integración incluyen

controladores de módulos, generadores de datos de prueba, simuladores de entorno y una
instalación de administración de bibliotecas para permitir la configuración y reconfiguración
sencillas de los elementos del sistema. Los controladores de módulos automatizados
permiten la especificación de casos de prueba (entradas y resultados esperados) en un
lenguaje descriptivo. La herramienta del controlador luego llama a la rutina (o rutinas)
utilizando los casos de prueba especificados, compara el resultado real con los resultados
esperados e informa las discrepancias.

Las pruebas de aceptación implican la planificación y ejecución de pruebas funcionales,

pruebas de rendimiento y pruebas de estrés para demostrar que el sistema implementado
satisface sus requisitos. No es inusual que se ejecuten dos conjuntos de pruebas de
aceptación: las desarrolladas por el grupo de control de calidad y las desarrolladas por el
cliente.

Además de las pruebas funcionales y de rendimiento, se realizan pruebas de estrés para

determinar las limitaciones del sistema. Por ejemplo, se puede probar un compilador para
determinar el efecto del desbordamiento de la tabla de símbolos, o se puede probar un
sistema para determinar el efecto de la llegada simultánea de numerosas interrupciones de
alta prioridad.

pág. 35
Por lo general, las pruebas de aceptación incorporarán casos de prueba durante las
pruebas unitarias y las pruebas de integración. Se agregan casos de prueba adicionales al
nivel deseado de pruebas funcionales, de rendimiento y de estrés de todo el sistema. Las
herramientas de temporización de importancia especial durante las pruebas de aceptación
incluyen un analizador de cobertura de prueba, un analizador de temporización y un
verificador de estándares de codificación.

Un analizador de cobertura de prueba registra las rutas de control seguidas para cada caso
de prueba. El registro acumulativo se utiliza para establecer el alcance de la cobertura de
prueba obtenida durante las pruebas de aceptación. Sin esta herramienta, es imposible
establecer el alcance de la cobertura de prueba obtenida. En sistemas grandes, el
analizador de cobertura puede registrar solo las rutinas llamadas y no las declaraciones
individuales ejecutadas.

Un analizador de tiempo informa el tiempo pasado en varias regiones del código fuente en
diferentes casos de prueba. No es inusual que un programa gaste del 80 al 90 por ciento
del tiempo de ejecución en 20 por ciento o menos del código. Estas regiones del código son
áreas en las que se debe concentrarse para mejorar el rendimiento del sistema.

Ciertos estándares de codificación a menudo se establecen en los requisitos del producto.

Los estándares de codificación pueden estar relacionados con el proyecto, el cliente, el
desarrollador o el idioma. La inspección manual generalmente no es un mecanismo
adecuado para detectar violaciones de los estándares de codificación. Los analizadores
estáticos y los verificadores de estándares se pueden usar para inspeccionar el código en
busca de desviaciones de los estándares y pautas.
La verificación formal implica el uso de técnicas matemáticas rigurosas para demostrar que
los programas de computadora tienen ciertas propiedades deseadas. El método de
aseveraciones de entrada-salida, condiciones previas más débiles y técnicas estructurales
comúnmente utilizadas.

Las pruebas de la fiabilidad son un proceso de pruebas cuya meta consiste precisamente
en medir la fiabilidad de un sistema. Existen muchas métricas de fiabilidad, como POFOD,
probabilidad de falla a pedido, y ROCOF, tasa de ocurrencia de falla. Dichas métricas
permiten especificar cuantitativamente la fiabilidad requerida del software. Durante el
proceso de pruebas de fiabilidad es posible comprobar si el sistema logró el nivel de
fiabilidad requerido.
En la figura siguiente se ilustra el proceso para medir la fiabilidad de un sistema.

Este proceso incluye cuatro etapas:

pág. 36
  Se inicia con el estudio de los sistemas existentes del mismo tipo para entender
cómo se usan en la práctica. Esto es importante, pues se trata de medir la fiabilidad
como la ve un usuario del sistema. Su meta es definir un perfil operativo. Este último
identifica clases de entradas del sistema y la probabilidad de que dichas entradas
ocurran en uso normal.
 Luego se construye un conjunto de datos de prueba que reflejan el perfil operativo,
lo que significa que se crean datos de prueba con la misma distribución de
probabilidad que los datos de prueba para los sistemas que ya se estudiaron.
Normalmente, se usará un generador de datos de prueba para apoyar este proceso.
 El sistema se prueba usando estos datos y el número de cuenta, así como el tipo de
fallas que ocurren. También se registran los tiempos de dichas fallas. Las unidades
de tiempo elegidas deben ser adecuadas para la métrica de fiabilidad que se usa.
 Después de observar un número estadísticamente significativo de fallas, es posible
calcular la fiabilidad del software y trabajar con el valor adecuado de métrica de
fiabilidad.

Este proceso de cuatro pasos en ocasiones se conoce como “prueba estadística”. La meta
de la prueba estadística es valorar la fiabilidad del sistema.

Es necesario registrar los resultados del análisis del riesgo en el plan del proyecto, junto
con un análisis de consecuencias, que establece las consecuencias del riesgo para el
proyecto, el producto y la empresa. La gestión de riesgos efectiva facilita hacer frente a los
problemas y asegurar que éstos no conduzcan a un presupuesto inaceptable o a retrasos
en el calendario.

Los riesgos específicos que podrían afectar un proyecto dependen del proyecto y el entorno
de la organización donde se desarrolla el software. Sin embargo, también existen riesgos
comunes que no se relacionan con el tipo de software a desarrollar y que pueden ocurrir en
cualquier proyecto.

Una de las tareas en la planificación es la estimación de los recursos requeridos para lograr
el esfuerzo de desarrollo del software. Las tres principales categorías de los recursos de la
ingeniería de software son:

 Personal.
 Componentes de software reutilizables.
 Entorno de desarrollo (herramientas de hardware y software).
Cada recurso se especifica con cuatro características:

 Descripción del recurso.

 Un enunciado de disponibilidad.
 Momento en el que se requerirá el recurso.
 Duración del tiempo que se aplicará el recurso.

pág. 37
Las últimas dos características pueden verse como una ventana temporal. La disponibilidad
del recurso para una ventana específica debe establecerse en el tiempo práctico más
temprano.

Los proyectos de software se planean y controlan debido a una razón principal: es la única
forma conocida para manejar la complejidad. E incluso así, los equipos de software todavía
batallan. En un estudio de 250 grandes proyectos de software desarrollados entre 1998 y
2004, Capers Jones encontró que “alrededor de 25 se consideraron exitosos por haber
logrado sus objetivos de calendario, costo y calidad. Aproximadamente 50 tuvieron demoras
o excesos por abajo de 35 por ciento, mientras que más o menos 175 experimentaron
grandes demoras y excesos, o se dieron por concluidos sin completarse”. Aunque
actualmente la tasa de éxito para los proyectos de software puede haber mejorado un poco,
la tasa de falla de proyecto sigue siendo mucho más alta de lo que debiera.

Para evitar el fracaso del proyecto, un gerente de proyecto de software y los ingenieros de
software que construyan el producto deben evitar un conjunto de señales de advertencia
comunes, entender los factores de éxito cruciales que conducen a una buena
administración del proyecto y desarrollar un enfoque de sentido común para planificar,
monitorear y controlar el proyecto.

Para administrar un proyecto de software exitoso, se debe comprender qué puede salir mal,
de modo que los problemas puedan evitarse. En un excelente ensayo acerca de los
proyectos de software, John Reel define 10 señales que indican que un proyecto de
sistemas de información está en peligro:

 El personal del software no entiende las necesidades del cliente.

 El ámbito del producto está pobremente definido.
 Los cambios se gestionan pobremente.
 Cambia la tecnología elegida.
 Las necesidades empresariales cambian (o están mal definidas).
 Las fechas límite son irreales.
 Los usuarios son resistentes.
 Pérdida de patrocinio (o nunca obtenido adecuadamente).
 El equipo del proyecto carece de personal con habilidades adecuadas.
 Los gerentes (y profesionales) evitan mejores prácticas y lecciones aprendidas.

Los profesionales de la industria, hastiados, con frecuencia se refieren a la regla 90-90

cuando estudian proyectos de software particularmente difíciles: el primer 90 por ciento de
un sistema absorbe el 90 por ciento del esfuerzo y tiempo asignados. El último 10 por ciento
toma otro 90 por ciento del esfuerzo y tiempo asignados. Las semillas que conducen a la
regla 90-90 están contenidas en las señales anotadas en la lista anterior.

Conclusiones
Flores Carmona Diana Arlett
pág. 38
Gracias a lo que vimos en clase y las investigaciones que se realizaron tenemos una
manera más clara de la importancia que conlleva realizar un proyecto de software, ya que
es muy diferente a los proyectos productivos.

Se realizó una investigación para ver cuáles son las principales características y tener un
mínimo margen de error al momento de la creación de este, ya que para comenzarlo
debemos tener muy en claro cuáles serán los objetivos del proyecto ya que sino planteamos
bien los objetivos tendremos problemas al momento de comenzar con las estimaciones de
tiempo y de costo, en la estimación de tiempo es más como calendario o cronograma dónde
deben seguirse al pie de la letra cada una de las actividades a realizar.

Al reclutar personal es cuando comienza el reto para cumplir con las estimaciones del
tiempo ya que al momento de contratarlo de cierta manera deben formar parte del proyecto
e involucrarlo a tal grado que solo conozca su parte del trabajo, sin omitir lo que son sus
honorarios.
Entendimos que hay varias maneras para evitar que ocurran riesgos y como ya se sabe
que en cualquier proyecto siempre hay un margen de error se deben plantear estrategias
para estar preparados ante algunos de los sucesos o contingencias.

Sabemos que la viabilidad del proyecto depende mucho de todo lo anterior y que debe
realizarse de tal manera que se cubran todos los puntos para evitar pérdidas, ya sean
económicos o de personal, ya que para tener un buen proyecto es necesario tener un
equipo unido.
Morales Flores Jose Manuel

En base a lo que hemos investigado de esta unidad, puedo decir que la planificación del
proyecto tiene una amplia importancia al momento de iniciar el desarrollo de un software o
cualquier proyecto, especifica todos los puntos que debemos contemplar para poder cumplir
el objetivo que se ha plateado.
Primeramente, nos habla del objetivo del mismo, que no es más que la etapa en la que
debemos analizar qué es lo que se tiene o debe lograr, para así conocer exactamente el
rumbo del proyecto y que las demás personas envueltas en él también sepan y se realicen
las tareas necesarias para ello. Después de esto, pasaríamos al punto de establecer una
calendarización, para ello debemos analizar todas las actividades, recursos, personal para
poder repartir tareas de un mismo tamaño a cada uno de los que forman parte con una
estructura en la cual estas mismas tareas no se crucen o alteren otras.
Analizando todas las partes de las cuales habla esta unidad, nos damos cuenta que todas
las fases llevan un orden y cada una de ellas van enlazadas, por ejemplo, no podemos
estimar los tiempos, si todavía no sabemos de lo que se tratará el proyecto cómo también
no podemos estimar los costos de todo el proyecto si todavía no hemos hecho un calendario
de las actividades a realizar más los recursos a utilizar.

pág. 39
Otro punto muy importante que nos dice es que, aunque nosotros seamos ingenieros en
sistemas, cuando queramos iniciar un proyecto aun así sea de desarrollo de software o no,
debemos tener en cuenta que también debemos saber organizar y administrar tiempo,
personal y recursos. Algo que algunos ingenieros no se enfocan tanto, pero es muy
importante. Entonces esto nos enseña a tener una idea de cómo podemos administrar un
proyecto para que este se concluya exitosamente como también cuando haya problemas,
podamos saber resolverlos o convertirlos en una ventaja.
Valenzuela Barrientos Carlos Jair

Como ya se sabe, un proyecto no es más que el conjunto de actividades desarrolladas por

una persona o un equipo para lograr un objetivo o una meta. En nuestro caso específico,
para la realización de un software que cumpla con una demanda o solucione una
problemática.

La tarea de la planificación de un proyecto no es sencilla, pues como administrador o jefe

del proyecto, uno tiene las responsabilidades de todo el ciclo de vida, desde la
calendarización, en la cual se debe planear muy bien los tiempos de trabajo, así como la
selección del equipo de trabajo, que serán los encargados de llevar a cabo las tareas
asignadas por nosotros como administradores y, que de ellos dependerá (en parte) el
resultado final del proyecto.
La calendarización es la distribución de periodos y fechas en el tiempo estimado para la
realización del proyecto. Por esto es de suma importancia que el administrador sepa asignar
bien los periodos de trabajo, para evitar retardos en la entrega, aunque es inevitable algún
retraso en alguna actividad calendarizada.

El personal es el activo más importante con el que contaremos, por esta razón es el recurso
más costoso, puesto que es difícil reclutar al mejor personal, además de retenerlo (esto se
refleja en dinero). Pero que, de realizar bien esta selección, se reflejara en la calidad de
nuestro producto.

Otro de los puntos a tomar en cuenta es la de calcular que tanto nos costará la realización
del proyecto, tomando en cuenta factores como el pago al equipo de trabajo, compra de
hardware (equipos) y software (licencias) para trabajar, costos de capacitaciones, así como
también el precio que se le propondrá al cliente por nuestro trabajo.

Bibliografía
 Ingeniería de software. Ian Sommerville.
 Ingeniería de software. Un enfoque práctico. Roger S. Pressmam.
 Preparación y evaluación de proyectos. Nassir Sapag Chain. Reinaldo Sapag Chain.
 Software Engineering Concepts. Richard E. Fairley.
 Contandriopoulos AP, Champagne F, Potvin L, Denis JL, Boyle P. Preparar un
proyecto de investigación. Barcelona: SG ed; 1991.

pág. 40