Mauro:
Puedo contarte mi experiencia en un grupo de Calidad en la
industria financiera (Banco "Top-Of-Mind") , quizás desde allí puedas
hacerte una composición de lugar y armar tu propia experiencia.
En principio hay que considerar dos aspectos diferentes que
son: "Quality Control" (Foco en Testing) y "Quality Assurance" (Foco
en Procesos) Lo recomendable en ambos casos es comenzar con un
piloto, es decir seleccionar un aplicativo y aplicar ambos conceptos
para poder utilizar algún conceptos similar al propuesto por Carnagie-
Mellon denominado "IDEAL" (Initiating, Diagnosing, Establishing,
Acting, Lerning).
En cuanto a Quality Control, nosotros tenemos dos situaciones:
Nuevos Desarrollos y Mantenimiento. Las pruebas de nuevos desarrollos
llevan considerablemente más tiempo y lo recomendable es inciar el
diseño de la prueba conjuntamente con el desarrollo tratando de
utilizar algo que en testing se llama Modelo "V" (no te cuento el
modelo porque en Internet seguramente vas a encontrar muchísimo
material de este tema). Para los aplicativos en ciclo de
mantenimiento, nosotros estamos tratando de comenzar utilizando un
concepto propio basado en el "Risk-Based Testing" y también vas a
encontrar mucho en la red, nosotros estamos tratando de entender la
granularidad transaccional para identificar tipos de transacciones de
negocio y ir avanzando en el porcentual de cobertura para asegurar
que la transaccionalidad crítica esté cubierta y darle además a los
sectores de negocio una garantía de que el 90% de las transacciones
de producción han sido probadas antes de pasar a producción
utilizando robots para ello.
En cuanto a Quality Assurance, lo que hicimos es identificar
atributos de calidad del producto y verificar que los mismos estén
siendo cubiertos en la medida de lo requerido por los estándares de
calidad. Hecho esto dentro de los distintos artefactos. Por Ejemplo,
en un documento de "acuerdo de proyecto" se encuentren todos los
involucrados definidos y notificados. Otro ejemplo: Que los scanners
de código no hayan identificado en los programas el uso de sentencias
no permitidas. Un último Ejemplo: Que se haya realizado al menos
una "Revisión de Pares" en el componénte crítico para detectar
proactivamente defectos en los componenetes (algunos lo llaman
Testing Dinámico). Los desvíos a estos son tratados como "Incidentes
del Proceso" de un modo similar a los defectos de componentes de Soft
es decir se les asigna una severidad y criticidad de acuerdo al
incidente evaluado. Se hace un scoring del paquete documental y si
está sobre el nivel mínimo exigible puede continuar con la otra fase
pero los incidentes de una fase deben ser cerrados antes de pasar a
la etapa subsiguiente.
Una vez que hayas hecho el piloto, podés replicarlo a otras
aplicaciones. En nuestra organización no probamos todas los
aplicativos, tenemos una política escrita y acordada con la dirección
que nos dice cuales son los aplicativos que probamos y además
contiene todos estos aspectos que te estoy contando.
Por supuesto, esto que te cuento es solo una experiencia de
campo de por sí mejorable y estoy seguro que habrá otras tantos
modelos de aplicación como organizaciones existan. Espero te sea de
Utilidad.
Saludos
--- En AsegCalidadSoftware@..., Mauro Agustinelli
<mause76@y...> escribió:
> Gente: En la empresa en la cual trabajo, están
> interesados a comenzar a darle importancia a la
> "Calidad" del software.
> Para mi es un tema totalmente desconocido.
> Alguien de ustedes podría decirme como se encara este
> tema, metodologias que existen, pasos que hay que
> seguir, o todo lo que hay que tener en cuenta para
> certificar ciertas normas de calidad en un producto de
> software.
> Si disponen de bibliografia se los agradezco.
>
> Gracias
> Saludos, Mauro.-
>
>
>
> __________________________________________________
> Correo Yahoo!
> Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
> Regístrate ya - http://correo.espanol.yahoo.com/