CONFERENCIA: CALIDAD DE SOFTWARE Y GESTIN DE CONOCIMIENTO.

PONENTE: Jess Rojas Hernndez. Consultor T.I.

DEFINICIN:
I do not worry whether something is cheap or expensive. I only worry if it is good. If
it is good enough, the public will pay back for it. Walt Disney.

La calidad es relativa a las personas, a la edad, a las circunstancias y el tiempo ya
que el concepto y la perspectiva evoluciona.
VISTAS DE CALIDAD
Trascendental (calidad = excelencia innata).
Basada en usuario (adecuacin al propsito).
Basada en el fabricante (conformidad con requisitos).
Basada en el producto (econmica).
Basada en el valor (precio asequible).

Se recomienda dedicar el 50% del tiempo total para la planeacin del proyecto, el
20% para el desarrollo y 30% para el mantenimiento.

Entidades certificadoras (ISO, IEEE, etc.)
Se revisaron conceptos de calidad de los autores que revisamos en clase y de
EOQ y Drucker.
Existe un teorema que dice que ningn sistema puede tener cero defectos.
El concepto de calidad no es absoluto, no est sujeto a restricciones y trata
compromisos aceptables.

G
E
S
T
I

N

D
E

L
A

C
A
L
I
D
A
D

PROGRAMADA
REALIZADA
NECESARIA

MEJORA DE LA CALIDAD
- Nivel individual PSP.
- Nivel empresa/organizacin.
- Nivel proyecto.

Uno de los errores es adaptar la necesidad que surge a lo que dicen los libros. Lo
correcto es adaptar lo que dice el libro a la necesidad.

COMPONENTES DE SISTEMA DE CALIDAD
- Documentacin: describe el sistema, procedimiento, ajustndose a una
norma.
o Manual de calidad.
o Procedimientos de calidad.
o Registros de datos sobre la calidad.
- Parte prctica:
o Aspectos fsicos (locales, herramientas, computadoras).
o Aspectos humanos (formacin de personal a todos los niveles).

Las pruebas contribuyen a mejorar la fiabilidad pero no la garantizan totalmente
debido a diversos factores. La fiabilidad est influenciada por procesos de
desarrollo, pero no hay relacin simple entre fiabilidad del producto y la del
proceso.
A veces los sistemas no se ajustan a las necesidades del usuario incluso estando
bien hechos.

MODELOS DE PROCESOS CLSICOS VS GILES (No planear, no documentar,
se elige si el tamao de proyecto es pequeo. P.e. SCRUM, Lean, Kanban).

BUENAS PRCTICAS MALAS PRCTICAS
Comentar cdigo. No describir qu se hace.
Documentar pendientes e incidencias. No poner bien los nombres donde
se describe lo que hace una
funcin.
Manual de BD siguiendo patrn. Confiar en que el cliente define bien
los requerimientos.
No seguir reglas.