El
Enfoque hacia el Producto
El ingeniero de software, ante todo, necesita
determinar el Objetivo verdadero del software. En cuanto a esto, es de capital importancia tener
presente los requerimientos del cliente y aquellos que estos incluyen como
requerimientos de calidad, no únicamente los requerimientos funcionales.
Así, el ingeniero de software
tiene como responsabilidad obtener los requerimientos de calidad, que pueden no
estar explícitos en un principio, tratar su importancia así como el nivel
dificultad para alcanzarlos
Todos los procesos asociados a la Calidad de software
(como por ejemplo, construcción, pruebas, mejora de la calidad) serán diseñados
con estas exigencias en mente, y ello conlleva gastos adicionales.
La calidad de un producto no se
limita a su confiabilidad o corrección, aunque ésta debería estar en
consonancia con el precio y el uso de la aplicación de este software. Atañe a aspectos de similar importancia a la
confiabilidad, como la seguridad del producto, de sus partes, cada vez más
importante en tanto y cuanto una parte del software actual se realiza mediante
la composición de componentes proporcionados bien por el programador, bien por
el sistema de desarrollo, bien suministrado por terceros.
Otros aspectos fundamentales de la calidad de un
producto de software son la facilidad de utilización por los usuarios
esperados, las prestaciones ofrecidas por las aplicaciones, la adaptación a su
mantenimiento y producción de nuevas versiones, la flexibilidad y la
transportabilidad a sistemas hardware/software diferentes, etc.
Una de las acepciones más
utilizadas de la calidad es la relacionada con modelos de aseguramiento tipo
ISO 9000.
El concepto se orienta más a
predecir la calidad (sea la que sea) del producto final mediante el control de
las tareas para su realización y, sobretodo su registro. De esta forma, si el producto final no responde a
nuestros criterios de calidad (lo esperado, no lo deseable), podemos saber en
qué punto del proceso se produjo un error y subsanarlo.
El estándar ISO/IEC 9126-01 define, para dos de sus
tres modelos de calidad, características de calidad, Sub-características, y las
medidas que son útiles para Evaluación de calidad de producto de software.
El significado del término
"producto" es ampliado para incluir cualquier artefacto que es la
salida de cualquier proceso empleado para construir el producto de software
final. Como ejemplos de un producto cabe incluir, aunque no con carácter
limitativo, una completa especificación del sistema, una especificación de
requerimientos de software para un componente de software de un sistema, un
módulo de diseño, código, documentación de prueba, o los informes producidos
como consecuencia de tareas de análisis de calidad.
Enfoque
hacia el proceso
Mientras la mayor parte del tratamiento de la calidad
es descrito en términos del software final y funcionamiento del sistema, una
ingeniería práctica responsable requiere que los productos intermedios
relevantes para la calidad sean evaluados a lo largo de todo el proceso de
ingeniería de software. Las metodologías de desarrollo nos ayudan a realizar
este proceso (el de desarrollo) reglado y prefijado para conseguir productos
adecuados.
No se entiende un concepto como el de Fábrica de
Software sin la asociación con el concepto de tareas repetibles, planificables,
organizadas, igual que no se entiende una fábrica como un conjunto de tareas
anárquicas, sin control ni organización. Dentro de la Ingeniería de Software existen multitud
de metodologías para el desarrollo de productos de software. Incluso, cada país suele tener su versión de
metodología obligatoria (normalmente en lo relativo a los aspectos formales
orientados a la documentación) en los productos de administración pública.
La orientación adecuada consiste
en partir de una metodología de desarrollo suficientemente contrastada y
admitida, personalizada para la propia organización pero sin pérdida de la
generalidad de la misma (lo que consiguen muchas personalizaciones es la
pérdida de la eficiencia de la metodología).
Un proceso de desarrollo de software determina quién
debe hacer qué, cuándo y cómo. Un proceso de software define la forma en que se
organiza el trabajo de un equipo de desarrollo y otros grupos de apoyo.
Son las actividades que se
realizan siguiendo métodos y técnicas para desarrollar un producto de software. El proceso de desarrollo recibe como entrada
requisitos nuevos o modificados y genera un sistema nuevo o modificado.
Los procesos de software difícilmente
se inventan desde cero, más bien recogen las mejores prácticas y experiencias
de los que han tenido éxito en el desarrollo de software.
Actualmente, disponemos de una serie de modelos
generados por consenso entre profesionistas, que podemos tomar como modelos de
referencia. Los
ejemplos más destacados de estos modelos el CMM-SW, el CMMI, el ISO/IEC 12207 e
ISO/IEC 15504. La
confianza en estos modelos se debe al hecho de que fueron sustraídos de las
experiencias de varias empresas y de muchos proyectos exitosos desarrollados
anteriormente.Los modelos de referencia mencionados muestran, que para tener
éxito en el proceso de desarrollo de software hay que darle la debida
importancia no solamente a los aspectos técnicos, sino también a los aspectos
de gestión de un proyecto.
Una organización que quiera medir la calidad, o usando
los términos de los modelos, la capacidad y/o madurez de sus procesos, puede
comparar su forma de trabajar con respecto a lo que sugieren estos modelos. Esto se conoce como evaluación de procesos (Process Assessment). Esencialmente el proceso está definido por un modelo
de proceso junto con la definición de artefactos, actividades y roles.
El modelo de proceso se base en uno o más de los
siguientes enfoques: codificar y reparar (code-and-fix), modelo en
cascada, desarrollo evolutivo, desarrollo formal (paradigma de programación
automática) y desarrollo basado en componentes. Además, existe consenso respecto a que el proceso de
desarrollo debe ser iterativo. En este sentido normalmente se combinan una estrategia
de desarrollo incremental con una de desarrollo en espiral. Una importante característica de un proceso iterativo
es que la especificación del software es desarrollada a lo largo del proceso de
desarrollo de software, es decir, no se establece de forma completa e inmutable
al principio del desarrollo.
Un artefacto es cualquier información usada o
producida por el proceso de desarrollo de software (OMG 2002). Ejemplos de artefactos son: documentos, modelos,
archivos fuente y ejecutables. Un rol es la definición del comportamiento y
responsabilidades de un individuo o conjunto de individuos trabajando juntos
como un equipo, dentro del contexto de la organización de ingeniería de software.
Una actividad es una unidad de trabajo que
puede realizar un determinado rol.Todo lo anterior se define de acuerdo a la
terminología utilizada en RUP (Rational Unfied Process) que es la
versión de la empresa Rational del proceso unificado . No existe un proceso de desarrollo de software
universal que sea adecuado para cualquier proyecto. Debido a esto, un proceso de desarrollo debe ser
entendido como un marco de trabajo configurable, capaz de ser adoptado y escalda
según las características del proyecto
En la actualidad, quizá dos de los exponentes más
representativos de procesos en cuanto a su interés industrial, son RUP y XP (Extreme
Programming) (Beck 2000). Ambos representan una pugna entre lo que se ha
clasificado por algunos autores como procesos peso pesado (heavyweight)
y procesos peso ligero (lightweight) o también llamados metodologías
ágiles.
0 comentarios:
Publicar un comentario