Calidad de Software

Contenido
1. Calidad de Software
1.1 Calidad de software
1.2 Problema de la calidad de software
1.3 Medida de la calidad de software
1.4 Factores, Criterios y Métricas de la Calidad
1.5 Estrategia de la calidad de software
1.6 Arquitectura de Software y calidad

1.1 Calidad de Software

Existe una constante preocupación de los investigadores tecnológicos en
lo referente a la calidad de sus productos. Es necesario que cuenten con
lineamientos y herramientas de apoyo necesarios para disminuir este
problema y así poder liberar sus trabajos sin ninguna preocupación.

¿Por qué es necesaria la calidad?

Porque la competencia es cada mayor, por eso necesario que las
empresas se preocupen por dar un mejor producto, pero la calidad de un
producto no solo se mide al terminarlo. Hoy en día las necesidades de
buscar una solución a problemas complejos en el software ha ocasionado
que las empresas dedicadas al desarrollo o mantenimiento de software
sean rebasadas, es decir que no sean capaces de desarrollar o entregar
un software confiable, a tiempo y apegado al presupuesto acordado con
el cliente y de que el cliente confié que todo lo anterior se cumplirá. Por
esto las organizaciones deben buscar una norma, estándar o modelo que
pueda ayudarlas a ser competitivas o llegar a la calidad. En los modulo
anteriores se dieron un resumen de estos métodos, herramientas y
lineamientos, en este módulo estableceremos los conceptos que son
necesarios para que un proyecto de software se considere “que cumple
con los requerimientos establecidos por el cliente o stakeholder “o sea
de calidad.

1.1.1. Definición de calidad/calidad de software.

En recientes años surgió la moda por la calidad en todas las áreas
productivas de los países, y según Joseph Juran, algunos han buscado
realizar nuevos esquemas de calidad sofisticados después del
surgimiento de estándar ISO9000, en esa loca carrera han surgido
estándares mediocres, puesto que la calidad está en movimiento, y no
debe comenzarse un nuevo estándar de cero. Juran dice que calidad
consiste en esas características del producto que satisfacen con las
necesidades de los clientes, es decir la satisfacción del producto. Calidad
consiste en un producto libre de fallas. Philip Crosby quien desarrollo
conceptos de administración de la calidad y cuyas influencias se
encuentran en el estándar de calidad ISO9000:2000 que difiere del 1994
en el contexto de cada uno de sus 8 principios, define calidad como el
ajuste a los requerimientos y cero defectos.
ISO 9000 define calidad como la totalidad de las características de una
entidad que soportan su disponibilidad para satisfacer las necesidades
que el cliente estableció como requerimientos en un contrato o las
necesidades que la compañía que provee el producto identifica y define.
Esta definición debería ser aplicada a todos los productos ya sean
manufactureros, artesanales, de software etc.

Calidad de software se define por algunos especialistas de ingeniería de

software como:
1. Dar cumplimiento a un número adaptado de parámetros de calidad
definidos por McCall, los cuales son correcto, robusto, extendible,
reusable, compatible, eficiente, portable, integro, verificable, y de fácil
uso (Meyer)

2. Proceso de administración que asegura que el software tiene un

número bajo de defectos que llega a los estándares de calidad
requeridos confiabilidad, portabilidad, mantenibilidad etc. (Somerville)

Para nosotros:
La calidad del software es el conjunto de cualidades que lo caracterizan
y que determinan su utilidad y existencia. La calidad es sinónimo de
eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad,
portabilidad, usabilidad, seguridad e integridad. La calidad del software
es medible y varía de un sistema a otro o de un programa a otro. Un
software elaborado para el control de naves espaciales debe ser
confiable al nivel de "cero fallas"; un software hecho para ejecutarse una
sola vez no requiere el mismo nivel de calidad; mientras que un
producto de software para ser explotado durante un largo período (10
años o más), necesita ser confiable, mantenible y flexible para disminuir
los costos de mantenimiento y perfeccionamiento durante el tiempo de
explotación.
La calidad del software puede medirse después de elaborado el
producto. Pero esto puede resultar muy costoso si se detectan
problemas deriva dos de imperfecciones en el diseño, por lo que es
imprescindible tener en cuenta tanto la obtención de la calidad como su
control durante todas las etapas del ciclo de vida del software.

Calidad de Software
Es la concordancia con los requerimientos funcionales y de rendimiento
explícitamente establecidos, con los estándares de desarrollo
explícitamente documentados y con las características implícitas que se
esperan de todo software desarrollado profesionalmente.

Existen 3 puntos importantes de la definición de calidad de software:

1. los requerimientos del software son los fundamentos desde los que se
mide la calidad
2. los estándares específicos definen un conjunto de criterios de
desarrollo que guían la forma de aplicación de la ingeniería de software
3. existen requerimientos implícitos que no se mencionan
Un producto de alta calidad requiere menos mantenimiento y facilita
tanto el desarrollo como el mantenimiento de la productividad. Con la
medición de la calidad se pueden lograr estos objetivos. En lo que se
refiere al mantenimiento, la medición de la calidad del software ayuda a
identificar problemas de confiabilidad y a mejorar las técnicas para
identificar las necesidades de mantenimiento.

1.2. Problemas de la calidad de software.

Adolfo Guzmán Arenas Centro de Investigación en Computación (CIC), Instituto

Politécnico Nacional (IPN), México dice:
Sorprende cómo, a través de los años, actividades tan básicas a nuestra
profesión como la creación de software de calidad, y la buena calidad en
la enseñanza en computación, se han rodeado o cubierto paulatinamente
de creencias, actitudes, “escuelas de pensamiento”, supersticiones y
fetiches que raramente se ven en un campo científico o técnico, y que
cada vez más personas cuestionan cada vez menos, de manera que se
convierten en “verdades cotidianas” o “estándares a observar y a exigir.”
Tengo la impresión de que soy minoría en esta ola de creyentes y
creencias, y que mis puntos de vista son altamente impopulares. Me
atrevo a expresarlos porque no alcanzo a ver fallas suficientes en mi
razonamiento, y porque quizá halle a otros “creyentes” de las creencias
actuales no tan convencidos de ellas, de modo que, tal vez,
descubramos que al fin “el emperador no llevaba traje, estaba desnudo”.

¿Por qué es tan difícil desarrollar software?

Desarrollar software puede ser un gran desafío intelectual:
Problemas grandes, complejos y muy variados
Formalismos inadecuados
Gran diferencia entre la teoría y la práctica
Imposibilidad de utilizar aproximaciones
No hacer las cosas bien se manifiesta en muchas formas.
Estos problemas, que se listan a continuación, son los más
generalizados en las empresas del sector cuyos procesos no tienen
calidad y no tienen forma de asegurar la calidad del producto software:

Compromisos consistentemente incumplidos, expresados en términos

de entregas tardías, afluencia constante de defectos de última hora —
algo que aquí en Colombia llaman coloquialmente «chicharrones»— y
costos espiralados.
Reducida visión gerencial en el progreso, con la ocurrencia de sorpresas
constantes.
Problemas propios de la calidad, como demasiado «reproceso» o
«retrabajo», que las funciones no operen correctamente y un elevado
número de quejas de los clientes luego de la entrega —lo cual no es
menor si pensamos en el impacto que esto puede tener sobre la imagen
marca de la empresa al estar dejando gran parte de las detecciones de
defectos en manos de los clientes.
Moral pobre, que se percibe en forma de gente frustrada y la sensación
de que nadie está a cargo.
1.3. Medida de calidad de software.
Las medidas constituyen un aspecto fundamental para todos los
ingenieros y, por tanto, los ingenieros del software deben conocer
algunos aspectos de la teoría de medidas aplicadas a la ingeniería del
software. Se han publicado gran cantidad de medidas del software, que
miden distintos aspectos del software, pero no siempre todas ellas
resultan apropiadas. La calidad del software es un tema candente en la
actualidad y es necesario saber definir adecuadamente la calidad de un
sistema informático y cómo evaluar dicha calidad mediante la utilización
correcta de medidas. Por último, los resultados proporcionados por un
modelo que evalúe la calidad del software pueden aprovecharse para
mejorar el proceso software personal o corporativo.

¿COMO OBTENER UN SOFTWARE DE CALIDAD?

La obtención de un software con calidad implica la utilización de
metodologías o procedimientos estándares para el análisis, diseño,
programación y prueba del software que permitan uniformar la filosofía
de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y
facilidad de prueba, a la vez que eleven la productividad, tanto para la
labor de desarrollo como para el control de la calidad del software.
La política establecida debe estar sustentada sobre tres principios
básicos: tecnológico, administrativo y ergonómico.
El principio tecnológico define las técnicas a utilizar en el proceso de
desarrollo del software.
El principio administrativo contempla las funciones de planificación y
control del desarrollo del software, así como la organización del
ambiente o centro de ingeniería de software.
El principio ergonómico define la interfaz entre el usuario y el ambiente
automatizado.
La adopción de una buena política 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 evaluación.

Estandarización y medida del producto

Según Hatton, (1995) el aspecto más importante de la estandarización
del producto software es que prácticamente no hay ningún estándar
válido. Diversos estudios han destacado que el estado del arte en cuanto
a métricas hoy en día no está lo suficientemente avanzado como para
permitir una estandarización, aunque sí que existen algunos estándares
sobre métricas como el ISO 9126 “Software product evaluation. Quality
characteristics and guidelines” (ISO/IEC, 1991) que cubre aspectos
sobre calidad del software y medida o el IEEE 1061 “Standard for a
Software Quality Metrics Methodology” (IEEE, 1998) que presenta una
metodología para obtener las métricas que puedan evaluar la calidad del
producto software realizado.

Estandarización del proceso

Se trata de estandarizar el proceso de desarrollo del producto software.
Hay estándares muy generales que luego se van particularizando en
stándares para un campo de aplicación determinado, un área de
influencia, etc., existen estándares aparte de los usados para el
desarrollo del software como ISO 9001 e ISO 90003, CMM “Capability
Maturity Model for Software”
SPICE 98 “Software Process Improvement and Capability determination”
o ISO/IEC TR 155041998 “Information TechnologySoftware Process
Assessment”, Def 0055 “Requirements for Safety Related Software
inDefense Equipment”
IEEE/EIA 12207 “SoftwareLifecycle Processes” (IEEE/EIA, 1998) ESA
PSS050 es el estándar de la agencia espacial europea para ingeniería del
software

Existen otros para tareas más específicas, como la codificación,

convenciones para poner nombres, gestión de la configuración,
documentación, glosarios de términos, mantenimiento, etc. Un
compendio hasta 1993de todos ellos puede encontrarse en Thayer
(1993).

1.4 Factores, Criterios y Métricas de la Calidad

1Factores de Calidad
Los factores que determinan la calidad se pueden clasificar en 2 grandes
grupos:
1Factores que se pueden medir directamente (Ej. errores / unidad de
tiempo)
2Factores que sólo pueden ser medidos indirectamente (Ej. Facilidad de
mantenimiento)

En ambos casos, se puede obtener una medida. Pero estas medidas

deben ser comparadas con alguna referencia o indicador para poder
llegar a una indicación de la realidad Mc Call clasifica los factores de
calidad en:
1Características Operacionales
2Capacidadde Soportar Cambios
3Adaptabilidad a nuevos entornos

1CaracterísticasOperacionales
Corrección Es el grado en que un programa satisface sus
especificaciones y consigue los objetivos pedidos por el cliente. Este
factor tiene una pregunta asociada: ¿Hace lo que quiero?

Confiabilidad Es el grado en que se puede esperar que un programa

lleve a cabo sus funciones esperadas con la precisión requerida. La
pregunta asociada a este factor sería: ¿Lo hace de forma fiable todo el
tiempo?

Eficiencia La cantidad de recursos de computadoras y de código

requeridos por un programa para llevar a cabo sus funciones. La
pregunta asociada a este factor sería: ¿Se ejecutará en mi hardware lo
mejor que pueda?

2Capacidad de Soportar Cambios

Facilidad de Mantenimiento Es el esfuerzo requerido para localizar y
arreglar un error en un programa. La pregunta asociada a este factor
sería: ¿Puedo corregirlo?
Flexibilidad Es el esfuerzo requerido para modificar un programa
operativo. La pregunta asociada a este factor sería: ¿Puedo cambiarlo?

Facilidad de Prueba Es el esfuerzo requerido para probar un

programa de forma que se asegure que realiza su función requerida. La
pregunta asociada a este factor sería: ¿Puedo probarlo?

3 Adaptabilidad de nuevos entornos

Portabilidad Es el esfuerzo requerido para transferir el programa
desde un hardware y/o un entorno de sistema de software a otro. Este
factor tiene una pregunta asociada: ¿Podré usarlo en otra máquina?
Reusabilidad Es el grado en que un programa (o partes de este) se
pueden reusar en otras aplicaciones. Este factor tiene una pregunta
asociada: ¿Podré reusar alguna parte del software?
Facilidad de Interoperación Es el esfuerzo requerido para acoplar un
sistema a otro. Este factor tiene una pregunta asociada: ¿Podré hacerlo
interactuar con otro sistema?

Métricas
Métricas de Calidad
Es difícil desarrollar medidas directas de los anteriores factores de
calidad. Por eso, se definen un conjunto de métricas para cada uno de
los factores de calidad. Generalmente estas métricas definidas por
MacCall solo pueden ser medidas en forma subjetiva.
Las métricas pueden estar listas de comprobaciones para obtener el
grado de los atributos específicos del software. El esquema de
graduación propuesto por McCall va en una escala de 0 (bajo) a 10
(alto). En este esquema se usan las siguientes métricas:
Facilidad de Auditoría La facilidad con que se puede comprobar la
conformidad con los estándares
Exactitud La precisión de los cálculos y el control
Normalización de las Comunicaciones El grado en que se usan el
ancho de banda, los protocolos y las interfaces estándar
Completitud El grado en que se ha conseguido la total implementación
de las funciones requeridas
Concisión Lo compacto que es el programa en términos de líneas de
código
Consistencia El uso de un diseño uniforme de técnicas de
documentación a los largo del proyecto de desarrollo de software
Estandarización en los datos El uso de estructuras de datos de tipos
estándar a lo largo de todo el programa
Tolerancia de Errores El daño que se produce cuando el programa
encuentra un error
Eficiencia en la Ejecución El rendimiento en tiempo de ejecución de
un programa
Facilidad de expansión El grado en que se puede ampliar el diseño
arquitectónico de datos o procedural
Generalidad La amplitud de aplicación potencial de los componentes del
programa
Independencia del Hardware El grado en que el software es
independiente del hardware en que opera
Instrumentación El grado en que el programa muestra su propio
funcionamiento e identifica errores que aparecen
Modularidad La independencia funcional de los componentes del
programa
Facilidad de Operación La facilidad de operación de un programa
Seguridad La disponibilidad de mecanismos que controlen o protejan
los programas o datos
AutoDocumentación El grado en que el código fuente proporciona
documentación significativa

Las métricas de calidad aportan una indicación de cómo se ajusta el

software a los requisitos implícitos y explícitos del cliente. A veces,
cuando se intentan obtener medidas precisas de la calidad del software
se acaba frustrado por la naturaleza subjetiva de esta actividad. Para
resolver este problema, se buscan medidas cuantitativas de la calidad
del software, para poder llevar a cabo un análisis objetivo. Pero no es
posible medir la calidad del software de forma exacta, ya que cada
medida es parcialmente imperfecta. Las medidas de calidad siempre son
indirectas, ya que no se mide directamente la calidad sino algunas de
sus manifestaciones. El factor que lo complica es la relación precisa
entre la variable que es medida y la calidad del software. En la figura 2,
Möller (Möller& Paulish, 1993) muestra la importancia de las métricas
para conseguir una mejora en la calidad del software.El término
“métrica” se usa frecuentemente para indicar un conjunto de mediciones
tomadas en un proceso particular. En el estándar EEE, (1998) se define
la métrica de calidad del software como:“Una función cuyas entradas
son datos del software y cuya salida es un único valor numérico que
puede ser interpretado como el grado que posee el software de un
atributo dado que afecta a la calidad.”Las métricas de ingeniería del
software se usan para caracterizar:
Productos de ingeniería del software; por ejemplo, diseños, código
fuente, casos de prueba…
Procesos de ingeniería del software; por ejemplo, actividades del
análisis, diseño, codificación…
Tareas realizadas por personas; por ejemplo, la eficiencia de una
persona que realiza las pruebas, o la productividad de un diseñador
individual. Si se usan de manera adecuada, las métricas de ingeniería
del software deben permitir:
• Definir cuantitativamente el grado de éxito y/o fracaso para un
producto, un proceso o las tareas realizadas por una persona.
• Identificar y cuantificar las mejoras, su ausencia o la degradación del
producto, del proceso o de las tareas realizadas por las personas.
• Hacer entendibles y útiles las decisiones técnicas y las de gestión.
• Identificar tendencias.
• Realizar estimaciones cuantificables y con sentido.
Los trabajos preliminares de la aplicación de métodos cuantitativos al
desarrollo del software se establecieron en 1970 (Möller & Paulish,
1993). Existían cuatro tendencias tecnológicas principales que fueron las
que evolucionaron en las métricas de hoy en día:

1. Medidas de la complejidad del código. A mediados de los 70

existía una significativa actividad investigadora para desarrollar medidas
de la complejidad del código. Estas métricas serán fáciles de calcular a
partir del código del producto. Algunos ejemplos de ellas son la medida
de complejidad ciclomática de McCabe y la ciencia del software de
Halstead.
2. Estimación de los costes del proyecto software.
Estas técnicas fueron desarrolladas a mediados de los 70 para estimar el
esfuerzo y la planificación necesarios para desarrollar un producto
software, basado en la estimación del número de líneas de código
necesarias para implementarlo u otros factores.Algunos ejemplos de
estas técnicas incluyen el modelo SLIM de Larry Putnam y el modelo
COCOMO de Barry Boehm.
3. Garantía de calidad del software. Las técnicas relacionadas con la
garantía del software mejoraron significativamente a finales de los 70 y
principios de los 80. Especialmente interesante para los métodos
cuantitativos fue la acumulación de datos de fallos durante las distintas
fases del ciclo de vida del software.
4. Proceso de desarrollo software. A medida que los proyectos de
software se fueron haciendo más grandes y más complejos, se fue
viendo la necesidad de controlar el proceso de desarrollo. Este proceso
incluía la definición del ciclo de vida de desarrollo en varias fases
secuenciales y ponía más énfasis en la gestión del proyecto software con
mejores controles de los recursos.
En la actualidad existen multitud de métricas. Cada organización deberá
decidir cuáles son sus metas y, en virtud de ellas, decidir qué métricas
emplear. En la tabla 3, presentada en Horch (1996), se enumeran
algunas de las métricas más conocidas relacionadas con unas metas
determinadas. Las siglas SQS de la tabla significan“Software Quality
System”, sistema de calidad del software. Las siglas STR2 quieren decir
“Software Trouble Report”, informe de los problemas software. En este
libro, se utilizan las métricas como una relación entre dos medidas.
TABLA 3. METAS Y MÉTRICAS
Metas del SQS Métricas aplicables
Mejora de la gestión de defectos
Cambios del costo de calidad / Planificación de la implantación del SQS
Coste del software rechazado / Coste total del proyecto
Coste de la corrección de defectos / Coste de la detección de defectos
Densidad de defectos / Fase del ciclo de vida
Defectos encontrados en las revisiones / Defectos encontrados en las
pruebas
Defectos detectados por el usuario / Defectos detectados por el
desarrollador
STR’s cerrados / Total de STR’s abiertos
STR’s que quedan abiertos / STR’s cerrados
STR’s abiertos y cerrados / Periodo de tiempo
Tiempo medio entre fallos
Fiabilidad del producto software
Llamadas a la ayuda / Producto software
Requisitos cambiados / Requisitos totales
Mejora de los requisitos
Requisitos implementados / Requisitos totales
Errores de los requisitos / Errores totales
Mejora en la detección de defectos
Pruebas realizadas con éxito / Total de pruebas planificadas
Defectos encontrados en las revisiones / Defectos encontrados en las
pruebas
Densidad de defectos / Producto software
Defectos detectados por el usuario / Defectos detectados por el
desarrollador
Mejora de la productividad del desarrollador
Miles de líneas de código o puntos función / Mes de una persona
Planificación o presupuesto real / Estimación
Desembolso del presupuesto / Estado de la planificación
Tiempo medio para reparar un defecto
Defectos incorrectamente corregidos / Defectos totales
Defectos del producto software / Complejidad del producto software
Mejora de las técnicas de estimación
Planificación o presupuesto real / Estimación
Tiempo medio para reparar un defecto
Desembolso del presupuesto / Estado de la planificación
Incremento del procesamiento del centro de datos
Correcciones realizadas de manera errónea / Correcciones totales
Tiempo medio para reparar un defecto
Defectos detectados por el usuario / Defectos detectados por el
desarrollador
La relación entre los factores de calidad del software y las métricas se
muestran en la siguiente tabla:
com

1.5 Estrategia de la calidad de software

La estrategia de Calidad es la construcción de un camino sobre un
entorno estratégico dinámico y que tenga como estrella guía «la
misión», como actores permanentes a las personas y como conductor al
líder, racional y apasionado, seductor y dogmático, soñador y
pragmático, es decir al hombre, esencia misma de la contradicción y
paradoja y hacedor irrenunciable de los caminos cualitativos de la
historia y que adquiere mayor relevancia en esta época signada por la
tecnología y las comunicaciones, la globalización y la revolución de los
modos culturales. Porque en este nuevo orden de la economía, donde los
productos primarios se han desconectado del empleo, los capitales
adquieren relevancias fantasiosas, las oficinas se convierten en fábricas
de ideas (y hasta adquieren arquitectura de «producción»). Es innegable
la participación vital que tiene, porque sólo él será capaz de atender la
problemática y crecer con ella.
¿Por qué planificar?
¿Por qué preocuparse en mejorar de forma continua?
¿A que apunta la estrategia?
Todas preguntas importantes de responder, y a las cuales muchos
directivos, profesionales y empresarios no le dan la debida importancia o
la suficiente atención.
Responder a éstas y otras cuestiones es lo que marca la diferencia entre
empresas que sólo subsisten, con directivos que tratan de poner parches
a los desequilibrios financieros, tratando de apaciguar las arremetidas de
consumidores y clientes descontentos, luchando contra costos cada día
más altos y niveles de productividad en claro declive. Empresas estas
que ven la luz cuando la situación global es óptima, pero que nunca
aprovechan en su plenitud estas situaciones, y que cuando el mercado
se deprime entran en un fuerte cono de sombra e incertidumbre. Y por
otro lado tenemos a aquellas empresas y organizaciones que con
objetivos claramente definidos, y un perfecto enfoque en las actividades
a realizar, planifican proactivamente, no sólo anticipándose al futuro sino
creándolo. Empresas para las cuales los recursos tienen un valor y saben
en consecuencia administrarlo. Entre esos recursos fundamentales se
encuentra el tiempo. Elemento crucial que una vez consumido ya no se
puede recuperar. Así tenemos a las empresas que malgastan el tiempo
de sus clientes, empleados y el de su propio futuro como entidad, de
aquellas que lo saben valorar no desperdiciando tan importante recurso.
No menor importancia tiene como recurso el capital humano que cada
empresa posee y que muy pocas saben en realidad valorar. Se
despilfarran sistemáticamente recursos humanos, cuando no se hace
lugar a su participación activa, cuando sus experiencias, habilidades,
capacidades y conocimientos no son tenidos en cuenta, o son lisa y
llanamente subestimados por los directivos.
En vistas al mediano y largo plazo sólo podrán sobrevivir aquellas
empresas que menos recursos desperdicien. Para ello es fundamental
lograr un óptimo nivel de planificación, y tener la disciplina de mejorar
día a día. Cada día se agregan nuevos competidores a escala global.
Piense en cualquier actividad y verá nuevas empresas y nuevos países
ingresar con más fuerza y profundidad en los mercados mundiales.

Acaso alguien pensaba hace unas décadas atrás en que Malasia sería
hoy el principal productor mundial de chips de informática, o que Corea
del Sur entraría en los mercados occidentales en materia automotriz.
Pues bien estos son sólo unos pocos ejemplos de los cambios que están
teniendo lugar. Los países y las empresas carentes de estrategias están
destinadas a ver cada día más lejos un nivel óptimo de crecimiento y
desarrollo. No es lo mismo ser propietario o empleado de una empresa
en la cual no se sabe qué día se abonarán los sueldos, ni si se podrán
cubrir las deudas bancarias, o en la que los obreros no saben si
continuarán empleados en los próximos meses, que aquellos que
formando parte de empresas de primera línea planifican como ingresar
en nuevos mercados, analizan su participación, diseñan nuevos
productos y servicios, sus marcas son sinónimo de calidad y excelencia a
nivel mundial, o como mínimo regional o nacional.
No es lo mismo ser parte de empresas que con el paso de los años no
registran cambio alguno, y si lo han registrado es de manera negativa,
que estar involucrados en organizaciones que mejoran día tras día,
brindando mejores productos y servicios a los consumidores, y haciendo
participes a sus propietarios, directivos y empleados de niveles de vida
más ricos no sólo en materia económica, sino además en crecimiento y
desarrollo personal. Tampoco es lo mismo para un cliente probar suerte
con los productos y servicios que una organización le brinda, que
adquirir bienes y servicios de empresas confiables, que otorgan alto
valor a los niveles de satisfacción, ofreciendo cada día una más variada
gama de productos y servicios.
Nada de ello es producto de la casualidad. Las cosas ocurren porque se
planifica y realizan acciones concretas para su obtención, o sea hay una
causalidad. Es muy fácil hablar de planificación, organización, dirección y
control. Pero otra muy distinta es llevarlo a la práctica y mejorarlos de
manera continua.
Es la hora en que los clientes se preguntan qué empresa vale la pena
realmente contratar para sus servicios, es también el momento en que
los trabajadores se preguntan si vale la pena dejar parte de sus vidas y
proyectos personales en empresas que no le permiten ningún
crecimiento personal ni económico. Es el momento en que los
consumidores piensan si deben seguir adquiriendo productos de escaso
valor, mala calidad, precio elevado y un servicio al cliente atroz.
Es el momento en el cual los líderes deberán hacerse cargo de sus
responsabilidades implantando una estrategia que permita dar vida a la
excelencia. La excelencia sólo se obtiene con la ética del trabajo, la
disciplina de la mejora continua y un cambio de paradigmas que permita
hacer de la empresa y el trabajo una base para la creatividad y
expansión humana, y no meramente una máquina de triturar recursos y
proyectos

Las Estrategias deben de contener estos tres factores:

Conformar Equipo Humano, selección y formación de un equipo
humano experto en cada actividad del desarrollo de software.
Definición y consolidación del proceso y la metodología de desarrollo de
software adaptada a la cultura y a las necesidades de la Empresa.
Seleccionar e implementar las mejores Herramienta de desarrollo de
software
Implementar la cultura de la mejora continua y el aseguramiento de la
calidad

¿COMO CONTROLAR LA CALIDAD DEL SOFTWARE?

Para controlar la calidad del software es necesario, ante todo, definir los
parámetros, indicadores o criterios de medición, ya que, como bien
plantea Tom De Marco, "usted no puede controlar lo que no se puede
medir".
Las cualidades para medir la calidad del software son definidas por
innumerables autores, los cuales las denominan y agrupan de formas
diferentes. Por ejemplo, John Wiley define métricas de calidad y
criterios, donde cada métrica se obtiene a partir de combinaciones de los
diferentes criterios. La Metodología para la evaluación de la calidad de
los medios de programas de la CIC, de Rusia, define indicadores de
calidad estructurados en cuatro niveles jerárquicos: factor, criterio,
métrica, elemento de evaluación, donde cada nivel inferior contiene los
indicadores que conforman el nivel precedente. Otros autores identifican
la calidad con el nivel de complejidad del software y definen dos
categorías de métricas: de complejidad de programa o código, y de
complejidad de sistema o estructura. Todos los autores coinciden en que
el software posee determinados índices medibles que son las bases para
la calidad, el control y el perfeccionamiento de la productividad. Una vez
seleccionados los índices de calidad, se debe establecer el proceso de
control, que requiere los siguientes pasos:

Definir el software que va a ser controlado: clasificación por tipo, esfera

de aplicación, complejidad, etc., de acuerdo con los estándares
establecidos para el desarrollo del software.
Seleccionar una medida que pueda ser aplicada al objeto de control.
Para cada clase de software es necesario definir los indicadores y sus
magnitudes.
Crear o determinar los métodos de valoración de los indicadores:
métodos manuales como cuestionarios o encuestas estándares para la
medición de criterios periciales y herramientas automatizadas para
medir los criterios de cálculo.
Definir las regulaciones organizativas para realizar el control: quiénes
participan en el control de la calidad, cuándo se realiza, qué documentos
deben ser revisados y elaborados, etc.

1.6 Arquitectura de Software y calidad.

Arquitectura software
En los inicios de la informática, la programación se consideraba un arte,
debido a la dificultad que entrañaba para la mayoría de los mortales,
pero con el tiempo se han ido desarrollando metodologías para conseguir
nuestros propósitos. Y a todas estas técnicas se les ha dado en llamar

Arquitectura Software.
Una Arquitectura Software, también denominada Arquitectura lógica,
consiste en un conjunto de patrones y abstracciones coherentes que
proporcionan el marco de referencia necesario para guiar la construcción
del software para un sistema de información.
La arquitectura software establece los fundamentos para que analistas,
diseñadores, programadores, etc. trabajen en una línea común que
permita alcanzar los objetivos y necesidades del sistema de información.
Una arquitectura software se selecciona y diseña con base en unos
objetivos y restricciones. Los objetivos son aquellos prefijados para el
sistema de información, pero no solamente los de tipo funcional,
también otros objetivos como la mantenibilidad, auditabilidad,
flexibilidad e interacción con otros sistemas de información. Las
restricciones son aquellas limitaciones derivadas de las tecnologías
disponibles para implementar sistemas de información. Unas
arquitecturas son más recomendables de implementar con ciertas
tecnologías mientras que otras tecnologías no son aptas para
determinadas arquitecturas. Por ejemplo, no es viable emplear una
arquitectura software de tres capas para implementar sistemas en
tiempo real.
La arquitectura software define, de manera abstracta, los componentes
que llevan a cabo alguna tarea de computación, sus interfaces y la
comunicación ente ellos. Toda arquitectura software debe ser
implementable en una arquitectura física, que consiste simplemente en
determinar qué computadora tendrá asignada cada tarea de
computación.
La arquitectura de software, tiene que ver con el diseño y la
implementación de estructuras de software de alto nivel. Es el resultado
de ensamblar un cierto número de elementos arquitectónicos de forma
adecuada para satisfacer la mayor funcionalidad y requerimientos de
desempeño de un sistema, así como requerimientos no funcionales,
como la confiabilidad, escalabilidad, portabilidad, y disponibilidad

La AS ha agregado al área del desarrollo de software desde hace

varios años el concepto de calidad, puesto que se han generado
patrones de diseño, estándares de diseño, métodos de diseño,
estudios de costos del diseño, métodos de evaluación del diseño,
servicios, plantillas y herramientas arquitectónicas.
A continuación un panorama de cómo la AS evoluciono en los últimos
años. La década de 1990, creemos, será la década de la arquitectura de
software. Usamos el término “arquitectura” en contraste con “diseño”,
para evocar nociones de codificación, de abstracción, de estándares, de
entrenamiento formal (de los arquitectos de software) y de estilo. ? Es
tiempo, de reexaminar el papel de la arquitectura de software en el
contexto más amplio del proceso de software y de su administración, así
como señalar las nuevas técnicas que han sido adoptadas.
En el siglo XXI, la AS aparece dominada por estrategias orientadas a
líneas de productos y por establecer modalidades de análisis, diseño,
verificación, refinamiento, recuperación, diseño basado en escenarios,
estudios de casos y hasta justificación económica, redefiniendo todas las
metodologías ligadas al ciclo de vida en términos arquitectónicos. Todo
lo que se ha hecho en ingeniería debe formularse de nuevo, integrando
la AS en el conjunto. La producción de estas nuevas metodologías ha
sido masiva, y una vez más tiene como epicentro el trabajo del Software
Engineering Institute en Carnegie Mellon. La aparición de las
metodologías basadas en arquitectura, junto con la popularización de los
métodos ágiles en general y Extreme Programming en particular, han
causado un reordenamiento del campo de los métodos, hasta entonces
dominados por las estrategias de diseño “de peso pesado”. Después de
la AS y de las tácticas radicales, las metodologías nunca volverán a ser
las mismas.