La calidad del software (página 2)

El costo total de una gestión eficaz de la calidad es la suma de cuatro componentes de costos que son: Costos de prevención, de inspección, de fallas internas y de fallas externas. Los costos de prevención consisten en las medidas adoptadas para prevenir los defectos que se produzcan en las primeras etapas de producción. Los costos de inspección consisten en medir, evaluar, y auditar los productos o servicios de conformidad con las normas y especificaciones. Los costes de fallas internas son aquellos incurridos por la detención de los productos defectuosos antes de ser entregados al cliente. Los costes de fallas externas consisten en los costos de defectos descubiertos después de que el producto ha sido puesto en libertad es decir que ha salido al consumidor. Esta última puede ser devastadora, ya que pueden dañar la reputación de la empresa o resultar en la perdida de ventas futuras. La mejor forma de recuperar la inversión es la prevención. El incrementar el énfasis en prevenir reduce el número de defectos que van al cliente sin ser detectados, mejora la calidad del producto, y reduce el coste de producción y mantenimiento.

Verificación versus Validación

La verificación es demostrar que un producto cumple con los requisitos especificados durante las actividades previas llevadas a cabo correctamente durante el ciclo de vida de desarrollo, y la validación comprueba que el sistema cumple con los requisitos del cliente al final del ciclo de vida de desarrollo. Se trata de una prueba de que el producto cumple con las expectativas de los usuarios, y asegura que el programa ejecutable funciona tal como se había especificado. La creación de programas de prueba está más estrechamente relacionada con la validación que con la verificación.

Tradicionalmente, la prueba del software ha sido considerada como un proceso de validación, es decir, como una fase del ciclo de vida de desarrollo de sistema. Después que el programa ha sido completado, el sistema es validado o probado para determinar su desempeño funcional y operativo.

Cuando la verificación se incorpora a las pruebas, las pruebas se presentan en todo el ciclo de vida de desarrollo. Para obtener los mejores resultados, es una buena práctica el combinar la verificación con la validación en el proceso de prueba. La Verificación incluye procedimientos sistemáticos de revisión, análisis y pruebas, empleados durante todo el ciclo de vida de desarrollo del software, comenzando con la fase de requerimientos del software y atraves de la fase de codificación. La Verificación garantiza la calidad en la producción de software y su mantenimiento. Además, la verificación impone como un desarrollo organizado y sistemático-práctico que asegura que el programa resultante puede ser fácilmente comprendido y evaluado por un tercero independiente.

La Verificación surgió hace unos 20 años como resultado de que la industria aeroespacial necesitaba de software muy fiable en sus sistemas en los que un error en uno de esos programas podría ocasionar un fallo en la misión dar lugar a una gran cantidad de pérdida de tiempo y reveses financieros, o incluso situaciones que amenazan la vida. El concepto de verificación incluye dos criterios fundamentales: el software debe adecuarse de forma correcta y realizar todas las funciones previstas, y en segundo lugar el software no debe llevar a cabo cualquier función que sea por sí sola o en combinación con otras funciones que pueda degradar el rendimiento de todo el sistema. El objetivo general de la verificación es asegurar que cada producto de software desarrollado durante todo el ciclo de vida de desarrollo satisfacen las necesidades del cliente y sus objetivos tal como se especificó en el documento de requerimientos del software.

La verificación también establece trazabilidad (capacidad de seguir una representación del diseño o de un componente del programa hasta los requisitos) entre las diversas secciones de la documentación del software y las partes asociadas de los requerimientos de especificaciones. Un esfuerzo de verificación integral garantiza que todos los requisitos de rendimiento del software y las especificaciones de la calidad están adecuadamente probados y que los resultados del examen se pueden repetir después de los cambios en la instalación.

La verificación es un "proceso de mejora continua" y no tiene un final definitivo.Se debe utilizar durante todo el ciclo de vida de desarrollo del sistema para mantener la configuración y la integridad operativa.

La verificación garantiza que el software funciona según lo previsto y tiene losatributos necesarios (por ejemplo, la portabilidad), y aumenta las posibilidades de que el software contiene pocos errores (es decir, un número aceptable de errores en el producto final). Proporciona un método para vigilar de cerca el desarrollo del proyecto del y proporciona un monitoreo de la gestión del proyecto en cualquier momento. Cuando se utilizan los procedimientos de verificación, la gerencia puede estar segura de que los desarrolladores siguen un proceso formal, secuencial, y trazable de desarrollo de software, con un conjunto mínimo de actividades para mejorar la calidad del sistema.

Una de las críticas de la verificación es que aumenta los costos del desarrollo de software considerablemente. Cuando el costo del software es considerado a lo largo de ciclo de vida total es decir desde el inicio hasta el abandono definitivo del sistema, Sin embargo, la verificación en realidad reduce el coste global del software. Con un programa de verificación eficaz, se puede reducir los defectos de cuatro a uno en el sistema instalado., porque corregir un error durante las operaciones y mantenimiento puede constar de 20 a 100 veces más que durante el diseño, por tal razón el ahorro global superan con creces el gasto adicional inicial

Aseguramiento de la calidad del software

Una definición formal de aseguramiento de la calidad del software es que es una actividad sistemática de ejercicios o tareas que aportan pruebas y evidencias del uso total del software o producto. La Garantía de calidad del software se logra mediante el uso y establecimiento de directrices para el control de calidad para garantizar la integridad y la prolongada vida del software. Las relaciones entre la garantía de calidad, control de calidad, la función de auditoría y pruebas de software a menudo se confunden.La garantía de calidad es el conjunto de actividades de apoyo necesario para proporcionar adecuada confianza en que los procesos son establecidos y continuamente mejorados con el fin de producir productos que cumplan con las especificaciones y están en condiciones para su uso. El control de calidad es el proceso mediante el cual se compara la calidad del producto con las normas aplicables y las medidas adoptadas de no conformidad cuando se detecta. La auditoría es la inspección o actividad de evaluación que verifica el cumplimiento de los planes, políticas y procedimientos.

El aseguramiento de la calidad del software es un esfuerzo planificado para asegurarse de que un software o producto cumple con estos criterios y tiene otros atributos específicos del proyecto, por ejemplo, la portabilidad, la eficiencia, reutilización y flexibilidad. Es un conjunto de actividades y funciones que se utilizan para monitorear y controlar el proyecto de software para que los objetivos específicos se logren con el deseado nivel de confianza. No es la única responsabilidad del grupo de calidad del software, pero está determinado por el consenso del director director del proyecto, líder del proyecto, el personal del proyecto, y los usuarios.

El aseguramiento de la calidad es una función responsable de la gerencia de la calidad. La palabra "seguridad" significa que si los procesos se siguen, la gerencia puede estar segura de la calidad del producto. La garantía de calidad es una función catalítica que deben fomentar actitudes de calidad y disciplina por parte de la gerencia y los trabajadores. El éxito de los gerentes de control de calidad es saber hacer conciencia en la gente sobre la calidad y de hacerlos reconocer los beneficios de calidad para ellos y para la organización.Los objetivos de calidad del software se logran típicamente siguiendo un plan de aseguramiento de la calidad del software que establece los métodos del proyecto a emplear para asegurar que los documentos o los productos elaborados y revisados en cada etapa son de alta calidad. Este enfoque garantiza que explícitamente todas las medidas se han adoptado para lograr la calidad del software y proporciona una gestión con la documentación de esas acciones. El plan establece los criterios por los actividades de calidad que pueden ser monitoreados en lugar de establecer objetivos imposibles objetivos, como software de cero defectos o software 100 por ciento confiable.El aseguramiento de la calidad del software es una estrategia para la gestión de riesgos. Existe debido a que la calidad del software es típicamente costosa y deben ser incorporados en la gestión de riesgos formal de un proyecto. Algunos ejemplos de software con niveles de calidad muy pobre incluyen:• Se entrega el software con fallas frecuentes.

• Las consecuencias de las fallas del sistema son inaceptables, desde el punto de vista financiero y de escenarios de riesgo para la vida.

• Los sistemas a menudo no están disponibles para los fines previstos.

• Hacer mejoras al sistema es a menudo muy costoso

• Los costos de detectar y eliminar defectos son excesivos.

Aunque la mayoría de los riesgos de calidad están relacionados con defectos, esto sólo es una parte de la historia. Un defecto es un incumplimiento de un requisito. Si los requisitos son insuficientes o incorrectos, incluso, los riesgos de defectos son más generalizados.El resultado es una gran cantidad de defectos en los productos que no son verificables. Algunas de las estrategias de gestión de riesgos y técnicas incluyen el software pruebas, técnicas de revisiones, evaluaciones inter pares, y la verificación de cumplimiento

Componentes de Aseguramiento de la Calidad

La mayoría de las actividades de aseguramiento de la calidad del software se pueden clasificar en software de pruebas, es decir, de verificación y de validación, Gestión de configuración de software y control de calidad. Pero el éxito de los programas de aseguramiento de la calidad del software también depende de un conjunto coherente de normas, prácticas, convenciones, y especificaciones, como se muestra en la figura 1.1.

Pruebas de Software (TESTING)

Las pruebas de software es una estrategia particular de gestión de riesgos. Se utiliza para verificar que los requisitos funcionales se cumplieron. La limitación de este enfoque, Sin embargo, es que por el tiempo de prueba se produce, es demasiado tarde para construir la calidad en el producto. Las pruebas son tan buenas como los casos de prueba, pero se puede inspeccionar para asegurar que todos los requisitos se ponen a prueba en todos las posiblescombinaciones de insumos y los estados del sistema. Sin embargo, no todos los defectos se descubren durante la prueba. Las pruebas de software incluyen las actividades descritas en este texto, incluyendo las actividades de verificación y validación. En muchas organizaciones, estas actividades, o su supervisión, se incluyen en el chárter de funciones del aseguramiento de la calidad del software. Incluyendo personal independiente de diseño y codificación que deben participar en las actividades del aseguramiento de la calidad del software, dichas actividades dependen de políticas institucionales y políticas del proyecto.

El objetivo principal de las actividades de verificación y validación es asegurarque el diseño de software, del código, de la documentación cumplen todos los requisitos que se les impone. Ejemplos de requisitos incluyen necesidades de los usuarios; derivados de las especificaciones y diseñados para satisfacer las necesidades del usuario, la revisión del código e inspección de los criterios, requisitos de prueba en el subsistema modular, e integración de los niveles de software, pruebas y la aceptación del código después de haber sido totalmente integrado con el hardware.

Durante el diseño e implementación del software, la verificación ayuda a determinar si los productos de la primera fase del ciclo de vida de desarrollo del software cumplen con los requisitos establecidos en la fase anterior. Lasactividades de verificación tardan menos tiempo y es menos complejo cuando se realiza en todo el proceso de desarrollo.

Control de Calidad

El control de calidad es definido como los procesos y los métodos utilizados para controlar el trabajo y observar si se cumplen los requisitos. Se centra en la revisión y eliminación de los defectos antes del envío de los productos. El control de calidad debe ser la responsabilidad de la unidad organizativa de producción del producto. Es posible tener el mismo grupo que se encarga de construir el producto y el que se encarga de las funciones de control de calidad, o establecer un grupo de control de calidad o departamento dentro de la unidad de organización que desarrolla el producto.

El control de calidad en un producto consiste en controles bien definidos que son especificadas en el plan de aseguramiento de la calidad del producto. Para productos de software, el control de calidad incluye típicamente revisiones de especificaciones, comentarios, listas de condiciones, documentación del código, y los controles de las prestaciones del usuario. Por lo general, el documento de inspecciones de productos se lleva a cabo en cada etapa del ciclo de vida para demostrar que los artículos producidos se encuentran dentro de los criterios especificados del plan de aseguramiento de la calidad del software. Estos criterios normalmente se encuentran en las especificaciones de requisitos, documentos conceptuales y de diseño detallado, y los planes de prueba. Los documentos entregados a los usuarios son los requisitos de especificaciones, documentación de diseño, los resultados de la aceptación de los usuarios, pruebas, el código de software, guía del usuario, y la guía de operaciones y mantenimiento. Documentos adicionales se especifican en el plan de aseguramiento de la calidad del software.

El control de calidad puede ser proporcionado por diversas fuentes. Para proyectos pequeños, el personal del proyecto de grupo de pares o la calidad del departamento de software coordinador puede inspeccionar los documentos. En proyectos grandes, un tablero de configuración de control puede ser el responsable del control de calidad. El consejo puede incluir a los usuarios o un representante de los usuarios, un miembro del departamento de la calidad del software, y el líder del proyecto.

Las inspecciones son funciones tradicionales de control de calidad, es decir, exámenes independientes para evaluar el cumplimiento de algunos criterios establecidos. Por expertos en la materia objeto de examen especificaciones y productos de obras de ingeniería para identificar los defectos y proponer mejoras. Se utilizan para examinar el proyecto de software para la adhesión a las normas del proyecto por escrito en un proyecto de hitos y en otros momentos durante el ciclo de vida del proyecto como se consideren necesarias en el líder del proyecto o la garantía de la calidad del software de personal.

Una inspección puede ser una lista detallada para evaluar el cumplimiento o una breve lista de comprobación para determinar la existencia de las prestaciones, tales como documentación. Un informe donde se indique el objeto de la inspección y las deficiencias que se encuentran va al supervisor del proyecto, responsable del proyecto, y el personal del proyecto para la acción.

La responsabilidad de las inspecciones se indica en el plan de calidad del software. Para proyectos pequeños, el líder del proyecto o la calidad del departamento coordinador pueden realizar las inspecciones. Para los proyectos grandes, un miembro del grupo de software de control de calidad

Puede conducir una inspección realizada por un equipo de auditoría, que es similar a la tarjeta de control de configuración mencionados con anterioridad. Después de la inspección, el personal del proyecto se asigna para corregir los problemas en un horario específico. El control de calidad está diseñado para detectar y corregir los defectos, mientras que el aseguramiento de la calidad está orientado hacia la prevención de ellos. La Detección de defectos en los procesos implica que se supone que para producir productos y servicios libres de defectos. El aseguramiento de la calidad es una función de gestión que evita esos problemas en la partida que se alejen, y asesorando a la moderación y la redirección.

Gestión de configuración del software

La gestión de configuración del Software tiene que ver con el etiquetado, seguimiento, y control de los cambios en los elementos de software de un sistema. El sistema de gestión de configuración de software Controla la evolución de las versiones del software y sus relaciones.

El propósito de la gestión de configuración de software es la identificación de todos los componentes interrelacionados de software y su controlar su evolución a lo largo de las diferentes fases del ciclo de vida. La gestión de configuración de Software es una disciplina que puede aplicarse a actividades que incluyen el desarrollo de software, el control de documentos, el seguimiento de problemas, y el control de cambios, y mantenimiento. Se puede proporcionar un ahorro alto de los costos en la reutilización de software ya que cada componente de software y su relación con otros componentes de programas se han definido.

La gestión configuración de Software se compone de actividades que garantizan que el diseño y el código se definen y no se puede cambiar sin una revisión del efecto del cambio en sí mismo y su documentación. El propósito de la gestión de configuración es el control de código y su documentación asociada para que el código final y su descripción sean consistentes y que represente los artículos que fueron revisados y probados en realidad. Por lo tanto, cambios a última hora en el software se eliminan.

Para proyectos concurrentes de desarrollo de software, la gestión de configuración software puede tener considerables beneficios. Se puede organizar el software en fase de desarrollo y reducir al mínimo la probabilidad de cambios involuntarios. La gestión de configuración software tiene un efecto estabilizador en todo el software cuando hay una gran cantidad de actividad de cambio o un riesgo considerable de seleccionar mal los componentes del software.

Elementos de la Gestión de Configuración de Software

La gestión de configuración de software identifica una configuración del sistema con el fin de controlar sistemáticamente los cambios, mantener la integridad, y hacer cumplir la trazabilidad de la configuración de todo su ciclo de vida. Los Componentes a ser controlados incluyen la planificación, análisis y diseño de documentos, código fuente código ejecutable, servicios públicos, el lenguaje de control de trabajos (JCL), planes de prueba, la prueba de secuencias de comandos, los casos de prueba, y los informes de desarrollo. Los procesos de la configuración de software

suele constar de cuatro elementos: la identificación de componentes de software, software de control de versiones, la construcción de configuración y cambio de software de control, como se muestra en la figura 1.2.

Exhibit 1.2. Software Configuration Management

Identificación de los componentes

Una configuración básica de gestión de la activad del software es la identificación de los componentes de software que componen una entrega en cada punto de su desarrollo.la gestión de configuración del Software proporciona directrices para identificar y nombrar las líneas de base de software, componentes de software y configuraciones del software. Los componentes de software pasan por una serie de cambios. Con el fin de gestionar el proceso de desarrollo, es necesario establecer métodos y normas, nombre para la identificación exclusiva de cada revisión. Una forma sencilla de nombre de las revisiones de componente consiste en utilizar una serie de cifras discretas. El primer entero podría se refieren al número de un componente de software de desbloqueo exterior. El segundo entero podría representar el desarrollo interno de software número de versión. La transición de número de versión 2,9 a 3,1 indicaría que un nuevo versión externa 3 se ha producido. El componente de software número de versión se incrementa automáticamente cuando el componente se verifica en el software biblioteca. Además de los niveles de clasificación podría utilizarse también cuando sea necesario, como la fecha de una nueva versión. Una configuración de software es una colección de elementos de software que componen una función de negocio principales. Un ejemplo de una configuración es el conjunto de módulos del programa para un sistema de orden. La identificación de una configuración es bastante similar a la identificación de los componentes individuales de software. Configuraciones se pueden tienen una secuencia de versiones. Cada configuración debe ser nombrada de una manera que lo distingue de los demás. Cada versión de configuración debe ser diferenciada de otras versiones. La identificación de una configuración debe

También incluyen su estado de aprobación y una descripción de cómo la configuración fue construido.

Una técnica simple para identificar una configuración para almacenar todos sus programas componentes en una sola biblioteca o repositorio. La lista de todos los componentes también puede ser documentada.

El control de versiones

Como las aplicaciones evoluciona con el tiempo, son creadas muchas versiones diferentes del software en ese transcurso, y es necesario que haya un proceso organizado de gestionar los cambios en los componentes de software y sus relaciones. Por lo tanto es un requisito el soporte para el desarrollo y mantenimiento de componenetes de software en paralelo.

los programas informáticos van cambiado a medida que evoluciona a través de una sucesión de estados temporales llamadas versiones, es necesario que exista una gestión de control de instalaciones de versiones de software en forma de biblioteca. El control de versiones ofrece la trazabilidad o un historial de cambio realizado en el software, incluyendo quién hizo? Qué?, por qué? y cuándo?. Dentro del ciclo de vida del software, los componentes de software evolucionan, y en un cierto punto cada uno llega a un estado relativamente estable. Pero como los defectos se corrigen y las funciones de mejora se aplican, el resultado de esos cambios da como resultados nuevas versiones del software. Mantener el control de estas versiones de programas es a lo que llamamos control de versiones de componentes.

Un componente es identificado y etiquetado para diferenciarlo de los demás componentes en las versiones del software. Cuando un componente de software es modificado, las ediciones anteriores y las nuevas se pueden identificar por separado. Por lo tanto, cada versión, a excepción de la primera, tiene un predecesor. La sucesión de versiones de los software es la historia de sus diferentes componentes y su maleabilidad. Las diferentes versiones también funcionan como copias de seguridad de modo que uno puede regresar a las anteriores versiones del software.

Configuración de la construcción del software

Para crear una configuración de software que se necesita para identificar las versiones correctas de sus partes y ejecutar los procedimientos de construcción de sus partes. Esto es a menudo es llamado la construcción de configuración.

Una configuración de software consiste en un conjunto derivado de las partes que componen el software o programa. Un ejemplo son los programas objetos ejecutables derivados del código fuente de los programas.

los componentes derivados del software están correctamente asociados a cada componente de origen para obtener una derivación correcta. El modelo de construcción de la configuración define la forma de cómo controlar y juntar los componentes derivados del software.

Las entradas y salidas necesarias para construir el modelo de configuración incluyen los insumos primarios, como los componentes de origen, la selección de la versión de procedimientos y el modelo del sistema, que describe cómo los componentes del software están relacionados. Las salidas son la configuración de destino y sus respectivos componentes derivados del software. Los software de gestión de entorno de configuración utilizan diferentes enfoques para la selección de versiones. El método más sencillo de selección de la versión es mantener una lista de versiones. Otros enfoques usan o selecionan las versiones de pruebas mas recientes, o las modificaciones realizadas en una fecha determinada.

Control de cambios

El control de cambios es el proceso mediante el cual la modificación del software se propone, se evalúa, se aprueba o se rechaza, se programan y se le da seguimiento. Su fundamento básico es un proceso de control de cambios, un estado de los componentes, presentación de informes, y un proceso de auditoría. El control de cambios en el software es un proceso de decisión utilizado en el control de la los cambios realizados al software. Algunos cambios propuestos son aceptados e implementados durante este proceso. Otros son rechazadas o pospuestos, y no se aplican. El control de cambios también se proporciona para el análisis de impacto para determinar las dependencias.

la modificación de una configuración tiene al menos cuatro elementos: una solicitud de cambio, un análisis del impacto del cambio, un conjunto de modificaciones y adiciones de nuevos componentes, y un método fiable para la instalación de las modificaciones como una nueva línea de base, todo esto debe ser registrado en el documento de solicitud de cambio.

Un cambio a menudo implica modificaciones a los componentes de software.

Por lo tanto, un sistema de almacenamiento que proporciona varias versiones de un solo archivo no suele ser suficiente. Una técnica es necesaria para identificar el conjunto de modificaciones como un solo cambio. Esto a menudo se llama el almacenamiento delta. Cada componente de software tiene un ciclo de vida de desarrollo. Un ciclo de vida consiste en estados y las transiciones permitidas entre los estados. Cuando un componente del software se cambia, siempre debe ser revisado y almacenado hasta que una nueva versión sea creada. La autoridad revisora debe aprobar o rechazar las modificaciones realizadas al componente del software. Una librería de software cuenta con todos los componentes de software tan pronto como estos se almacenan y también actúa como un repositorio de componentes homologados.

Uno de los componentes derivados está ligado a su origen y tiene el mismo estatus que su fuente. Además, una configuración no puede tener un estado más completo que cualquiera de sus componentes, porque no tiene sentido para revisar una configuración cuando algunos de los componentes asociados no están almacenados o registrados.

Todos los componentes sometidos a control por software de gestión de configuración y almacenados en una biblioteca de configuración de software, incluidos los productos de trabajo tales como datos de negocio y modelos de procesos, los grupos de arquitectura, diseño de unidades, pruebas del software de aplicación, la reutilización del software, y el software de prueba especial

Cuando un componente de software se va a modificar, este es chequeado en el

repositorio o librería en un espacio de trabajo privado. Se desarrolla a través de muchos estados, que se encuentran temporalmente fuera del ámbito de control de gestión de la configuración.

Cuando un cambio se ha completado, el componente se registró en la biblioteca y se convierte en una versión de software nuevo componente. El componente anterior la versión también se conserva.

El plan de aseguramiento de la calidad

El plan de aseguramiento de la calidad del software (SQA) es un esbozo de las medidas de calidad para garantizar niveles de calidad dentro de un esfuerzo de desarrollo de software. El plan se utiliza como referencia para comparar los niveles reales de calidad durante el desarrollo con los niveles de calidad previstos. Si los niveles de calidad no están dentro de los niveles de calidad previstos, la gerencia debe responder de manera adecuada como se documentó en el plan.

El plan constituye el marco y las directrices para el desarrollo decódigo comprensible y fácil de mantener. Estos ingredientes ayudan a garantizar la cualidad apreciada en un proyecto de software. Un plan de SQA también proporciona los procedimientos para garantizar que la calidad del software se produce o mantiene durante el desarrollo del software. Estos procedimientos afectan a la planificación, a el diseño, la codificación, las pruebas, la documentación, el almacenamiento y mantenimiento de los programas de informática.

Debe ser organizado de esta manera porque el plan garantiza la calidad del software en lugar de describir los procedimientos específicos para el desarrollo y mantenimiento del mismo.

Pasos para desarrollar y aplicar un Plan de Aseguramiento de Calidad de SoftwarePaso 1. Documento del Plan

El plan de aseguramiento (garantía) de la calidad del software debe incluir las siguientes secciones. • Sección Objetivo – Esta sección delinea el propósito específico y ámbito particular del plan de SQA. Se debe indicar el nombre (s) de la elementos de software que abarca el plan de SQA y el uso previsto de lossoftware. Afirma la parte del ciclo de vida del software cubierto por el plan de SQA para cada artículo del software especificado.• Sección de Documento de Referencia – Esta sección incluye una lista completa de los documentos referenciados en cualquier lugar del plan de SQA.

• Sección de Gestión – En esta sección se describe la organización del proyecto su estructura, tareas y responsabilidades.• Sección de Documentación – En esta sección se identifica la documentación que rigen el desarrollo, verificación validación, uso y mantenimiento del software. También afirma que los documentos son para comprobar su adecuación. Esto incluye los criterios y la identificación de las revisiones, auditorias que la adaptación de cada documento sea confirmado.

• Sección de Estándares, prácticas, convenios, y mediciones – En esta sección se identifica las normas, prácticas, convenciones y métricas que seranaplicada, y también indica cómo el cumplimiento de estos elementos serán monitoriado de forma segur

• Sección de Revisiones e Inspecciones – En esta sección se define la técnicas de revisiones de gestión, tutoriales, y las inspecciones a realizar.También indica cómo los exámenes, tutoriales, y las inspecciones se puede lograr incluyendo las actividades de seguimiento y aprobaciones.• Sección de la gestión de configuración de software – Esta sección es tratada en detalle en el plan de la gestión de configuración del proyecto de configuración de software.

•Sección de Problema de Información y Acción Correctiva – Esta sección se trata en detalle el plan del proyecto de gestión de configuración del software.• Sección de la metodología, técnicas y herramientas – En esta sección se identifican las herramientas especiales de software, técnicas y metodologías que apoyo SQA, los estados sus propósitos, y describe su uso.• Sección de control de Código – En esta sección se define los métodos y las instalaciones utiliza para mantener, almacenar, proteger, controlar y documentar la versiones del software identificado durante todas las fases de desarrollo. Esto puede ser implementado en conjunto con un programa de ordenador biblioteca y / o que puedan establecerse como parte de la configuración de software plan de manejo.• Sección de Control de los medios de comunicación – Esta sección establece los métodos e instalaciones que se utilizará para identificar los medios de comunicación para cada producto y equipo la documentación requerida para almacenar los medios de comunicación, incluyendo la copia y el proceso de restauración, y protege el programa de computadora físicalos medios de comunicación del acceso no autorizado o daño accidental o deterioro durante todas las fases de desarrollo. Esto puede ser proporcionado por el configuración de software de gestión del plan.

• Sección de control del proveedor – Esta sección establece las disposiciones para asegurar que el software proporcionado por los proveedores cumple establecido los requisitos. Además, debe indicar los métodos que se utiliza para asegurar que el proveedor de software recibe suficientes y los requisitos completos. Para previamente desarrollado un software, en esta sección estados los métodos que se utilizan para asegurar la idoneidad de los producto para su uso con los elementos de software cubierto por el plan de SQA.{Para el software a desarrollar, el proveedor estará obligado a preparar e implementar un plan de SQA de conformidad con esta norma.En esta sección también se indicarán los métodos que se emplearán para asegurar que los desarrolladores cumplan con los requisitos de esta norma.

Sección de retención, Colección y mantenimiento de Documentos – En esta sección identifica la documentación SQA que deben conservarse. Afirma los métodos y facilidades para montar, proteger y mantener este documentación, y designar el período de retención. La puesta en práctica del plan de SQA implica las aprobaciones necesarias para el plan, así como el desarrollo de un plan para su ejecución. La posterior evaluación del plan de SQA se llevará a cabo como resultado de su ejecución.• Sección de Metodología de pruebas – En esta sección se define el enfoque de prueba, técnicas y herramientas automatizadas que se utilizarán.

Paso 2. Obtener la aceptación de la Gerencia

La participación de la gerencia es necesaria para la implementación exitosa de un plan de SQA. La administración es responsable tanto para garantizar la calidad de un proyecto de software como de proporcionar los recursos necesarios para el desarrollo del mismo.

El nivel de compromiso de la gerencia necesarias para la aplicación de un plan de SQA depende del alcance del proyecto. Si un proyecto abarca las fronteras de la organización, la aprobación se debe obtener de todas las zonas afectadas. Una vez se obtenga la aprobación, el plan de SQA se coloca debajo del control de configuración.

En el proceso de aprobación de la gerencia, la gerencia renuncia a la administración y control del plan para la mejora de la calidad del software (SQA), el control del plan de aseguramiento de la calidad del software a menudo se deja al equipo de desarrolladores. La calidad es deseable , pero la gerencia puede expresar preocupación por los costos de un plan formal de SQA. El personal debe ser consciente de que la gerencia ve el programa como un medio de garantizar la calidad del software, y no como un fin en sí mismo.

Para hacer frente a problemas la gerencia debe tener un estimado oficial de los costos del ciclo de vida de desarrollo de los proyectos ejecutados con o sin plan de calidad. En general, la aplicación de un plan formal de SQA hace económica y da sentido a la gestión.

Paso 3. Obtener un desarrollo aceptable

Debido a que el personal de desarrollo de software y mantenimiento son los principales usuarios de un plan de SQA, su aprobación y su cooperación en la aplicación del plan es esencial. Los miembros del equipo del proyecto de software deben cumplir el plan de SQA, todo el mundo debe aceptarlo y seguirlo.

No hay un plan de SQA que se aplique con éxito sin la participación de los miembros del equipo de software y sus directivos en el desarrollo dl plan. Debido a que los equipos de proyecto en general, tienen sólo unos pocos miembros, todos los miembros del equipo deberían participar activamente en la redacción del plan SQA. Cuando los proyectos son muy largos (es decir, que abarca las divisiones enteras o departamentos), los representantes de los subgrupos del proyecto deben proporcionar información.la retroalimentación constante de los representantes de los miembros del equipo ayuda al plan a ganar aceptación.

Paso 4. Plan de implementación del plan de SQA

El proceso de planificación, formulación y elaboración de un plan de SQA requiere personal y los recursos de procesamiento de textos. La persona responsable de la aplicación de un plan de SQA debe tener acceso a estos recursos. Además, la asignación de recursos requiere la aprobación de la gerencia y, en consecuencia, su apoyo. Para facilitar la asignación de recursos, la gerencia debe ser consciente de los riesgos del proyecto que pueda impedir el proceso de aplicación (por ejemplo, la limitada disponibilidad de personal o de equipo). Un calendario para la redacción, revisión y aprobación del plan de SQA debe ser desarrollado.

Paso 5. Ejecutar el Plan de SQA

El proceso real de la ejecución de un plan de SQA por el equipo de desarrollo y mantenimiento de software consiste en determinar los puntos necesarios para el control de auditoría de éste. La función de auditoría debe ser programada durante la fase de ejecución del producto de software para que el control inadecuado del proyecto de software no afecte el plan de SQA. Los Puntos de Auditoría debe ocurrir ya sea de manera periódica durante el desarrollo o en momentos específicos del proyecto (Por ejemplo, en las revisiones importantes o cuando una parte del proyecto se entrega).

Normas de Calidad

La siguiente sección describe los estándares de calidad líder en TI.ISO9000

Designa un conjunto de normas sobre calidad y gestión continua de calidad, establecidas en el 1987 por la Organización Internacional para la Estandarización (ISO).

Para verificar que se cumplen los requisitos de la norma, existen unas entidades de certificación que auditan la implantación y mantenimiento, emitiendo un certificado de conformidad. Estas entidades están vigiladas por organismos nacionales que regulan su actividad.

Todas las normas ISO9000 son guías rigurosas para el control de la calidad. La certificación ISO se está convirtiendo en la norma más importante en toda Europa y los Estados Unidos para la fabricación de productos. Los proveedores de software estarán cada vez más obligados a tener certificación ISO. ISO9000 no es un conjunto definitivo de normas de calidad, sino que representa lo normas de calidad como parte de un programa de gestión de calidad total (TQM). En esto consiste la norma ISO9001, ISO9002 o ISO9003, y proporciona las directrices para la selección y aplicación de una norma de garantía (aseguramiento) de calidad.

ISO9001 es una norma muy completa y define todos los elementos de calidad necesarias para demostrar la capacidad del proveedor para diseñar y entregar

Exhibit 1.3. Companion ISO Standards

Un producto de calidad. ISO9002 abarca consideraciones de calidad para el proveedor para controlar las actividades de diseño y desarrollo. ISO9003 demuestra la capacidad del proveedor para detectar y controlar la no conformidad del producto durante la inspección y las pruebas. ISO9004 describe los estándares de calidad asociados con ISO9001, ISO9002 e ISO9003 y proporcionan un listado de verificación integral de calidad.Modelo de Madurez de Capacidad (CMM)

El Modelo de Madurez de Capacidades o CMM (Capability Maturity Model),El Instituto de Ingeniería de Software-Capability Maturity Model (SEI-CMM).Es un modelo para juzgar la madurez de los procesos de software de una organización y para identificar las prácticas clave que son necesarios para aumentar la madurez de estos procesos. Como las organizaciones desean mejorar sus capacidades de procesos de software, para que progresen a través de los distintos niveles de madurez.

El logro de cada nivel de madurez representa un componente diferente en el proceso del software, dando como resultado un aumento general en la capacidad de proceso de la organización. El Modelo de Madurez de Capacidad de Software describe los principios y prácticas que subyacen a la madurez del proceso software y tiene por objeto ayudar a las organizaciones de software mejorar la madurez de sus procesos en términos de un camino evolutivo de procesos caóticos a uno de madurez especial, disciplinando los procesos del software.

El CMM está organizado en cinco niveles de madurez :

1. Inicial. El proceso de software se caracteriza por ser ad hoc, y ocasionalmente caótico. Pocos procesos están definidos, y el éxito depende del esfuerzo individual y heroico de un gerente.

Este es el nivel en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, te tienes que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco, no sabes lo que pasa en él.

2. Repetible. Los procesos básicos de gestión de proyectos se han establecido a base del costo , la programación y funcionalidad. La disciplina de proceso necesaria está en el lugar para repetir éxitos en proyectos anteriores con similares aplicaciones.

Quiere decir que el éxito de los resultados obtenidos se puede repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento.Los procesos que hay que implantar para alcanzar este nivel son:

• Gestión de requisitos

• Planificación de proyectos

• Seguimiento y control de proyectos

• Gestión de proveedores

• Aseguramiento de la calidad

• Gestión de la configuración

3. Definido. El proceso de software para la administración y las actividades de ingeniería están documentadas, estandarizado e integrado en un estándar de procesos de software para la organización. Todos los proyectos de uso de una aprobada, la versión adaptada del software estándar de la organizaciónproceso de desarrollo y mantenimiento de software

este nivel significa que la forma de desarrollar proyectos (gestión e ingeniería) esta definida, por definida quiere decir que está establecida, documentada y que existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos.

Los procesos que hay que implantar para alcanzar este nivel son:

• Desarrollo de requisitos

• Solución Técnica

• Integración del producto

• Verificación

• Validación

• Desarrollo y mejora de los procesos de la organización

• Definición de los procesos de la organización

• Planificación de la formación

• Gestión de riesgos

Análisis y resolución de toma de decisiones

4. Gestionado. Las medidas detalladas del proceso del software y de productos de calidad son recolectadas. ambos Tanto el proceso de software y productos son entendidos cuantitativamente y controlados.

Los procesos que hay que implantar para alcanzar este nivel son:

Gestión cuantitativa de proyectos

Mejora de los procesos de la organización

5. Optimización. La mejora continua del proceso está activado por cuantitativos retroalimentación del proceso y de pilotaje, ideas innovadorasy las tecnologías.

Los procesos que hay que implantar para alcanzar este nivel son:

Innovación organizacional

Análisis y resolución de las causas

Nivel 1 – Inicial. La organización generalmente , no proporciona un medio ambiente estable para el desarrollo y mantenimiento de software. Este período es caótico sin ningún tipo de procedimientos y procesos establecido para el desarrollo de pruebas software . Cuando una organización carece de buenas prácticas de gestión, la planificación eficaz y los sistemas de reacción-impulsado por el compromiso socavan los beneficios de las buenas prácticas de ingeniería de software.En esta fase, los proyectos suelen abandonar los procedimientos previstos y volver a la codificación y pruebas. El éxito depende totalmente de quien tiene una excepcional gerencia de proyecto y un equipo eficaz de software. Los resultados de los proyectos dependen de los gestores de proyectos capaces y fuertes. Pero cuando ellos salen de la gerencia de proyecto su influencia estabilizadora se va con ellos. Incluso una ingeniería de procesos fuerte no puede superar la inestabilidad creada por la ausencia de buenas prácticas de gestión.Nivel 2 – repetible. Durante esta fase las medidas y métricas se revisan para incluirlas en un porciento de procesos inlocalizados, entregas reasignadas , el número de cambios en los requerimientos, serie de cambios en los planes del proyecto, la variación entre los tamaños reales y los estimados de las prestaciones, y la variación real entre las auditorías realizadas y PQA número previsto de solicitudes de cambio y procesados en un período de tiempo.Las siguientes son las actividades clave del proceso en el nivel 2:• Software de gestión de la configuración• Software de control de calidad• Software de gestión de subcontratación• El software de seguimiento y supervisión de proyectos• Software de planificación de proyectos• Requisitos de gestiónNivel 3 – Definido. Durante esta fase de las medidas y métricas serevisado para incluir el porcentaje del tiempo total del proyecto dedicado a las actividades de prueba, eficiencia de las pruebas, la tasa de inspección de las prestaciones, la eficiencia de inspección, varianza entre la asistencia real y la asistencia prevista para programas de capacitación, y la variación entre la dirección real y la prevista esfuerzo. El nivel 3 significa el cumplimiento de los procesos de una organización para la gestión y las actividades de ingeniería han sido formalmente definidos, documentados, e integrado en un proceso estándar que se entiende y seguido por personal de la organización en el desarrollo y mantenimiento de software. Una vez una organización que ha alcanzado este nivel, tiene una base para continuar progreso. Los nuevos procesos y herramientas se pueden agregar con una interrupción mínimay los nuevos miembros del personal pueden ser entrenados fácilmente para adaptarse a la organización de prácticas. Las siguientes son las áreas de proceso clave para el nivel 3:• Revisiones por homólogos• Intergrupal de coordinación• Software de ingeniería de producto• Gestión integrada de software• Programa de capacitación• Organización de la definición del proceso• Organización enfoque procesoLa capacidad de proceso de software de nivel 3 las organizaciones pueden resumirse como estándar y consistente, porque tanto el software de ingeniería y las actividades de gestión son estables y repetibles. Dentro de los productos establecidos líneas, horarios, costo y funcionalidad están bajo control, y el software la calidad se hace un seguimiento. Esta capacidad del proceso se basa en la de toda la organización común comprensión de las actividades, funciones y responsabilidades en un define el proceso de software.Nivel 4 – Gestionado. Esta fase indica que los procesos están biendefinidos y gestionados profesionalmente. Las normas de calidad se encuentran en una fase de expansión. Con una calidad de sonido los procesos en marcha, la organización es mejor equipadas para satisfacer las expectativas de los clientes de high-quality/high-performancesoftware a un costo razonable y de las entregas comprometidas. Entrega de la coherencia en productos de trabajo de software y la coherencia en todo el software el desarrollo del ciclo de vida, incluyendo planes, procesos, requerimientos, diseño código, y la prueba ayuda a crear clientes satisfechos. Proyectos de lograr un control sobre sus productos y procesos mediante la reducción de la variación en sus rendimiento de los procesos a caer dentro de límites aceptables cuantitativos.Variaciones significativas en el rendimiento del proceso se pueden distinguir devariaciones aleatorias (ruido), en particular en las líneas de productos establecidos.Los riesgos involucrados en el movimiento hasta la curva de aprendizaje de una nueva aplicacióndominio son conocidos y administrados con cuidado:• Software de gestión de calidad• cuantitativos de gestión de procesosLa capacidad de proceso de software de nivel 4 las organizaciones pueden resumirse tan predecible porque el proceso es medido y opera dentro delímites mensurables. El nivel de capacidad de proceso permite a una organización predecir las tendencias en el proceso y la calidad del producto dentro de los cuantitativos límites de estos límites. Cuando se sobrepasan estos límites, se toman medidas para corregir la situación. Los productos de software son de una calidad previsible de alta.Nivel 5 – Optimizado. Un continuo énfasis en la mejora de procesosy la reducción de defectos evita el estancamiento del proceso o la degeneración y asegura la mejora continua, que se traduce en una mayor productividad, fugas defecto reducida, y una mayor puntualidad. Rastreo de requisitos a través de cada fase de desarrollo mejora la integridad del software,reduce la repetición del trabajo, y simplifica el mantenimiento. Verificación y validación las actividades se planifican y ejecutan para reducir las fugas defecto. Clientestener acceso al plan del proyecto, recibir los informes de situación periódicos, y sus comentarios se solicitan y se utiliza para el ajuste de proceso. El Ejército Popular de Corea en el nivel 5 son:• Proceso de gestión del cambio• La tecnología de gestión del cambio• La prevención de defectoslos equipos de proyecto de software en el nivel 5 las organizaciones a analizar para determinar los defectos sus causas. Procesos de software son evaluados para evitar que se conoce tipos de defectos se repitan, y las lecciones aprendidas son difundidas a otros proyectos. La capacidad de proceso de software de nivel 5 organizaciones puede ser caracterizada como la mejora continua, porque el nivel 5 organizaciones está continuamente tratando de mejorar el alcance de su capacidad de proceso, mejorando así el rendimiento de los procesos de sus proyectos.Mejora se produce tanto por los avances incrementales en el vigente proceso y por las innovaciones con las nuevas tecnologías y métodos.

PCMMLa gente Capability Maturity Model (People CMM) es un marco que ayuda a las organizaciones con éxito frente a sus problemas de la gente crítica.Sobre la base de las mejores prácticas actuales en campos como los recursos humanos, gestión del conocimiento, y desarrollo organizacional, el Pueblo guías CMM organizaciones en la mejora de sus procesos de gestión y el desarrollo de sus fuerzas de trabajo. El People CMM ayuda a las organizaciones caracterizan la madurez de las prácticas de su fuerza de trabajo, establecer un programa de desarrollo de la fuerza continua, establecer prioridades de mejora acciones, integrar el desarrollo con mano de obra de mejora de procesos, y establecer una cultura de excelencia. Desde su lanzamiento en 1995, miles de copias del People CMM se han distribuido, y se utiliza en todo el mundo por las organizaciones de pequeños y grandes.El People CMM consta de cinco niveles de madurez que establecen sucesivas bases para la mejora continua de las competencias individuales, el desarrollo de equipos eficaces, motivar un mejor desempeño, y la configuración de la mano de obra la organización necesita para cumplir sus planes de negocio futuro. Cada nivel de madurez es una meseta evolutiva bien definida que institucionaliza la nueva capacidades para el desarrollo de fuerza de trabajo de la organización. Siguiendo las marco de madurez, una organización puede evitar la introducción de prácticas de mano de obra que sus empleados no están preparados para implementar de manera efectiva.

CMMILa suite de productos CMMI proporciona las últimas mejores prácticas para el desarrollo y mantenimiento de productos y servicios . Los modelos CMMI están como el mejor modelo de procesos disponibles para el desarrollo de modelos de desarrollo y mantenimiento de productos y servicios. Estos modelos se extienden a las mejores prácticas del modelo de capacidad de madurez del software (SW-CMM ®), el modelo de capacidad de ingeniería de sistema (SECM), y el modelo de capacidad de madurez integrada de los productos (IPD-CMM).

las organizaciones informaron de que CMMI es adecuado para orientar su proceso de actividades de mejora y que los cursos de formación y evaluación CMMI son métodos adecuados para sus necesidades, aunque hay oportunidades específicas para la mejora. El costo de CMMI es un tema que ha afectado la adopción decisiones para algunos, pero no para otros. Por último, la información del retorno de la inversión suele ser útil a las organizaciones a la hora de tomarla decisión de la adopción del modelo CMMI.

Malcolm Baldrige, Premio Nacional de Calidad

El Premio Nacional de Calidad Malcolm Baldrige se crea en Estados Unidos en 1987, momento en el que la invasión de productos japoneses en el mercado estadounidense precisa de una respuesta por parte de las organizaciones de este país. En la creencia de que la Gestión de Calidad Total es necesaria para que las organizaciones puedan competir en el mercado internacional, surge el proyecto del Premio Nacional de la Calidad Americana

La misión de este premio es:

• Sensibilizar al país y a las industrias, promocionando la utilización de la Gestión de la Calidad Total como método competitivo de gestión empresarial.

• Disponer de un medio de reconocer formal y públicamente los méritos de aquellas firmas que los hubieran implantado con éxito

El premio lleva el nombre de Malcolm Baldrige, que se desempeñó como Secretario de Comercio desde 1981 hasta su trágica muerte en un accidente de rodeo en 1987.

El Premio Baldrige es una propuesta por el Presidente de los Estados Unidos aempresas – de fabricación y de servicios, pequeños y grandes – y parala educación y la salud de las organizaciones de atención que se aplican y se consideran se destacables en siete áreas: liderazgo, planificación estratégica, los clientes y el enfoque de mercado, información y análisis, enfoque de los recursos humanos, gestión de procesos, y los resultados empresariales. . . . Mientras que el Baldrige Premio Baldrige y los destinatarios son la pieza central muy visible del movimiento de calidad de EE.UU., un programa más amplio de calidad nacional desarrollado en torno a la concesión y sus criterios. En un informe, A partir de Baldrige:

Los siete criterios en los que se basa el modelo son:

1.- Liderazgo 2.- Planificación estratégica 3.- Enfoque al cliente y al mercado 4.- Información y análisis 5.- Desarrollo y gestión de Recursos Humanos 6.- Estandarización 7.- Resultados de negocio

Siete categorías constituyen los criterios de adjudicación:

1. Liderazgo – Examina cómo los altos ejecutivos orientan a la organización y cómo la organización aborda sus responsabilidades en las prácticas del sector público y la buena ciudadanía. Las evaluaciones se basan en la pertinencia, eficacia y alcance del líder y la empresa de participación en relación con el tamaño y tipo de negocio.

2. Medición, análisis y gestión del conocimiento – Examina la gestión, y su uso efectivo, análisis y mejora de los datos y la información para apoyar los procesos clave de organización y de la organización el rendimiento del sistema de gestión. El ámbito de aplicación, gestión, y análisis de datos dependen del tipo de negocio, sus recursos, y la distribución geográfica.

3. La planificación estratégica – Examina cómo la organización establece estratégica direcciones y la forma en que determina los principales planes de acción. Las evaluaciones son basadas en el rigor y la eficacia de los procesos.

4. Centrado en los recursos humanos – Examina cómo la organización permite a sus mano de obra para desarrollar todo su potencial y cómo la fuerza de trabajo es alineados con los objetivos de la organización. La evaluación depende del enfoque de recursos humanos de la empresa.5. Proceso de gestión – Examina aspectos de la producción como clave / los procesos de entrega y el apoyo están diseñados, gestionados y mejorado. Los tipos de productos y servicios, el cliente y el gobiernorequisitos, los requisitos reglamentarios, y el número de ubicaciones de la empresa son los factores que influyen en esto.6. Los resultados del negocio – Examina el desempeño de la organización y mejora en sus áreas de negocio clave: satisfacción del cliente, financiera y el rendimiento de mercado, recursos humanos, proveedores yrendimiento de los socios, el rendimiento operativo, y la gobernanza y responsabilidad social. La categoría también examina cómo la organización lleva a cabo en relación con los competidores.7. Centrado en el Cliente y el mercado – Examina cómo la organización determina sus requisitos y expectativas de los clientes y los mercados;construye relaciones con los clientes, y adquiere, cumple, y conserva los clientes.El sistema de examen para los elementos de puntuación se basa en la evaluación de estos dimensiones:

1. Enfoque: el enfoque indica el método que utiliza la empresa para lograr los objetivos. El grado en que el enfoque esta basado en la prevención- basado en la eficacia y uso idóneo de las herramientas, técnicas y métodos, por lo tanto si el enfoque es sistemático, integrado puede aplicarse de manera coherente y eficaz para auto-evaluación y la retroalimentación, la información cuantitativa recopilada, y la singularidad y capacidad de innovación de este enfoque son los factores que deciden si el enfoque correcto.

2. Implementación: Se trata de las áreas donde el enfoque es desplegado. Se evalúa si el enfoque se aplica en todos los productos y servicios y todos los procesos internos, actividades, instalaciones, y empleados.

3. Resultados: Se refiere a los resultados de este enfoque. La calidad niveles demostrado, la tasa de mejora de la calidad, amplitud, importancia, y la comparación de la mejora de la calidad y el alcance de la mejora de la calidad a la que se demuestra son los factores clave a esto. En comparación con otros programas como la ISO, el premio Deming de Japón y Premio Baldrige de los Estados Unidos:

• Centrarse más en los resultados y el servicio• Confíe en la participación de diversos profesionales y el trabajo en equipo• Proporcionar créditos especiales para los enfoques innovadores para la calidad• Incluir a un cliente fuerte y el enfoque de recursos humanos• Hacer hincapié en la importancia de compartir información

Notas1. http://www.sei.cmu.edu/cmmi/adoption/cmmi-start.html.2. http://www.nist.gov/public_affairs/factsheet/baldfaqs.htm.

Se consulto de forma particular el libro: Software Testing and Continuous Quality Improvement

Autor:

Rafael González Freites (pepelo)

Azua, Republica Dominicana