Archivo para la categoría Calidad

Requisitos legales

Se le llama requisitos legales a aquellas condiciones, impuestas por ley, que deban ser cumplidas por el proyecto, ya sea en la ejecución del proyecto como tal o en la funcionalidad provista por el sistema terminado. Los requisitos legales nacen de las leyes vigentes y que apliquen a nuestro proyecto de desarrollado ya sea por su naturaleza o por la jurisdicción bajo la cual se encuentra nuestra empresa.

Los requisitos legales surgidos por la naturaleza de nuestro proyecto, son aquellas obligaciones legales que puedan existir para ciertos tipos de aplicaciones. Son ejemplos comunes: las aplicaciones bancarias, los sistemas electorales y aquellos sistemas que manejen información privada del publico.

Las aplicaciones bancarias se encuentran sometidas a una amplia gama de requisitos legales. Tanto de confidencialidad como de confiabilidad en las transacciones. Se suele incluir en la legislación de muchos países aspectos tales como los registros de las operaciones, la interoperatividad de los sistemas, la criptografía a utilizar y las garantías de correcto funcionamiento.

Un poco más recientes, son las aplicaciones para sistemas electorales. En algunos países de la región así como en algunas jurisdicciones locales en los Estados Unidos, se han comenzado a utilizar sistemas de voto electrónico, ya sea en sustitución de las votaciones manuales o como complemento de estas en casos específicos. Como es natural esperar, los procesos de votación electrónica han de contar con gran cantidad de partes interesadas o stakeholders, razón esta por la cual hay grandes requerimientos de transparencia, confiabilidad y exactitud exigidos a estos sistemas por la ley y los reglamentos respectivos.

Incluso en aplicaciones más comunes pueden existir requisitos legales a considerar. Aquellos sistemas que recojan información de sus usuarios y que a la vez, permitan el registro del publico general como usuarios de las mismas, suelen estar sometidas a regulaciones sobre la seguridad de los datos.

Una variación también muy común es la de restringir el registro de menores de edad, por así requirlo las leyes de defensa de los niños u otros grupos protegidos.

Los requisitos legales surgidos por la jurisdicción son una matería de amplia discusión en estos días de Internet. En los viejos días era fácil identificar la jurisdicción competente, pues esta coincidia con el área geografica en que se ubicaba nuestra empresa. Hoy en día en cambio, es necesario considerar jurisdicciones adicionales, ya que nuestros productos pueden ser utilizados en otros países con más facilidad que nunca antes, y el incumplir con los eventuales requisitos legales de otras jurisdicciones pueden causar problemas con la comercialización de nuestras aplicaciones.

Todo esto significa que en aplicaciones de gran escala es conveniente obtener asesoría legal de parte de un escritorio juridico o abogado, tomando lo que este nos indique como requisitos funcionales o no funcionales, según sea el caso.

Anuncios

, , , , , ,

3 comentarios

Definimos Terminos de Referencia como…

De tanto en tanto nos vamos a encontrar con que la organización que requiere el desarrollo elabora para nosotros un documento de requisitos, en formato libre, al que llaman no sin cierto orgullo “Términos de Referencia”. La práctica viene de otras áreas de la ingeniería donde una petición simple de parte del cliente puede ser analizada y convertida en un trabajo completo, con un razonable nivel de calidad.

Sin embargo, en Ingeniería del Software los términos de referencia no pueden ser utilizados con buenos resultados. Típicamente son documentos incompletos, que mezclan requisitos con análisis e incluso con diseño, cuya existencia es señal de acceso limitado a los stakeholders por parte de la organización de desarrollo. En otras palabras: si nos dan Términos de Referencia tendremos problemas más adelante.

El acto de especificar un sistema de software a demostrado repetidamente ser difícil. Es necesario indicar un gran número de aspectos distintos, mantener la diferencia entre requisito y solución, actuar primero a lo ancho, capturar valor de negocio, entre otros puntos que son propios de nuestra profesión y que resultan incompatibles con las premisas detrás de un documento de términos de referencia.

Veamos algunos de estos puntos en detalle. Comencemos por la definición:

Términos de Referencia: Documento elaborado por el cliente con indicaciones de las especificaciones requeridas al sistema de software por desarrollar.

En otras palabras: en un documento de Términos de Referencia el cliente ha querido ahorrarnos a nosotros el trabajo de especificación. Muy amable de su parte, pero si la organización de desarrollo no interviene en la especificación entonces nos enfrentamos a varios problemas:

  • Se ha asumido un modelo de ciclo de vida en cascada. Los modelos actuales son iterativos, repitiendo múltiples veces el paso de especificación. Un esquema más rígido, como el cascada, suele incrementar el riesgo de fracaso del proyecto.
  • Si el cliente siente que ya ha desarrollado los requisitos a satisfacción puede verse renuente a dedicar esfuerzos nuevos en este asunto. Tendríamos entonces problemas al presupuestar horas para actividades de elicitación de requisitos.
  • El documento en si mismo es un problema. Su estructura es necesariamente ad-hoc, independiente de la metodología que se vaya a seguir en el desarrollo. Puede ser difícil de analizar y haber dejado puntos importantes por fuera.

Si solo fuera para tener una idea del proyecto, básicamente cualquier documento o carta es bueno. Sin embargo los términos de referencia vienen con intenciones más amplias: sustituir la especificación profesional por un único documento, valido para el desarrollo así como para el cálculo de la oferta económica. No importa como lo vea, los términos de referencia son un problema.

Sin embargo, los Términos de Referencia son también un hecho. En algunas situaciones incluso son lógicos: en las licitaciones se distribuyen especificaciones para acto seguido requerir ofertas de costo cerrado. Si esto funciona bien en tantos sectores distintos, el cliente puede pensar que ha de valer también para sus proyectos de software.

Por lo anterior será inevitable que nos topemos con estos documentos. Tendremos que desarrollar entonces alguna técnica para sacar el mayor provecho de los mismos, sin importar cuan diferentes sean de caso en caso y de cliente en cliente. A fin de cuentas ellos son el cliente, y uno no puede ser tan descortez de desachar los resultados de su trabajo.

Finalmente me gustaría recordar que todos sin excepción hemos luchado con los términos de referencia de nuestros profesores y preparadores. ¿Cuantas veces en nuestros estudios tuvimos que llevar a cabo un proyecto a partir de un breve enunciado carente de toda norma de calidad? Así como entonces fue difícil producir un programa autenticamente útil a partir de dichas especifiones, aquí nos va a costar mucho trabajo en conseguir satisfacer el cliente si nos atenemos unicamente a lo dicho en los malvados, digo, en los variables Términos de Referencia.

, , , , , , , ,

3 comentarios

Definimos retrabajo como…

La elaboración de un diseño o producto, conforme a unas especificaciones conocidas, da lugar a la posibilidad de fallar en el cumplimiento de lo requerido. Toda diferencia entre lo que se nos pidió y lo que estamos entregando como resultado de nuestro trabajo es considerado un fallo de calidad y se le suele llamar inconformidad.

Si la inconformidad es muy grave y compromete la aceptación del producto por parte del cliente, es necesario dedicar esfuerzos adicionales en lograr que el producto sea conforme a lo especificado. A este esfuerzo adicional es a lo que llamamos retrabajo.

Técnicamente como para el glosario:

Inconformidad. Fallo de calidad definido como la desviación del producto de su especificación.

Y también:

Retrabajo. Esfuerzo adicional necesario para la corrección de una inconformidad en algún producto.

El problema que surge con el retrabajo es obvio: es un esfuerzo adicional que no puede en buena lid ser cobrado al cliente, pero que es necesario para que este quede conforme con lo que hemos hecho para él. La idea es entonces minimizar la cantidad de retrabajo en el que incurramos, objetivo deseado pero dificil de lograr sin un adecuado sistema de gestión de calidad.

, , , , , , , ,

Deja un comentario

Capacidades y Competencias

Cualquier organización, sin importar su área de trabajo, puede ser modelada como un conjunto de procesos, que buscan elaborar uno o más productos que estén de acuerdo con las especificaciones dadas. Esta definición abarca no solo a las empresas de software dedicadas al desarrollo, sino también a las dedicadas al servicio, a la adquisición o a la consultoría.

Incluso es posible pensar que la definición dada abarca a todas las organizaciones, sin importar si de dedican al software o no, sin importar si se dedican a la manufactura o al sector servicios e incluso, sin importar si se dedican a la búsqueda de un beneficio económico o por el contrario son una entidad estatal o de beneficencia. Todas las organizaciones persiguen objetivos, los cuales pueden ser caracterizados como productos de procesos realizados en conformidad con las metas y especificaciones dadas.

Entonces, podemos definir sobre esta búsqueda de la calidad, los siguientes dos conceptos:

Capacidad: habilidad de la organización, sistema o proceso, para realizar un producto que cumpla con sus requisitos. (ISO 3534-2)

Y también

Competencia: capacidad demostrada de aplicar conocimiento y habilidades. (ISO 19011)

Nuestras organizaciones deben contar con competencias suficientes para competir en el mercado, de lo contrario quedarán fuera de este. De ahí entonces, que el desarrollo de dichas competencias sea un interés constante en la dirección estratégica de toda organización, en particular de aquellas dedicadas al desarrollo de software.

Lo que llamamos mejores prácticas o simplemente prácticas, son referencias a las distintas capacidades que se han identificado como presentes en las organizaciones con éxito; complementadas cada una con la descripción de sus objetivos y productos típicos.

Existen gran variedad de mejores prácticas, por lo que en la industria han surgido varios esfuerzos por organizar estas en paquetes que faciliten su estudio y de ser posible, su asimilación por nuestras organizaciones. El objetivo de dichos paquetes de mejores prácticas, es la de establecer una ruta de mejora de los procesos, que vaya desde lo simple a lo más complejo, dando así una guía para los esfuerzos de mejorar que iniciemos.

, , , , , , , ,

Deja un comentario

Control de Calidad: Revisión de Forma

Como parte de todo proceso de control de calidad es necesario verificar primero la forma de los artefactos puestos a revisión antes de poder ir al fondo de lo expresado en ellos.

Esta revisión de forma toca entre otros puntos, los siguientes:

  • Buen uso del idioma español: redacción, ortografía, puntuación; tal como en la escuela.
  • Buen uso del vocabulario técnico común.
  • Buen uso del lenguaje UML.
  • Respeto de la estructura de las plantillas utilizadas.
  • Presentación de los documentos.
  • Uso de logotipos e imagen corporativa.
  • Cualquier otro aspecto general de los artefactos.

Según lo que se diga en el Plan de Control de Calidad del proyecto, esta tarea será realizada con mayor o menor frecuencia, pero ciertamente es necesario que sea realizada de tanto en tanto incluso en proyectos muy pequeños, ya que un documento con faltas de ortografía o que confunda el significado de palabras comunes ciertamente va a ser rechazado por cualquier cliente.

La siguiente ilustración muestra la tarea:

Revisión de Forma de Artefactos
Fig. 1 – Diagrama SPEM de la Tarea Revisión de Forma de Artefactos

Una nota para los proyectos muy pequeños: recordemos que un rol puede ser asumido por cualquier persona en la organización, no necesariamente es una persona dedicada solo a cumplir con ese rol; por lo cual es posible instruir a una secretaria o personal no técnico que tenga algo de tiempo que pueda dedicarse a la revisión de forma de los documentos. Claro que para verificar el buen uso del UML ha de contar con algo de instrucción técnica, pero la ortografía y la claridad de la redacción pueden ser verificados con facilidad por personal de una formación distinta de la ingeniería del software.

, , , , , ,

Deja un comentario

Modelo de Calidad Tradicional del Software

Anteriormente había comentado que intentar establecer de antemano las propiedades que un sistema de software debe cumplir para satisfacer a los clientes y usuarios es llamado Modelo de Calidad y que en concreto este era un instrumento útil para saber que preguntar ante un sistema nuevo. Sin embargo hay que apuntar aquí siempre, y así lo hago, que el concepto de calidad debe ser relativo a cada organización de desarrollo y que debe ser perseguida no por medio de una lista de comprobación común a toda la industria sino por medio de algún mecanismo o procedimiento apropiadamente diseñado y sobre el cual se pueda discutir objetivamente con ayuda de algún plan.

Ahora eso sí, no por eso debemos dejar de conocer cual es ese modelo de calidad tradicionalmente aplicado al software, ya que es parte de la profesión y como buenos profesionales nos sirve de mucho el conocerlo.

El problema me surgió cuando intente encontrar una lista de estas cualidades. La verdad sea dicha, la ultima vez que la vi fue hace ya varios años; por lo que he intentado encontrar una lista apropiada aún si es informal, en la Internet.

Con mucha diferencia, la mejor de tales listas es la presentada por mcarrillo en su blog http://mcarrillo.wordpress.com/ en el post titulado Factores de la calidad del software donde nos menciona las siguientes cualidades o factores de calidad:

  1. Eficiencia: La eficiencia de un software es su capacidad para hacer un buen uso de los recursos del ordenador.
  2. Portabilidad: Es la facilidad con la que un software puede ser transportado sobre diferentes sistemas físicos o lógicos.
  3. Fácil de usar: Cuando el usuario puede comunicarse con él de manera cómoda.
  4. Compatibilidad: Facilidad de los productos para ser combinados con otros y usados en diferentes plataformas hardware o software.
  5. Corrección: Facilidad para solucionar los problemas que puedan presentarse.
  6. Extensibilidad: Facilidad que tiene los productos de adaptarse a cambios en su especificación.
  7. Robustez: Capacidad que tiene los productos de software de funcionar incluso en situaciones anormales.
  8. Verificabilidad: Es la facilidad de verificación de un software, es decir, probar que el software funcione correctamente.
  9. Reutilización: Capacidad de los productos de ser reutilizados, en su totalidad o en parte, en nuevas aplicaciones.
  10. Integridad: Es la capacidad de un software de proteger sus propios componentes contra los procesos que no tengan el derecho de acceder.

Dichas cualidades se sabe que están presentes o debieran de estar presentes, en todo software de calidad. En cierta forma, al igual que con todos los modelos de calidad industriales, la lista es el resultado de la experiencia acumulada por el sector y tiene por detrás cierto nivel de teoría.

Así que valga la lista como referencia para cosas futuras.

, , , , ,

4 comentarios

Control de Calidad: Trazas

La moderna practica de la ingeniería del software se basa en la construcción de modelos que capturen progresivamente, el avance desde los requisitos al diseño y eventualmente, a la implementación y despliegue de la solución final. Esto representa un reto importante desde el punto de vista de la calidad ya que ha de existir alguna manera de seguir la pista de como se ha elaborado lo requerido a través de los múltiples modelos, hasta esa deseada implementación ejecutable.

La solución a este reto son las llamadas Trazas. A lo largo de los modelos, mantendremos notas y relaciones de realización de los casos de uso; de manera de seguir la pista de como se han dado solución a lo planteado como requisito. Es de observarse que las trazas son quizás, la única forma sistemática de comprobar que el proceso de desarrollo no ha tomado un camino propio y terminado por desarrollar algo diferente a lo solicitado.

Entonces, para el glosario:

Trazas. Indicaciones sobre la realización de los artefactos de un proyecto; indican la forma en que los artefactos se han elaborado respetando la información contenida en otros artefactos, generalmente de requisitos o previos en el proceso de desarrollo.

Las trazas son pues, un artificio de control que sigue la elaboración de modelos y artefactos a partir de lo indicado en algún otro documento. Es responsabilidad de todos en el proyecto de asegurar el fiel y cabal cumplimiento de lo requerido, por lo que también es necesario que todos se involucren en mantener las trazas entre los artefactos.

En lo que a los modelos se refiere, las trazas pueden adoptar la forma de un diagrama de paquetes, que muestre las trazas como dependencias estereotipadas de UML entre los modelos, aquí representados a su vez, como paquetes estereotipados. El siguiente diagrama ilustra el punto:

Ejemplo simple de trazas entre modelos UML

Fig. 1 – Ejemplo de Trazas entre Modelos UML

Por otra parte, en cuanto a los documentos, la forma más simple es la de mantener un anexo o apartado en cada documento, donde se indique cual documento con su número de versión y fecha, a sido tomado como insumo y a su vez, cuales son los documentos derivados que están en uso en el proyecto. La siguiente tabla muestra un ejemplo de esto:

Título del documento: Documento de Visión – v2.0 al 15 de mayo de 2008.
Responsable del documento: Iván Garcerant.
Documentos de insumo: Términos de Referencia – v1.0 al 20 de enero de 2008.
Documentos derivados: Modelo de Casos de Uso y Especificación de Requisitos Suplementarios.

Tabla 1 – Ejemplo de Trazas de Documento

Lo ultimo que vale la pena comentar, es que las trazas son auditadas por el equipo de Control de Calidad[*] (Software Quality Control – SQC) quienes se guían por estas para comprobar el buen estado del proyecto, en tanto que el sistema de trazas es diseñado por el equipo de Aseguramiento de Calidad[*] (Software Quality Assurence – SQA) como parte del diseño del proceso de desarrollo.

Entonces una vez más como conclusión: Las trazas son dependencias entre los artefactos, que indican la forma en que la información fluye por ellos, desde los requisitos hasta el diseño y la implementación; en UML podemos indicar trazas por medio de dependencias estereotipadas en tanto que en los documentos podemos hacer un aparte o anexo con esta información.

Es todo por hoy.

, , , , , , , ,

3 comentarios