Unidad I

1 Conceptos básicos de calidad.

1.1 Definición de calidad.

1.2 Definición de calidad de software.

1.3 Quién define la calidad.

1.4 Importancia de la calidad.

1.5 La calidad y el mundo globalizado.

1.6 Calidad de vida.

1.7 Calidad total.

2 Aseguramiento de la calidad del software ( SQA ).

2.1 Relación de la Ingeniería del software con SQA.

2.2 Definición y propósito del SQA.

2.3 Problemas que resuelve la SQA.

2.4 Calidad del software en el ciclo de vida del mismo.

2.5 Roles y responsabilidades de los equipos de desarrollo.

2.6 Habilidades y capacidades del personal del SQA.

2.7 Actividades del SQA.

2.8 Métodos y herramientas.

3 Estándares de calidad aplicados al software.

3.1 ISO

3.2 SPICE

3.3 CMM

3.3.1 Definición del modelo.

3.3.2 Nivel inicial.

3.3.3 Nivel repetido.

3.3.4 Nivel definido.

3.3.5 Nivel administrado.

3.3.6 Nivel optimizado.

4 Calidad enfocada al desarrollo de software.

4.1 Qué es la calidad del software.

4.2 Cómo obtener calidad de software (métodos, metodologías, estándares).

4.3 Cómo controlar la calidad del software.

4.4 Costo de la calidad del software.

4.5 Nomenclatura y certificación ISO

9001:2000.

4.6 La norma ISO/IEC 9126.

4.7 Análisis de factores que determinan la calidad del software.

4.8 Análisis del proceso del ciclo de vida del software.

4.9 Funciones de evaluación del software.

1.1. Definición de calidad

En el diccionario Webster, la calidad se define como "las características esenciales de algo, un carácter inherente o distinguir, el grado, o grado de excelencia”.

Otra definición de la calidad, es el cliente. Con esta definición, el cliente define la calidad en cuanto a si el producto o servicio cubre las necesidades del cliente.

CALIDAD, en algunos aspectos, es una característica difícil de alcanzar, no porque es difícil de lograr (una vez que decidimos lo que es), sino porque es difícil de describir.

Los atributos de calidad se describen en los requisitos de las especificaciones del cliente.

Por ejemplo, incluyen:

la facilidad de uso, la relativa facilidad con la que un usuario se comunica con la aplicación; la portabilidad, la capacidad de Reutilización, la capacidad de transferencia de componentes de software construidas en

un software sistema a otro.

Concepto de la calidad

•No es absoluta

•Está sujeta a restricciones

•Trata de compromisos aceptables

•Es multidimensional

•Los criterios de calidad no son

•independientes

1.2 Definición de Calidad de Sw

•Calidad del software: es el desarrollo de software basado en estándares con la funcionalidad y rendimiento total que satisfacen los requerimientos del cliente.

•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.

De acuerdo a la definición del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE, Std. 610-1990):

“La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario”.

Factores que determinan la calidad del software

•Se pueden clasificar en dos grandes grupos (Pressman):

–Factores que pueden ser medidos directamente

–Factores que solo pueden ser medidos indirectamente

•Se centran en tres aspectos importantes de un producto software (McCall):

–Características operativas

–Capacidad de soportar los cambios

–Adaptabilidad a nuevos entornos

•Características operativas

–Corrección. ¿Hace lo que quiero?

–Fiabilidad. ¿Lo hace de forma fiable todo el tiempo?

–Eficiencia. ¿Se ejecutará en mi hardware lo mejor que pueda?

–Seguridad (Integridad). ¿Es seguro?

–Facilidad de uso. ¿Está diseñado para ser usado?

•Capacidad de soportar los cambios

–Facilidad de mantenimiento. ¿Puedo corregirlo?

–Flexibilidad. ¿Puedo cambiarlo?

–Facilidad de prueba. ¿Puedo probarlo?

•Adaptabilidad a nuevos entornos

–Portabilidad. ¿Podré usarlo en otra máquina?

–Reusabilidad. ¿Podré reutilizar alguna parte del software?

–Interoperabilidad. ¿Podré hacerlo interactuar con otro sistema?

Situación actual

•La industria del software no ha acabado de salir de la fase artesanal

•Padecemos de “prisa patológica”, que es consecuencia directa de:

–Desorganización

–Falta de planificación

•Alta dependencia de los “héroes”

•Dedicamos nuestros esfuerzos de hoy a arreglar lo que se hizo mal ayer.

•El producto (software) es algo intangible y no limitado por las leyes físicas.

•La disciplina, ingeniería del software, es relativamente reciente y muchos de sus conceptos importantes están aún inmaduros

•Carencia de un corpus de conocimiento aceptado mayoritariamente que sirva como fundamentos

•Escasa presión del mercado

En una organización inmadura:

•Procesos software normalmente improvisados

•Si se han especificado, no se siguen rigurosamente

•Organización reactiva (resolver crisis inmediatas)

•Planes y presupuestos excedidos sistemáticamente, al no estar basados en estimaciones realistas

En una organización inmadura (cont.):

•Si hay plazos rígidos, se sacrifican funcionalidad y calidad del producto para satisfacer el plan

•No existen bases objetivas para juzgar la calidad del producto

•Cuando los proyectos está fuera de plan, las revisiones o pruebas se recortan o eliminan

•El 90% de los proyectos no alcanzan los objetivos

•El 40% fracasan por completo

•El 29% no se entregan nunca

•Gastos de adaptación tecnológica al año 2000

1.3 quien define la calidad

El cliente

Debe entenderse que el cliente/usuario es quien define la calidad; debiendo la empresa complacer a los clientes, y no contentarse sólo con librarlos de sus problemas inmediatos, sino ir más allá para entender a fondo sus necesidades presentes y futuras, a fin de sorprenderlos con productos y servicios que ni siquiera imaginaban.

Este conocimiento ya no debe ser sólo del dominio exclusivo de grupos especiales de una organización; sino que debe ser compartido y desarrollado por todos los empleados.

Una empresa que define la calidad sin tomar en cuenta a los consumidores corre con el riesgo de producir bienes y servicios con escasa o nula demanda, ya sea porque los clientes tienen otras expectativas y necesidades, o bien porque los competidores están generando bienes con un mayor valor agregado.

Por tales motivos es esencial para las empresas practicar tanto la investigación de mercado, como la inteligencia competitiva y el benchmarking.

Conocidos los deseos y necesidades de los consumidores, estos deben ser traducidas en términos cuantitativos y tangibles.

Este proceso de traducción no es sencillo y requiere de la integración de conocimientos de mercadotecnia con ingeniería y administración, para que las necesidades del consumidor y las expectativas que desarrolló durante el proceso de selección del producto, puedan ser satisfechas completamente.

Entre la técnica más importante para tales fines tenemos el Despliegue de la Función de Calidad (QFD), el cual sirve para realizar todo este proceso de traducción, ayudando a que la voz del cliente se despliegue a través de toda la organización.

(QFD traduce lo que el cliente quiere en lo que la organización produce)

La función de despliegue de la calidad tiene como objetivo asegurar que se cumplan las expectativas del cliente desde el diseño del producto, durante su proceso de manufactura, y hasta que es utilizado por el consumidor.

1.4 importancia de la calidad

La calidad le permite a la empresa:

•Aumentar su productividad

•Tener competitividad

•Mantenerse en el mercado

•Mejorar su rentabilidad

•Obtener reconocimiento

¿Por qué la calidad es importante para la empresa?

•La respuesta es calificada por Deming como la reacción en cadena. Se grafica de la siguiente manera:

Mejorar la calidad

Disminuir los costos

Mejorar la productividad

Conquistar el mercado con mejor calidad y precio bajo

Permanecer en el mercado

Generar más empleos

¿Por qué disminuyen los costos?

•Porque hay menos desperdicios, menor reproceso, menos errores, menos retrasos, se aprovecha mejor el tiempo de máquinas, sólo se emplean los insumos necesarios.

¿Por qué mejora la productividad?

Porque las horas hombre y las horas máquina no se malgastan, se aprovechan mejor. Los recursos renovables no se deterioran.

¿Por qué se conquista el mercado?

Porque se planifica y se produce en relación con las preferencias y requerimientos del cliente, y se mejora continuamente en ese sentido.

¿Por qué se permanece en el negocio?

Porque el cliente satisfecho volverá a comprar y recomendará hacer los mismo a otros clientes.

¿Por qué se genera más empleos?

Porque el mercado ha sido conquistado y está en aumento. El operario está orgulloso de su trabajo y la empresa crece.

1.5 La calidad y el mundo globalizado

Hoy en día las compañías de todo el mundo industrializado reconocen que la calidad del producto se traduce en ahorro de costos y en una mejora general.

La industria de desarrollo de software no es la excepción, por lo que en los últimos años se han realizado intensos trabajos para aplicar los conceptos de calidad en el ámbito del software.

Hablar de calidad del software implica la necesidad de contar con parámetros que permitan establecer los niveles mínimos que un producto de este tipo debe alcanzar para que se considere de calidad.

El problema es que la mayoría de las características que definen al software no se pueden cuantificar fácilmente; generalmente, se establecen de forma cualitativa, lo que dificulta su medición, ya que se requiere establecer métricas que permitan evaluar cuantitativamente cada característica dependiendo del tipo de software que se pretende calificar.

En este sentido se han realizado muchos trabajos que establecen propuestas para el establecimiento de los factores cualitativos que afectan la calidad del software.

Entre los principales están los factores de calidad de McCall y aquellos propuestos por Hewlett-Packard (FURPS: Funcionality, Usability, Reliability; Performance, Supportability) .

Además se han hecho varios intentos por estandarizar los mecanismos de evaluación de calidad del software. Entre los principales están:

• la familia de normas ISO 9000 (en especial la ISO 9001 y la ISO 9003–2),

•el modelo de niveles madurez CMM (Capability Maturity Model),

•el estándar para el aseguramiento de planes de calidad del IEEE 730:1984,

•el plan general de garantía de calidad del Consejo Superior de Informática

1.6 Calidad de vida

Es una hecho que el ser humano es un ser social. En sus dimensiones, física, mental, espiritual, económica y emocional está presente este aspecto.

La mayoría de las personas entiende la dimensión social de manera fragmentaria, es decir, desde el punto de vista de otros; "Mi imagen ante los demás, determina mi imagen ante mi mismo" cuando la realidad es al revés.

Inconscientemente, todos hacemos una diferencia entre lo que somos realmente a nivel individual y nuestro comportamiento a nivel profesional. Por eso vemos a diario:

•médicos (promotores de la salud) enfermos,

•abogados (luchadores por la justicia) deshonestos, etc, como dice el dicho "nadie es profeta en su tierra".

Casi nadie se excluye de este fenómeno, es raro aquel que mantiene una congruencia entre lo que es como individuo y su comportamiento hacia el público.

En la mayoría de los casos, todavía separa su desarrollo individual del profesional y constantemente los contrapone.

Esto se observa mucho actualmente en la cultura empresarial. Dos tercios del tiempo total de un día, la pasamos trabajando.

Sin embargo, en ese tiempo, alguno de nosotros tratamos de aparecer:

"lo menos humanos posible" ¿Por qué? "Está mal visto mostrar las emociones" "Aquí lo que importa es cuánto dinero se le produce a la empresa al mes, no las personas"

Pareciera que el concepto de "humanidad" y "productividad" estuvieran divorciados, por aquello de "Es de humanos cometer errores"

El resultado es el mismo; dosis industriales de estrés y temor, desconfianza de unos hacia otros, y al final la calidad del trabajo es del 50% de su potencial, porque al fin y al cabo, para no cometer errores, cada quien hace solamente el mínimo para conservar su trabajo.

Hasta ahora, con los cambios económicos, políticos y sociales, el mundo empieza a tomar en cuenta que la calidad la hacen los seres humanos y no las máquinas.

Se ha estado gestando una transición de conciencia en lo anterior, debido al surgimiento de las nuevas teorías de calidad total.

En países con una cultura avanzada como Japón son conscientes de la importancia de crear las condiciones para lograr aumentos de calidad, productividad y mejoras impresionantes en el ambiente laboral. Se dieron cuenta de que aunque implementaran procesos de cambio como el rediseño, calidad total, reingeniería, etc., no obtenían los resultados esperaban.

Había que "re humanizar" a las corporaciones.

Atender y entenderse como personas; El resultado fue sorprendente.

• Lograron una mejoría notable en el ambiente laboral,

• se propició un clima de mayor comunicación y mejor interacción...

•Empezaron a surgir equipos de trabajo unidos hacia las metas, pues al darle importancia a las personas, las diferencias y barreras interpersonales se desvanecen dando paso al compromiso de trabajo basado en la confianza mutua entre los empleados, así como en la confianza personal que cada uno experimenta como resultado del proceso vivencial intenso llevado a cabo.

•Mayor y mejor trabajo en equipo, resultando en un ambiente de trabajo más positivo, cálido y orientado a la cooperación.

•Independencia, seguridad y autoconfianza de la gente para llevar a cabo sus responsabilidades y a concretar el desempeño de sus funciones.

•Una implementación más rápida y efectiva de los cambios.

•Gente más creativa y mayor contribución de ideas, gente con sensibilidad personal para redescubrir todos sus potenciales internos.

1.7 calidad total

El concepto de la calidad total es una alusión a la mejora continua, con el objetivo de lograr la calidad óptima en la totalidad de las áreas. Es un concepto que explica cómo ofrecer el mayor grado de satisfacción a un cliente por medio de un bien o servicio.

Para lograr la calidad total se debe mejorar continuamente en la totalidad del bien o servicio, consiguiendo con ello un bien o servicio de calidad total, medido por la satisfacción total del cliente.

Siempre se está en constante perfeccionamiento manteniendo el objetivo de calidad total, la cual es alcanzable en la medida en que la necesidad de los clientes se satisface.

Una mayor satisfacción del cliente crea una mayor percepción de la calidad en el bien o servicio. En el momento que se satisface la necesidad de un cliente de forma total, se estará dando un producto de calidad total, entendiendo esto como el momento en que se satisface una necesidad anteriormente dada.

•Ishikawa, un autor reconocido de la gestión de la calidad, proporcionó la siguiente definición respecto a la Calidad Total: "Filosofía, cultura, estrategia o estilo de gerencia de una empresa según la cual todas las personas en la misma, estudian, practican, participan y fomentan la mejora continua de la calidad"

•Como ejemplo, podemos referirnos a la necesidad que surge de comunicarnos usando el sentido del oído de manera específica, en el momento en que se instala una línea telefónica fija que permite satisfacer esa necesidad en específico, se está dando un servicio de calidad total.

•Después surgirá la exigencia del cliente de que esa línea telefónica sea móvil, y será en el momento en que se adquiera un teléfono celular cuando se esté satisfaciendo totalmente esa necesidad de movilidad.

•A lo que mercadotecnia se refiere, la calidad está directamente relacionada con la satisfacción del cliente, así es que se dice que a mayor satisfacción del cliente, el producto o servicio prestado adquiere mayor grado de calidad.

UNIDAD 2 Aseguramiento de la calidad del software ( SQA ).

2.1 Relación de la ingeniería del software con SQA

La mayor parte de nuevas empresas de software necesitan desarrollar sus productos y lanzarlos al Mercado rápidamente. Muchas de las veces, la presión de las metas lleva a muchos desarrolladores a tener dentro del código o dentro de la funcionalidad de sus aplicaciones deficiencias tanto por errores funcionales, de especificaciones, de rendimiento, etc. y para cubrir estas deficiencias, tradicionalmente las empresas se han visto en la necesidad de contratar dentro de sus propias empresas equipos de personas para que detecten estos errores, los documenten y los envíen a los desarrolladores para resolverlos. Esta formación de equipos complementarios para pruebas, normalmente lleva a las empresas a adquirir equipamiento, y encontrar personal con las competencias necesarias para estas tareas.

El Aseguramiento de la Calidad del Software es uno de los elementos de la ingeniería del software. Tiene como principal objetivo el “dar confianza” al usuario de un software que satisface los requisitos del “cliente” acordados con el Equipo de IOUÇP Desarrollo y que esta libre de defectos.

El aseguramiento de la calidad del software es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto (software) satisfará los requisitos dados de calidad.

El Aseguramiento de Calidad del Software se diseña para cada aplicación antes de comenzar a desarrollarla y no después.

Algunos prefieren decir garantía de calidad en vez de aseguramiento. o Garantía, puede confundir con garantía de productos. o Aseguramiento pretende dar confianza en que el producto tiene calidad.

El aseguramiento de calidad del software está presente en:

Métodos y herramientas de análisis, diseño, programación y prueba. Inspecciones técnicas formales en todos los pasos del proceso de

desarrollo del software. Estrategias de prueba multiescala. Control de la documentación del software y de los cambios realizados. Procedimientos para ajustarse a los estándares (y dejar claro cuando se

está fuera de ellos) o Mecanismos de medida (métricas) Registro de auditorias y realización de informes.

Actividades para el aseguramiento de calidad del software o Métricas de software para el control del proyecto o Verificación y validación del software a lo largo del ciclo de vida Incluye las pruebas y los procesos de revisión e inspección. o La gestión de la configuración del software.

EN QUE CONSISTE: El desarrollo o mantenimiento de software, es un proceso que por su naturaleza “abstracta” y carente de visibilidad física, se puede volver complejo. El Aseguramiento de la Calidad del Software se realiza mediante diferentes actividades a lo largo del ciclo del desarrollo o mantenimiento. Se intercalan actividades y tareas específicas a lo largo del desarrollo o mantenimiento de una aplicación, con la intención de reducir errores. PROPOSITO: Este libro tiene por objetivo definir y organizar las responsabilidades al interior de la estructura organizacional de la gerencia SQA. Estas responsabilidades son necesarias para el correcto funcionamiento de la gerencia de manera de que los integrantes de la gerencia puedan ejecutar los procesos definidos en el documento de procesos de la gerencia SQA. Se debe tener en cuenta de que el objetivo final es producir los documentos SQAP/XX para lograr el asegurar la calidad del software, de acuerdo a la adherencia de los estándares de la fábrica. ALCANCE: Este documento pretende ser una guía para las relaciones jerárquicas que existen al interior de la gerencia SQA y no es modelo de proceso. Esta guía pretende que los integrantes de la gerencia conozcan el alcance de sus responsabilidades en los procesos de la gerencia.

2.2 Definición y propósito del SQA

Aunque el aseguramiento de calidad se llega a considerar importante en el desarrollo de software, se trata con posterga miento y/o con insuficiencia de prioridad y recursos. De tal forma que los proyectos de software terminan fuera de calendario, con aplicaciones no completamente satisfactorias o en un fracaso rotundo. El aseguramiento de calidad (SQA – Software Quality Assurance* ) tiene en sí costos, riesgos y complicaciones. Un programa de aseguramiento de calidad muy complejo o demandante, puede al igual que un proyecto de software, fallar; por lo que se sugiere comenzar con un plan más sencillo que pueda operar y poco a poco ir evolucionando. Uno de los primeros pasos es comprender el concepto de calidad en el software y su administración, la cual contempla el poder establecer metas, actividades y productos entregables, así como, el proceso requerido para lograrlos y una estrategia de desarrollo. Muchas entidades de desarrollo desean producir software de alta calidad, pero ¿qué es la calidad del software?

En términos generales podemos definir la calidad del software como “un atributo de los sistemas de software que tienen concordancia con los requisitos definidos explícita e implícitamente”. Entre los principales objetivos del SQA son la confiabilidad, el desempeño, la funcionalidad y el rehúso. Y entre los principales elementos para la aplicación de pruebas están la experiencia, guías y estándares, métricas, revisiones, pruebas y el rehúso.

Las actividades del aseguramiento de la calidad del software contemplan aquellas tareas del proceso de desarrollo de software que buscan asegurar el diseño, desarrollo y distribución de una aplicación exitosa u otra forma de tecnología de software. Ocurre durante todo el proceso de desarrollo, y cada persona involucrada en este proceso tiene un impacto en la calidad de la aplicación resultante, es importante concentrarse que el aseguramiento de la calidad no es una actividad separada que puede obtenerse fuera de la organización.

2.3 Problemas que resuelve la SQA

El SQA, como actividad de protección en el proceso de desarrollo, comprende procedimientos para la aplicación efectiva de métodos y herramientas, revisiones técnicas formales, técnicas y estrategias de prueba, dispositivos paka-yoke, procedimientos de control de cambios, procedimientos de aseguramiento de ajuste a los estándares y mecanismos de medida e información.

Los principales elementos del SQA son los siguientes

1. Definición y experiencia

2. Guías y estándares

3. Métricas

4. Revisiones a) Auto revisiones b) Revisiones informales c) Revisiones de paso d) Inspecciones

5. Pruebas a) Unitarias b) Módulo c) Integración d) Sistemas

6. Análisis y Reporte

o software del proyecto; revisar las actividades de ingeniería de software para verificar su ajuste al proceso definido; auditar los productos de software designados para verificar el ajuste con los definidos como parte del proceso; asegurar que las desviaciones del trabajo y los productos del software se documenten y se manejen de acuerdo con un procedimiento establecido y registrar lo que no se ajuste a los requisitos, e informar a los superiores.

Asimismo, coordina el control y administración de cambios, aunado a recopilar y analizar las métricas del software. Uno de los elementos importantes del proceso de SQA son las revisiones técnicas, las cuales se constituyen en reuniones conducidas por personal técnico para personal técnico, donde se analizan detalladamente los productos generados, los eventos que surgen en forma imprevista, etc. Para esta etapa el uso de métricas es esencial. Una rama importante de esta disciplina es el SQA estadístico, donde los datos históricos permiten una mejora continua tanto del producto generado en el proyecto, como de proyectos posteriores. Es importante aseverar que la ingeniería de pruebas es otro factor fundamental para el SQA. Muchas de las actividades a realizar deben estar incorporadas al proceso de desarrollo utilizado por la organización; cabe recalcar que primeramente la organización deberá tener definido su proceso o procesos de desarrollo de software. Aunado a ello, si existen herramientas automatizadas que dan soporte al SQA para probar aplicaciones y componentes de éstas, registrando y ejecutando casos de prueba, así como generándolos en forma automática se logra conseguir una productividad alta.

2.4 Calidad del software en el ciclo de vida del mismo

Dado que la calidad del software está presente en todo su proceso de desarrollo, y siendo más precisos, en su ciclo de vida; la presencia de estándares asociados directa e indirectamente son abundantes. Considerar la calidad del software como importante debe concretarse en entender inicialmente el concepto de “calidad del software”, crear el conjunto de actividades para su implantación, llevar a cabo tales actividades en todo proyecto, utilizar métricas para desarrollar estrategias que mejoren el proceso del software y, como consecuencia, mejoren la calidad del producto final. Una consecuencia indirecta y más importante de no contar con la administración de la calidad es el “inventar el hilo negro” cada vez que se inicia un proyecto de software, se hacen trabajos, particularmente a niveles abstractos, por ejemplo el no aplicar un método o metodología específica.

El uso de estándares ha permitido un entendimiento más claro, o por lo menos, más consistente y un primer acercamiento entre los actores participantes de la industria del software; y dicha tendencia tenderá a incrementarse drásticamente en los siguientes diez años.

2.5 Roles y responsabilidades de los equipos de desarrollo

El responsable de la gerencia es el Gerente SQA. Es la máxima autoridad en la gerencia. El Gerente SQA, será el responsable de la gerencia ante los cargos superiores de la fábrica tal como el Gerente General, y también ante las demás gerencias de la fábrica, por lo tanto es el responsable de que el producto resultante de los proyectos ejecutados por la fábrica, sea software de calidad. Como apoyo al trabajo del gerente, debe existir un subgerente. Este cargo es necesario para que funcione la gerencia. El subgerente reemplazará al gerente cuando éste lo solicite, o bien cuando lo estime necesario en circunstancias de fuerza mayor. Fuera de estos eventos, el subgerente apoyará al gerente directamente al recibir la responsabilidad de tareas asignadas al gerente, de manera que las actividades se repartan en forma equitativa. Es responsabilidad del gerente SQA formar un equipo y definir su estructura organizacional para que las actividades de la Gerencia SQA sean compatibles con los proyectos que desarrolle la fábrica. El requisito tanto para los cargos del gerente y subgerente es que las personas que los desempeñen sean expertas en el uso de estándares para el desarrollo de software. No basta que conozcan los estándares relativos a SQA, sino de todas las gerencias.

Dependiendo del o de los proyectos a realizar, el trabajo del Gerente y Subgerente, estará apoyado por Ingenieros de Especialidad, en un número relativo a la cantidad y envergadura de los proyectos que se ejecuten. Es deber del gerente y subgerente velar para que estos ingenieros estén capacitados profesionalmente, y es obligación del gerente y subgerente, entrenarlos en el uso de estándares para que puedan desempeñar su labor. Los Ingenieros de Especialidad ejecutarán en detalle las tareas definidas en el documento de procesos de la gerencia SQA. A continuación se presenta el organigrama de la gerencia, como se observa en el diagrama, el Gerente de SQA responde directamente al gerente general. El subgerente de SQA, a su vez, le responde al gerente, los ingenieros de especialidad reciben instrucciones del gerente, delegadas por medio del subgerente de SQA. Las decisiones al interior de la gerencia estarán a cargo del Gerente SQA. El Subgerente SQA será su colaborador en todas las decisiones gerenciales.

Es obligación del gerente SQA tomar las decisiones previa discusión con el Subgerente y en acuerdo con éste.

Gerente General

Gerente SQA

Subgerente SQA Ingeniero de Especialidad 1

Ingeniero de Especialidad

En caso de haber discrepancias éstas deben solucionarse en concordancia con los objetivos de la gerencia, cualquier decisión que el Gerente haga sin aprobación del subgerente se considerará una falta de protocolo. En casos extremos, el gerente, previo aviso al subgerente, podrá tomar decisiones solitariamente; en este caso la responsabilidad recaerá en forma total sobre el gerente. Es por esta razón que tanto el gerente como el subgerente deben ser profesionales de alta calidad y con un gran conocimiento en el uso de estándares de fabricación de software.

El objetivo operacional de la gerencia es producir todas las versiones del documento SQAP/XX. Los procesos y actividades necesarias para la realización de estos documentos se encuentra detallada en el documento Proceso de la Gerencia SQA v 0.3. El responsable de que se apliquen los procedimientos descritos en el proceso para la Gerencia SQAP es el gerente SQA. Todo documento que salga de la Gerencia deberá estar revisado y validado por el Gerente y Subgerente SQA. Para producir los documentos SQAP/XX, se necesitan distintos documentos de entrada según la fase que se esté implementando. Es responsabilidad del Gerente SQA, definir y planificar los plazos de entrega de los documentos con las otras gerencias de la fábrica. Para materializar estos intercambios de documentos, delegará estas funciones con el Subgerente de SQA, el cual ejecutará estas acciones, pudiendo delegarlas por proyectos o por especializaciones en los ingenieros de especialidad. En cuanto a los Ingenieros de Especialidad, éstos tendrán que ejecutar en detalle las actividades definidas por el Gerente y Subgerente en los plazos a convenir. Todos los trabajos de los Ingenieros de Especialidad deben ser verificados por la Gerencia y Subgerencia. Es también responsabilidad de la Gerencia definir las actividades y plazos para que los Ingenieros de Especialidad ejecuten las actividades. También es responsabilidad del Gerente y Subgerente apoyar el trabajo de los Ingenieros de Especialidad, Monitorearlo y evaluarlo de manera de que se cumplan las actividades de acuerdo a los procedimientos definidos en los estándares de la Gerencia.

2.6 Habilidades y capacidades del Personal SQA

Detalle del proceso operacional

Gerente SQA

El gerente de SQA deberá realizar estas actividades en cada una de las fases de la fábrica de software, detalladas en el proceso de la gerencia. • Estimar tiempo necesario para planificación, de acuerdo a antecedentes históricos y/o datos de referencia. • Construir WBS general de la gerencia. • Detallar estructura organizacional de la gerencia. • Determinar necesidades de recursos. • Definición de herramientas, métodos y técnicas a ser usadas. • Definir soporte administrativo necesario. • Generar carta Gant general. • Caminatas y reuniones de miembros de la gerencia. • Caminatas y reuniones con las demás gerencias. • Responsabilidad total de la gerencia ante cualquier proyecto. • Responsabilidad de cumplimiento de plazos. •

Responsabilidad ante la gerencia general 2

• Borradores de SQAP/XX. • Delegar tareas y funciones adicionales a integrantes de la gerencia.

Subgerencia SQA

El subgerente de SQA realizará las actividades que se detallan a continuación: • Reemplazar al gerente cuando éste lo solicite, o bien cuando lo estime necesario en circunstancias de fuerza mayor. • Apoyar a gerencia directamente, colaborando en las tareas asignadas al gerente. • Ejecutar el intercambio de documentos con las otras gerencias de la fábrica. • Apoyar, monitorear y evaluar el trabajo de los Ingenieros de Especialidad, velando por que se cumplan las actividades de acuerdo a los procedimientos definidos en los estándares de la Gerencia • Caminatas y reuniones de miembros de la gerencia. • Caminatas y reuniones con las demás gerencias. • Responsabilidad de cumplimiento de plazos. • Responsabilidad ante el gerente de SQA • Colaborar en la confección de los documentos SQAP/XX. • Delegar tareas y funciones adicionales a Ingenieros de Especialidad.

Ingeniero especialidad SQA

A.- Planificaciones Planificación SQAP/UR • Revisión del URD

• Revisar consistencia y completitud de los requisitos del usuario. • Enviar revisiones al usuario para chequear la correctitud de los requisitos. • Registre Tiempos y Defectos en Formularios.

2.7 Actividades del SQA

Es conveniente destacar que hay dos tipos de acciones importantes: las prácticas y las acciones. Entre las prácticas que ayudan a desarrollar una aplicación “sin defectos” destacan:

a) La Administración de requerimientos; b) La Administración de las versiones de los diferentes elementos que forman el software (documentos, programas, etc.) c) Administración y autorización de cambios a las especificaciones iniciales del cliente; d) Administración del proyecto; e) Ciclo de desarrollo “cíclico o en espiral”; f) Administración de riesgos; A continuación alguna de las acciones específicas para “Asegurar la Calidad”: a) Verificación de que elaboraron los productos intermedios o entregables de cada actividad o tarea; b) Inspección de los productos elaborados por un “colega” en busca de defectos; c) Desarrollo de un prototipo; d) Pruebas de “caja negra” de funcionalidad, integración y regresión; e) Pruebas de “volumen y estrés”. El Aseguramiento de la Calidad no únicamente depende de las acciones señaladas, sino que además requiere como pre-requisito:

a. Compromiso de la alta dirección para desarrollar o mantener software con un proceso de calidad; b. Selección y adopción de un proceso de desarrollo o mantenimiento de software; c. Capacitación al personal técnico en el proceso de desarrollo o mantenimiento de software;

d.Capacitación sobre “calidad” a todo el personal; e. Capacitación al personal que desarrolle actividades de liderazgo o administración; f. Desarrollo de un sistema de gestión de calidad, preferentemente basado en la ISO-15504; g. Compromiso en desarrollar “capacidad y madurez de competencias” como organización (se puede evaluar a través de la ISO-15504). h. Capacitación al personal en las herramientas técnicas utilizadas durante el proyecto.

Los elementos anteriores no “garantizan” el desarrollo o mantenimiento de una aplicación libre de defectos; sin embargo, reducen notablemente el riesgo de que ocurran. El futuro del Aseguramiento de la Calidad del Software en México, es bastante promisorio. Se está “sensibilizando” la industria nacional. La Secretaría de Economía está integrando el Aseguramiento de la Calidad a su proceso de software.

Quizá, lo mas evidente es la certificación ISO-9000:2000 al sistema de gestión de la calidad del proceso de desarrollo y mantenimiento de software; sin embargo, el verdadero objetivo es “desarrollar y mantener las aplicaciones, satisfaciendo los requisitos de los usuarios, superando sus expectativas y entregando las aplicaciones en fecha y libre de defectos”.

2.8 Métodos y herramientas

Gestión de la calidad del software (Software Quality Management)

• Gestión de la calidad (ISO 9000) o Conjunto de actividades de la función general de la dirección que determina la calidad, los objetivos y las responsabilidades, y se implanta por medios tales como la planificación de la calidad y la mejora de la calidad, en el marco del sistema de calidad.

•Política de calidad (ISO 9000) o Directrices y objetivos generales de una organización, relativos a la calidad, tal y como se expresan formalmente por la alta dirección.

• La gestión de la calidad se aplica normalmente a nivel de empresa. También puede haber una gestión de calidad dentro de la gestión de cada proyecto.

Control de la calidad del software (Software Quality Control)

• Son las técnicas y actividades de carácter operativo, utilizadas para satisfacer los requisitos relativos a la calidad, centradas en dos objetivos fundamentales: o Mantener bajo control un proceso. o Eliminar las causas de los defectos en las diferentes fases del ciclo de vida. • En general son las actividades para evaluar la calidad de los productos desarrollados.

Sistema de calidad

• Sistema de calidad o Estructura organizativa, procedimientos, procesos y recursos necesarios para implantar la gestión de calidad.

• El sistema de calidad se debe adecuar a los objetivos de calidad de la empresa.

La dirección de la empresa es la responsable de fijar la política de calidad y las decisiones relativas a iniciar, desarrollar, implantar y actualizar el sistema de calidad.

•Un sistema de calidad consta de varias partes o Documentación Manual de calidad. Es el documento principal para establecer e implantar un sistema de calidad. Puede haber manuales a nivel de empresa., departamento, producto, específicos (compras, proyectos….) o Parte física: locales, herramientas, computadoras, etc. o Aspectos humanos: Formación de personal. Creación y coordinación de equipos de trabajo.

• Normativas o ISO ISO 9000: Gestión y aseguramiento de calidad (conceptos y directrices generales) Recomendaciones externas para aseguramiento de la calidad (ISO 9001, ISO 9002, ISO 9003) Recomendaciones internas para aseguramiento de la calidad (ISO 9004)

Certificación de la calidad (Quality Certification)

• Un sistema de certificación de calidad permite una valoración independiente que debe demostrar que la organización es capaz de desarrollar productos y servicios de calidad. • Los pilares básicos de la certificación de calidad son tres: o Una metodología adecuada. o Un medio de valoración de la metodología o La metodología utilizada y el medio de valoración de la metodología deben estar reconocidos ampliamente por la industria.

Unidad 3 Estándares de calidad aplicados al software

Introducción.

Como hemos visto a lo largo de esta materia la calidad hace referencia a un conjunto de características explicitas e implícitas que hace de un producto en este caso un software cumpla con esas propiedades para que satisfaga las necesidades que el cliente requiera, pero no solamente es el desarrollo del software sino todo el proceso de aseguramiento que se aplique con el fin de elaborarlo de la mejor calidad posible llevando esto al seguimiento y utilización de estándares ya establecidos para lograr ese objetivo que es muy difícil de lograr.

Estándares de calidad aplicada al software Entremos en detalle hoy en día la calidad es importante para poder satisfacer a los clientes que pidan un sistema de calidad y cada vez hay mucho mayor competitividad en este mundo de la informática lo cual hace que cada uno de los desarrolladores busque opciones del como poder desarrollar software de calidad y en ello se han creado desde hace mucho tiempo atrás los estándares que hoy en día rigen en torno a este mundo para el desarrollo correcto de aplicaciones de calidad cumpliendo con sus normas y parámetros en aras de conseguir la ansiada calidad, y en este trabajo hablaremos específicamente de 3 estándares aplicados al desarrollo de software y esos son: ISO SPICE CMM

3.1 ISO

La Organización Internacional para la Estandarización, mejor conocida como ISO, es la agencia especializada en estandarización, fue establecida oficialmente el 23 de febrero de 1947 con el objeto de promover la estandarización internacional, de tal manera que se facilitara el intercambio internacional de bienes y servicios casi como el desarrollo científico y tecnológico. Actualmente abarca los estándares nacionales de 91 países y en los Estados Unidos, la representación se llama The American National Standards Institute (ANSI).ISO comprende alrededor de 180 Comités técnicos. Cada uno es responsable de una o más áreas de especialización, abarcan desde las abreviaturas de los sistemas de medición hasta la especificación de protocolos de transferencia, pasando por especificación de tornillos, lentes, contenedores marítimos, medios magnéticos, hojas de papel, cables, elementos estructurales, pruebas de seguridad, simbología, medio ambiente, etc., y por supuesto software.

Que son la serie de estándares ISO?????Las series de ISO 9000 son un grupo de 5 individualidades, pero relacionadas entre sí, siendo estándares internacionales de administración de la calidad y aseguramiento de la misma. Algunos de los beneficios que se alcanzan al instrumentar estas series en la empresa, son: La

posibilidad de darle calidad al producto o servicio. Evitar costos de inspecciones finales, costos de garantías y procesos. Puede reducirse el número de auditorías de los clientes a los procesos de operación. Mayor aceptación por parte de los clientes y acogida en los mercados tanto nacionales como internacionales.

Hablemos de nuestro estándar el ISO 9000-3En estos días & quot; alidad & quot; es la palabra que ocupa gran relevancia ya que los consumidores esperan productos de calidad para satisfacer sus necesidades, soluciones a sus problemas y obtener beneficios de la misma. Sin embargo como es de suponerse dentro de la industria del software, la & quot; calidad & quot; no ha sido el fuerte dentro de la rama. Las tres fallas predominantes que existen dentro de la industria del software son los altos costos en cuanto a depuración de un sistema, tiempo perdido en la corrección del sistema y la falla de conocer todas las necesidades del usuario, trayendo como consecuencia la perdida de clientes ya que se dejan insatisfechos con los pobres resultados de la inversión hecha por el cliente. Hoy en día la industria del software está implementando modelos para mejorar sus operaciones y corregir sus fallas y la expectativa es colocar el desarrollo de software bajo un control estadístico para verificar cuáles son las actividades repetitivas que continuamente se tienen que programar, y que producen exactamente el mismo resultado. Uno de estos modelos base son las normas estándares de calidad ISO 9000 que en especial han creado un interés masivo para la industria de software a causa de su aceptación a nivel internacional de muchas componías importantes.

ISO 9000-3 Generalidades Título: Normas de gestión de la calidad y garantía de la calidad. Parte 3: Orientaciones para la aplicación de la Norma ISO 9001 al desarrollo, suministro y mantenimiento del software. Naturaleza: Internacional. Ámbito: Desarrollo de Sistemas de Información, Procesos del ciclo de vida, Calidad del software. Campo de aplicación y alcance: Esta parte de la ISO 9000 contiene orientaciones que facilitan la aplicación de la Norma ISO 9001 a las organizaciones dedicadas al desarrollo, suministro y mantenimiento del software. Se pretende con ella dar orientaciones en relación con situaciones en las que un contrato entre dos partes exija la demostración de la capacidad de determinado proveedor para desarrollar, suministrar y mantener productos de software.

Estructura Sistema de la calidad.

Responsabilidad de la gestión. Sistema de la calidad. Auditorías internas al sistema de la calidad. Acciones correctivas. Sistema de la calidad . General.

Análisis del contrato Especificación de los requisitos del comprador Planificación del desarrollo Planificación de la calidad Proyecto e implementación Pruebas y validaciones Aceptación Reproducción, entrega e instalación Mantenimiento Sistema de la calidad - actividades de apoyo (independientes de cualquier

fase) Gestión de la configuración Control de documentos Registros de la calidad Medición Reglas, prácticas y convenciones Herramientas y técnicas Aprovisionamento Productos de software incluidos

Secciones de la norma ISO 9000-3

Responsabilidades de la dirección Sistemas de calidad Revisión del contrato Control de documentos y datos Productos provistos por el comprador Identificación y trazabilidad del producto Inspección y pruebas Equipos de Inspección, medición y pruebas Estado de Inspección y pruebas Control de producto no conforme Acciones correctivas y preventivas Manejo, almacenaje, empaque, preservación y embargue Control de registros de calidad Auditorías internas de calidad Capacitación Técnicas estadísticas

3.2 Estándar SPICE

SPICE es una importante iniciativa internacional para apoyar el desarrollo de una Norma Internacional para la Evaluación de Procesos de Software. El proyecto tiene tres objetivos principales: Para desarrollar un proyecto de trabajo para un estándar para la evaluación de procesos de software. Para llevar a cabo los ensayos de la industria de la norma emergente. Para promover la transferencia de tecnología de la evaluación de procesos de software en la industria mundial del software a nivel mundial. ¿Por qué una norma internacional? Los métodos de Evaluación de Procesos de Software vienen más en general a utilizar en la gestión de desarrollo de software, adquisición y utilización, frente a la evidencia sustancial del éxito de estos métodos en el impulso de mejoras en la calidad y la productividad. El impulso principal para el uso de la evaluación no ha venido de la corriente principal de la industria de desarrollo de software, sino más bien a los adquirentes de las grandes críticas de software sistemas intensivos - en particular en los sectores de defensa y telecomunicaciones.

El creciente número de métodos de evaluación disponibles, y la creciente utilización de la técnica comercial en áreas sensibles, fueron los factores clave que impulsaron el desarrollo y la aceptación de una propuesta para desarrollar un estándar internacional para la evaluación de procesos de software. Una Norma Internacional sobre Evaluación de Procesos de Software ofrecerá los siguientes beneficios a la industria y los usuarios del software: Beneficios para la Industria del Software Los proveedores de software se someterá a un solo esquema de proceso de evaluación. Las organizaciones de desarrollo de software tendrá una herramienta para iniciar y sostener un proceso continuo de mejora. Los directores de programas tendrán un medio para garantizar que su desarrollo de software está en consonancia con, y apoya, las necesidades comerciales de la organización

Beneficios para los compradores de software de: Los compradores podrán determinar la capacidad de los proveedores de software y evaluar el riesgo implicado en la selección de un proveedor sobre otro. Todas las industrias dependen ahora de software para la ventaja competitiva. El crecimiento sólo se conseguirá si cumple con la industria e incluso supera las normas internacionales y mundos mejores prácticas. Al contribuir al desarrollo de esta nueva norma, los países participantes y organizaciones se asegurará de que están a la vanguardia de esta nueva tecnología y dispuesto a cumplir la norma cuando llegue a la situación de una Norma Internacional.

3.3 Estándar CMM

CMM es el máximo estándar en ingeniería de software Innovación, velocidad y satisfacción del cliente se han convertido en la consigna de las organizaciones que quieren sobrevivir y crecer en el cada vez más competitivo mundo moderno. Como las tecnologías de información resultan fundamentales para lograrlas, el software se ha constituido en la piedra angular sobre la cual se soportan la gran mayoría de los nuevos modelos de empresa.

La creciente necesidad, sumada a décadas de promesas incumplidas en cuanto a calidad, costos y cumplimiento en el desarrollo de software, condujo al Instituto de Ingeniería de Software de los Estados Unidos a desarrollar el modelo CMM (CapabilityMaturityModel - Modelo de Madurez de Capacidad).El CMM está compuesto de 316 prácticas claves agrupadas en 18 áreas y distribuidas en una jerarquía de cinco niveles, a través de los cuales una organización progresivamente alcanza mayor calidad, productividad y menores costos en el desarrollo de software. Los niveles progresan desde el 1, que representa el estado caótico, hasta el nivel 5, que representa el estado de optimización continua.

Niveles del Estándar CMM

Nivel 1. Inicial. En este nivel, los procesos y métodos de ingeniería no se encuentran definidos. Por esa razón, los proyectos son adelantados de manera incoherente, incontrolada y poco profesional.

Nivel 2. Repetible. Se establecen algunos procesos y métodos de ingeniería a nivel de proyectos, aún incipientes.

Nivel 3. Definido. Los procesos, actividades y métodos relacionados con la ingeniería y administración de proyectos se encuentran documentados, estandarizados y construidos alrededor de un marco integrado para toda la compañía.

Nivel 4. Administrado. La compañía opera bajo Control Estadístico de Procesos, tanto en procesos como en productos.

Nivel 5. Optimización. En este nivel, las organizaciones se encuentran en un proceso de mejoramiento continuo. Todos los procesos y técnicas modernas están en pie, lo mismo que la administración cuantitativa.

Unidad 4 Calidad enfocada al desarrollo de software

4.1 ¿Que Es La Calidad Del Software?

. 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.

Pero esto puede resultar muy costoso si se detectan problemas derivados 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.

4.2 Como obtener Calidad de Software (métodos, metodologías, estándares)

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. 4.3-

4.3 Como Controlar la Calidad del Software

Definir los parámetros, indicadores o criterios de medición. 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.

4.4 Costo de la Calidad del Software

El Costo de la Calidad del Software CoQ, es una técnica introducida por Juran en 1996 con el fin de proporcionar a los directores de proyectos instrumentos que les permitan justificar la promoción de mejoras en el proceso de desarrollo.

• Costos de Prevención: planificación de la calidad, revisiones técnicas formales, equipo de pruebas, formación.

• Costos de Evaluación: inspección de cada proceso y entre procesos, pruebas.

• Costos de Fallos Internos: antes de la entrega. (Reparación, revisión, análisis)

• Costos de Fallos Externos: después de la entrega. (Resolución, soporte, reemplazo)

4.5 Nomenclatura y Certificación ISO 9001 2000

La norma ISO 9001, es un método de trabajo, que se considera tan bueno, Que es el mejor para mejorar la calidad y satisfacción del consumidor.

La versión actual, es del año 2000 ISO 9001:2000, que ha sido adoptada como modelo a seguir para obtener la certificación de calidad por todas las empresas.

Estos principios básicos de la gestión de la calidad, son reglas de carácter social encaminadas a mejorar la marcha y funcionamiento de una organización mediante la mejora de sus relaciones internas.

La certificación en la norma 9001, es un documento con validad legal que acredita y que certifica, que usted cumple las más estrictas normas de calidad, en aras a una mejora de la satisfacción del cliente.

Hay dos tipos de certificaciones, de empresa y de producto. Estas últimas, solo tienen en cuenta la calidad técnica del producto. Y no la satisfacción del cliente, de la que se ocuparía la certificación de empresa. Si una empresa está certificada, todos sus productos lo están.

4.6 La Norma Iso Iec 9126

ISO/IEC 9126-1: Tecnología de dotación lógica – calidad del producto

ISO/IEC 9126 (1991) ha sido substituido recientemente por un nuevo estándar de cuatro partes que ha reconciliado los dos acercamientos a la utilidad. ISO/IEC 9126-1 describe las mismas seis categorías de la calidad del software que son relevantes durante el desarrollo de producto: funcionalidad, confiabilidad, utilidad, eficacia, capacidad de mantenimiento y portabilidad.

Calidad del software cuando el producto es funcionando. El objetivo total es alcanzar la calidad funcionando, para el usuario final y el usuario de la ayuda.

La funcionalidad, la confiabilidad, la eficacia y la utilidad determinan la calidad funcionando para un usuario final en un contexto particular. El usuario de la ayuda se refiere a la calidad funcionando de tareas del mantenimiento y de la portabilidad.

4.7 Análisis Factores Determinan Calidad Software

Los factores que determinan la calidad se pueden clasificar en 2 grandes grupos:

1- Factores que se pueden medir directamente (Ej. errores / unidad de tiempo)

2- Factores 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:

1- Características Operacionales

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?

2- Capacidad 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 rehusar en otras aplicaciones. Este factor tiene una pregunta asociada: ¿Podré rehusar 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?

2- 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 Auditoria 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

Auto-Documentación

El grado en que el código fuente proporciona documentación significativa

4.8 Analisis Proceso Ciclo Vida Software

Etapas en el ciclo.

Veamos, a grandes rasgos, una pequeña descripción de etapas con que podemos contar a lo largo del ciclo de vida del software.

Expresión de necesidades

Esta etapa tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar). Dado que normalmente se trata de necesidades del cliente para el que se creará la aplicación, el documento resultante suele tener como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relación comercial, siendo que debe ser comprendido por ambas partes (puede incluso tomarse como base para el propio acuerdo comercial).

Especificaciones

Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar.

Por medio de esta etapa se obtendrá un nuevo documento que definirá con más precisión el sistema requerido por el cliente (el empleo de los casos de uso, use cases, de Jacobson es una muy buena elección para llevar a cabo la especificación del sistema).

Del sistema a la primera; serán necesarias sucesivas versiones del documento en que irán quedando reflejada la evolución de las necesidades del cliente (por una parte no siempre sabe en los primeros contactos todo lo que quiere realmente, y por otra parte pueden surgir cambios externos que supongan requerimientos nuevos o modificaciones de los ya contemplados).

Análisis

Es necesario determinar que elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades, … que van a dar una descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué comportamiento va a tener. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes:

Funcional. Estático. Dinámico.

Diseño

Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar como va a hacerlo (¿cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de

casos de uso esenciales a su definición como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc.).

Implementación

Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos.

Pruebas

El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, p.ej. de rendimiento).

Validación

Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos

Mantenimiento y evolución

Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (p.ej. mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución (p.ej. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto).

4.9 Funciones Evaluación del Software

Las técnicas de evaluación estática se aplican en el mismo orden en que se van generando los distintos productos del desarrollo siguiendo una filosofía top-down. Esto es, la evaluación estática acompaña a las actividades de desarrollo, a diferencia de la evaluación dinámica que únicamente puede dar comienzo cuando finaliza la actividad de codificación, siguiendo así una estrategia botomup.

La evaluación estática es el único modo disponible de evaluación de artefactos para las primeras fases del proceso de desarrollo (análisis y diseño), cuando no existe código.

Así pues, la importancia de las técnicas estáticas de evaluación a la hora de controlar el nivel de calidad con el que se está llevando a cabo el desarrollo es crucial, la estimación de faltas que aún quedan en un producto utilizando datos de las revisiones permite dos acciones que ayudan a prevenir futuros defectos en el proyecto:

Seguir revisando el producto para disminuir el número de faltas remanentes.

Tomar medidas correctivas del desarrollo si las estimaciones indican que se está llevando a cabo un trabajo pobre. Es decir, si las estimaciones de faltas.

Bibliografía

http://translate.googleusercontent.com/translate_c?hl=es&sl=en&u=http://www.sqi.gu.ed

http://cronicasdel.wordpress.com/2011/06/04/unidad-4-calidad-enfocada-al-desarollo-del-software/

http://www.buenastareas.com/ensayos/Calidad-Del-Software/1209577.html#