Seales que indican que un proyecto de sistemas de informacin est en peligro

Cuando se tienen problemas para controlar uno o ms de los factores de costo, tiempo, esfuerzo y calidad,
puede indicar que un proyecto de software puede estar en peligro, adems de las anteriores John Reel define
diez seales que tambin indican que un proyecto de sistemas de informacin est en peligro:
1. La gente del proyecto no comprende las necesidades del cliente
2. El mbito del producto est definido pobremente.
3. Los cambios estn mal realizados, es decir se gestionan pobremente.
4. La tecnologa elegida cambia.
5. Las necesidades del negocio cambian (o estn mal definidas)
6. Las fechas de entrega no son realistas.
7. Los usuarios se resisten.
8. Se pierden los patrocinadores (o nunca se obtuvieron adecuadamente).
9. El equipo del proyecto carece del personal con las habilidades apropiadas.
10. Los gestores (y los desarrolladores] evitan buenas prcticas y lecciones aprendidas.

1. PRUEBAS DE SISTEMAS

El desarrollo de sistemas de software implica una serie de actividades de produccin en las que las
posibilidades de que aparezca el fallo humano son enormes

Las pruebas del software son un elemento crtico para la garanta de calidad del software y representa una
revisin final de las especificaciones, del diseo y de la codificacin.
La creciente percepcin del software como un elemento del sistema y la importancia de los costes
asociados a un fallo del propio sistema, estn motivando la creacin de pruebas minuciosas y bien
planificadas. No es raro que una organizacin de desarrollo de software emplee entre el 30 y el 40 por ciento
del esfuerzo total de un proyecto en las pruebas

Una vez generado el cdigo fuente, el sistema debe ser probado para descubrir y corregir el mximo de
errores posibles antes de la entrega al cliente. El objetivo es ensear una serie de casos de prueba que tengan
una alta probabilidad de encontrar errores. Para ello se aplican tcnicas de pruebas, que facilitan una gua
sistemtica para disear pruebas que 1. Comprueben la lgica interna de los componentes de software y 2.
que verifiquen los dominios de entrada y salida del programa para descubrir errores en la funcionalidad, el
comportamiento y el rendimiento

Cules son los pasos:

El sistema debe probarse desde dos perspectivas diferentes:
1 la lgica interna del programa se comprueba utilizando tcnicas de diseo de casos de prueba de caja
blanca.
2. Los requisitos del software se comprueban utilizando tcnicas de diseo de casos de prueba de caja negra.
En ambos casos, se intenta encontrar el mayor nmero de errores con la menor cantidad de esfuerzo y tiempo

El ingeniero crea una serie de casos de prueba que intentan demoler el software construido. De hecho, las
pruebas son uno de los pasos de la ingeniera del software que se puede ver (por lo menos, psicolgicamente)
como destructivo en lugar de constructivo.

Objetivos de las pruebas

1. La prueba es el proceso de ejecucin de un programa con la intencin de descubrir un error.
2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta
entonces.

3. Una prueba tiene xito si descubre un error no detectado hasta entonces.

4. La prueba no puede asegurar la ausencia de defectos; slo puede demostrar que existen defectos en el
software.

El principio de Pareto es aplicable a la prueba del software. Dicho de manera sencilla, el principio de Pareto
implica que al 80% de todos los errores descubiertos durante las pruebas se les puede hacer un seguimiento
hasta un 20 % de todos los mdulos del programa

Para ser ms eficaces, las pruebas deberan ser realizadas por un equipo independiente, el que hizo el
sistema no es el ms adecuado para realizar estas pruebas

Cules son las caractersticas de una buena prueba?

Alta probabilidad, no es redundante, debe ser la mejor de todas, no debe ser demasiado simple o compleja
2. Prueba de Caja Blanca y Caja Negra

Cualquier producto de ingeniera (y de muchos otros campos) puede probarse de una de estas dos formas:
(1) conociendo la funcin especfica para la que fue diseado el producto, se pueden llevar a cabo
pruebas que demuestren que cada funcin es completamente operativa y, al mismo, tiempo buscando
errores en cada funcin;
(2) conociendo el funcionamiento del producto, se pueden desarrollar pruebas que aseguren que
todas las piezas encajan, o sea, que la operacin interna se ajusta a las especificaciones y que todos
los componentes internos se han comprobado de forma adecuada. El primer enfoque de prueba se
denomina prueba de caja negra y el segundo, prueba de caja blanca.

Cuando se considera el software de computadora, la prueba de caja negra se refiere a las pruebas que se
llevan a cabo sobre la interfaz del software, demostrar que las funciones del software son operativas que la
entrada se acepta de forma adecuada y que se produce un resultado correcto, as como que la integridad de la
informacin externa (por ejemplo, archivos de datos) se mantiene.

La prueba de caja blanca del software se basa en el minucioso examen de los detalles procedimentales. Se
puede examinar el estado del programa en varios puntos para determinar si el estado real coincide con el
esperado o mencionado.

PRUEBA DE CAJA BLANCA

La prueba de caja blanca, denominada a veces prueba de caja de vidrio o cristal es un mtodo de diseo de
casos de prueba que usa la estructura de control del diseo procedimental para obtener los casos de prueba.
Mediante los mtodos de prueba de caja blanca, el ingeniero del software puede obtener casos de prueba que:
(1) Garanticen que se ejercita por lo menos una vez todos los caminos independientes de cada
mdulo
(2) ejerciten todas las decisiones lgicas en sus vertientes verdadera y falsa
(3) ejecuten todos los bucles en sus lmites y con sus lmites operacionales
(4) ejerciten las estructuras internas de datos para asegurar su validez.

PRUEBAS DE CAJA NEGRA

Las pruebas de caja negra, tambin denominada prueba de comportamiento, se centran en los requisitos
funcionales del software. Permite obtener conjuntos de condiciones de entrada que ejerciten completamente
todos los requisitos funcionales de un programa. La prueba de caja negra no es una alternativa a las tcnicas
de prueba de caja blanca. Ms bien se trata de un enfoque complementario que intenta descubrir diferentes
tipos de errores que los mtodos de caja blanca. La prueba de caja negra intenta encontrar errores de las
siguientes categoras:
(1) funciones incorrectas o ausentes
(2) errores de interfaz
(3) errores en estructuras de datos o en accesos a bases de datos externas
(4) errores de rendimiento
(5) errores de inicializacin y de terminacin.

A diferencia de la prueba de caja blanca, que se lleva a cabo previamente en el proceso de prueba, la prueba
de caja negra tiende a aplicarse durante fases posteriores de la prueba. Ya que la prueba de caja negra ignora
intencionadamente la estructura de control, centra su atencin en el campo de la informacin.

3. Caractersticas de un software con facilidad de prueba

La siguiente lista de comprobacin proporciona un conjunto de caractersticas que llevan a un software fcil
de probar:

Operatividad. Cuanto mejor funcione, ms eficientemente se puede probar.

El sistema tiene pocos errores (los errores aaden sobrecarga de anlisis y de generacin de informes
al proceso de prueba).
Ningn error bloquea la ejecucin de las pruebas.

Observabilidad. Lo que ves es lo que pruebas.

Se genera una salida distinta para cada entrada.

Todos los factores que afectan a los resultados estn visibles.
Un resultado incorrecto se identifica fcilmente.
Los errores internos se detectan automticamente a travs de mecanismos de auto-comprobacin.
Se informa automticamente de los errores internos.
El cdigo fuente es accesible

Controlabilidad. Cuanto mejor podamos controlar el software, ms se puede automatizar y optimizar.

Todos los resultados posibles se pueden generar a travs de alguna combinacin de entrada.
El ingeniero de pruebas puede controlar directamente los estados y las variables del hardware y del
software.
Los formatos de las entradas y los resultados son consistentes y estructurados.
Las pruebas pueden especificarse, automatizarse y reproducirse convenientemente.
Capacidad de descomposicin. Controlando el mbito de las pruebas, podemos aislar ms
rpidamente los problemas y llevar a cabo mejores pruebas de regresin.
El sistema software est construido con mdulos independientes.
Los mdulos del software se pueden probar independientemente

Simplicidad. Cuanto menos haya que probar, ms rpidamente podremos probarlo.

Simplicidad funcional (por ejemplo, el conjunto de caractersticas es el mnimo necesario para

cumplir los requisitos).
Simplicidad estructural (por ejemplo, la arquitectura es modularizada para limitar la propagacin de
fallos).
Simplicidad del cdigo (por ejemplo, se adopta un estndar de cdigo para facilitar la inspeccin y el
mantenimiento).

Estabilidad. Cuanto menos cambios, menos interrupciones a las pruebas.

Los cambios del software son infrecuentes.

Los cambios del software no invalidan las pruebas existentes.
El software se recupera bien de los fallos.

Facilidad de comprensin. Cuanta ms informacin tengamos, ms inteligentes sern las pruebas.

Mitos

El diseo se ha entendido perfectamente.

Las dependencias entre los componentes internos, externos y compartidos se han entendido
perfectamente.
La documentacin tcnica es instantneamente accesible.
La documentacin tcnica est bien organizada.
La documentacin tcnica es especfica y detallada.
La documentacin tcnica es exacta.
Los atributos sugeridos por Bach los puede emplear el ingeniero del software para desarrollar una
configuracin del software (por ejemplo, programas, datos y documentos) que pueda probarse.

 Mitos de Gestin
Mitos del cliente
Mitos de los desarrolladores
Mitos de gestin
Los gestores o administradores con responsabilidad sobre el proyecto de un sistema de software, como en la
mayora de las disciplinas, estn normalmente bajo la presin de cumplir los presupuestos, hacer que no se
retrase el proyecto y mejorar la calidad. Igual que se agarra al vaco una persona que se ahoga, un
administrador de un proyecto de software se agarra frecuentemente a un mito del software, aunque tal
creencia slo disminuya la presin temporalmente
Mito. Tenemos ya un libro que est lleno de estndares y procedimientos para construir software, no le
proporciona ya a mi gente todo lo que necesita saber?
Realidad. Est muy bien que el libro exista pero se usa? conoce el equipo de trabajo su existencia?
refleja las prcticas modernas de desarrollo de software? est diseado para mejorar el tiempo de entrega
mientras mantiene un enfoque de calidad? En muchos casos, la respuesta a todas estas preguntas es no.
Mito. Mi gente dispone de las herramientas de desarrollo de software ms avanzadas, despus de todo, les
compramos las computadoras ms modernas
Realidad. Se necesita mucho ms que el ltimo modelo de computadora para hacer desarrollo de software de
gran calidad. Las herramientas de ingeniera del software asistida por computadora (CASE) son ms
importantes que el hardware para conseguir buena calidad y productividad, aunque algunos desarrolladores
del software todava no las utilicen eficazmente.
Mitos del Cliente
Un cliente que solicita un sistema puede ser:
Una persona de la oficina de al lado
Un grupo tcnico de la oficina de abajo
El departamento de ventas
O una compaa exterior que solicita un sistema bajo contrato.

En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los gestores y
desarrolladores del software hacen muy poco para corregir la mala informacin. Los mitos conducen a que el
cliente se cree una falsa expectativa y, finalmente, quede insatisfecho con el que desarrolla el software
Mito. Una declaracin general de los objetivos es suficiente para comenzar el sistema podemos dar los
detalles ms adelante.
Realidad. Una mala definicin inicial es la principal causa del trabajo baldo en software. Es esencial una
descripcin formal y detallada del mbito de la informacin, funciones, comportamiento, rendimiento,
interfaces, ligaduras del diseo y criterios de validacin. Estas caractersticas pueden determinarse slo
despus de una exhaustiva comunicacin entre el cliente y el analista.
Mito. Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fcilmente,
ya que el software es flexible.
Realidad. Es verdad que los requisitos del software cambian, pero el impacto del cambio vara segn el
momento en que se introduzca. Los cambios pueden producir trastornos que requieran recursos adicionales e
importantes modificaciones del diseo; es decir, coste adicional.
Mitos de los desarrolladores.
Los mitos en los que an creen muchos desarrolladores se han ido fomentando durante 50 aos de cultura
informtica. Durante los primeros das del desarrollo de sistemas de software, la programacin se vea como
un arte.
Mito. Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado.
Realidad. Alguien dijo una vez: Cuanto ms pronto se comience a escribir cdigo, ms se tardar en
terminarlo. Algunos datos indican que entre el 60 y el 80 por ciento de todo el esfuerzo dedicado a un sistema,
se realizar despus de que se le haya entregado al cliente por primera vez
Mito. Hasta que no se tiene el programa ejecutndose, realmente no hay forma de comprobar su calidad.
Realidad. Desde el principio del proyecto se puede aplicar uno de los mecanismos ms efectivos para
garantizar la calidad del software: la revisin tcnica formal.
El anlisis y la gestin del riesgo
Un proyecto de sistemas puede estar lleno de problemas. Un riesgo es un problema potencial puede ocurrir o
no-.

Quienes deben estar involucrados en el proceso de anlisis y gestin de riesgo: administradores, ingenieros
de software, clientes
Pasos a seguir en el anlisis y gestin de riesgos:
1. Reconocimiento de que algo puede ir mal, esto es llamado identificacin del riesgo. Hay riesgos
obvios y riesgos adecuados
2. Anlisis: cada riesgo es analizado para determinar la probabilidad de que pueda ocurrir y el dao que
puede causar si ocurre.
3. Priorizacin: Una vez establecida esta informacin, se priorizan los riesgos, en funcin de la
probabilidad y del impacto.
4. Por ltimo, se desarrolla un plan para gestionar aquellos riesgos con gran probabilidad e impacto.
Tipos de Riesgo
1. Los riesgos del proyecto amenazan al plan del proyecto; es decir, si los riesgos del proyecto se hacen
realidad, es probable que la planificacin temporal del proyecto se retrase y que los costos aumenten Los
riesgos del proyecto identifican los problemas potenciales de presupuesto, planificacin temporal, personal
(asignacin y organizacin), recursos, cliente y requisitos y su impacto en un proyecto de software
2. Los riesgos tcnicos amenazan la calidad y la planificacin temporal del software que hay que producir. Si
un riesgo tcnico se convierte en realidad, la implementacin puede llegar a ser difcil o imposible. Los
riesgos tcnicos identifican problemas potenciales de diseo, implementacin, de interfaz, verificacin y de
mantenimiento
3. Los riesgos del negocio amenazan la viabilidad del software a construir. Los riesgos del negocio a menudo
ponen en peligro el proyecto o el producto. Los candidatos para los cinco principales riesgos del negocio son:
(1) construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de mercado)
(2) construir un producto que no encaja en la estrategia comercial general de la compaa (riesgo
estratgico)
(3) construir un producto que el departamento de ventas no sabe cmo vender;
(4) perder el apoyo de una gestin experta debido a cambios de enfoque o a cambios de personal
(riesgo de direccin);
(5) perder presupuesto o personal asignado (riesgos de presupuesto).

4. Los riesgos conocidos son todos aquellos que se pueden descubrir despus de una cuidadosa evaluacin del
plan del proyecto, del entorno tcnico y comercial en el que se desarrolla el proyecto y otras fuentes de
informacin fiables (por ejemplo: fechas de entrega poco realistas, falta de especificacin de requisitos o de
mbito del software, o un entorno pobre de desarrollo).
5. Los riesgos predecibles se extrapolan de la experiencia en proyectos anteriores (por ejemplo: cambio de
personal, mala comunicacin con el cliente, disminucin del esfuerzo del personal a medida que atienden
peticiones de mantenimiento).
6. Los riesgos impredecibles son el comodn de la baraja. Pueden ocurrir, pero son extremadamente difciles
de identificar por adelantado
A partir de esto se genera un Plan de Reduccin, Supervisin y Gestin del Riesgo (RSGR) o un informe de
riesgos.