Propsitos de la calidad del Software:

-obtencin de un software con calidad implica la utilizacin de metodologas

o procedimientos estndares para el anlisis,diseo, programacin y prueba del software que
permitan uniformar la filosofa de trabajo, en aras de lograr una mayor confiabilidad,
mantenibilidad y facilidad de prueba
-Elevar la productividad, tanto para la labor de desarrollo como para el control de la calidad
del software.
-Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con los
requisitos es una falta de calidad.
-Los estndares o metodologas definen un conjunto de criterios de desarrollo que guan la forma
en que se aplica la ingeniera del software. Si no se sigue ninguna metodologa siempre habr falta
de calidad.
Existen algunos requisitos implcitos o expectativas que a menudo no se mencionan, o se
mencionan de forma incompleta (por ejemplo el deseo de un buen mantenimiento) que tambin
pueden implicar una falta de calidad.
La poltica establecida debe estar sustentada sobre tres principios bsicos: tecnolgico,
administrativo y ergonmico.
El principio tecnolgico define las tcnicas a utilizar en el proceso de desarrollo del software.
El principio administrativo contempla las funciones de planificacin y control del desarrollo
del software, as como la organizacin del ambiente o centro de ingeniera de software.
El principio ergonmico define la interfaz entre el usuario y el ambiente automatizado.
La adopcin de una buena poltica contribuye en gran medida a lograr la calidad del software, pero
no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluacin.

Errores en el desarrollo del software

Muchas veces, en alguna conversacin referente a algn proyecto software, cuando alguien nos
pide una opinin, en alguna charla o cuando estudiamos los riesgos de algn proyecto, suele salir
la lista de errores clsicos de McConnell. Debido al uso y utilidad de la misma, me ha parecido
interesante dejarla resumirda en este post.
En 1996 Steve McConnell public el libro Rapid Development, en mi opinin uno de los mejores
libros que se han escrito en lo que refiere a la gestin de proyectos software, en el que introduca
el concepto error clsico del desarrollo software.
McConnell defini a los errores clsicos como aquellos que se han repetido tantas veces, y por
tanta gente, que debieran ser previsibles y siempre se deberan gestionar. El libro describa 36
errores clsicos, que en 2007 se ampliaron a 42, sobre los que se realiz una encuesta sobre
aproximadamente 500 profesionales con el objetivo de determinar su frecuencia y gravedad.
A continuacin os resumo los errores que ocurren con mayor frecuencia, los que ocurren con
menor frecuencia y los que de ocurrir tienen ms impacto:
Errores que ocurren con mayor frecuencia
1. Planificaciones demasiado optimistas
2. Expectativas no realistas (o pedirle a un proyecto algo imposible)
3. Excesivas tareas (cuando, por ejemplo, los desarrolladores estn en muchos proyectos a la
vez)
4. Insuficiente aseguramiento de la calidad
5. Oficinas ruidosas
6. Incorporacin de caractersticas (por ejemplo, introducir nuevos requisitos a mitad de
proyecto)
7. Hacerse ilusiones (por ejemplo, cerrar los ojos a lo que se nos viene encima)
8. Gestin del riesgo insuficiente
9. Confundir estimaciones con objetivos (cuando por ejemplo el objetivo es tener el software en
3 meses, y de ah se fija que el desarrollo sern 3 meses)
10. Omitir tareas relacionadas con la estimacin (no guardar histricos para realizar mejores
estimaciones, al estimar obviar tareas como son las reuniones, etc.)
Errores que ocurren con menor frecuencia
1. Cambio de herramientas en mitad del proyecto
2. Falta de control automatizado del cdigo fuente
3. Desarrollo dirigido por la investigacin
4. Convergencia prematura o muy frecuente (forzar el cierre de una versin antes de que sea
posible)
5. Estimar obviando el uso de nuevas herramientas o mtodos (obviando, por ejemplo, el coste
de aprendizaje)
6. Negociaciones y el tira y afloja (entre, por ejemplo, desarrollo y comerciales)
7. El sndrome de la bala de plata
8. Errores en la subcontratacin
9. Llevar al equipo en la oscuridad (cuando, por ejemplo, los jefes de proyecto ocultan al equipo
el avance y plan de proyecto)
10. Problemas con el equipo
Errores que provocan problemas de mayor impacto
1. Expectativas no realistas (o pedirle a un proyecto algo imposible)
2. Equipo poco preparado
3. Planificaciones demasiado optimistas
4. Hacerse ilusiones (por ejemplo, cerrar los ojos a lo que se nos viene encima)
5. Insuficiente aseguramiento de la calidad
6. Diseo inadecuado
7. Falta de apoyo al proyecto
8. Confundir estimaciones con objetivos (cuando por ejemplo el objetivo es tener el software en
3 meses, y de ah se fija que el desarrollo sern 3 meses)
9. Excesivas tareas (cuando, por ejemplo, los desarrolladores estn en muchos proyectos a la
vez)
10. Falta de involucracin del usuario

Caractersticas especiales del software
El software es un producto que se puede distribuir de varias maneras. De forma clsica se
hace mediante una instalacin directa en equipos del cliente. Normalmente, si alguien quiere
usar una aplicacin de ventas, compra el CD-producto de instalacin, ejecuta un programa de
configuracin, da sus claves y, de este modo, puede comenzar a utilizar el sistema. Pero si
el usuario necesita que otra persona al extremo del globo terrqueo consulte su lista de
clientes, o de cobros pendientes, o de precios, y los quisiera manipular con el mismo software,
necesitara otro CD-producto, o necesitara bajar ese programa ejecutable de la web, y
generalmente necesitara otra licencia para ese producto, o hacer uso de una VPN, o
comunicarse mediante correo electrnico con la sede de operaciones. En cambio, si el
software est modelado como servicio, los requerimientos pueden ser mucho ms simples.
Las caractersticas del software como servicio incluyen:
Acceso y administracin a travs de una red.
Actividades gestionadas desde ubicaciones centrales, en lugar de la sede de cada cliente,
permitindoles tener acceso remoto a las aplicaciones a travs de la web.
La distribucin de la aplicacin es ms cercana al modelo uno-a-muchos (una instancia
con mltiples usuarios) que al modelo uno-a-uno, incluyendo arquitectura, precios,
colaboracin, y administracin.
Actualizaciones centralizadas, lo cual elimina la necesidad de descargar parches por parte
de los usuarios finales.
Frecuente integracin con una red mayor de software de comunicacin, bien como parte
de un mashup o como un enlace para una plataforma como servicio.

Visin de la calidad
Necesaria o requerida: La que quiere el cliente o usuario.
Programada o especificada: La que se intenta conseguir.
Realizada: la que es capaz de obtener la persona que hace el trabajo
Calidad percibida: La interseccin entre la calidad requerida y la realizada. Es la que el
cliente valora
El objetivo es conseguir que las tres visiones coincidan, para lograr una percepcin de
mayor calidad