MODELOS DE PROCESO
Un modelo de procesos de software es una simplificación o abstracción de un proceso real.
Podemos definir un modelo de proceso del software como una representación abstracta de alto nivel de un proceso software. Cada modelo es una descripción de un proceso software que se presenta desde una perspectiva particular.
Cada modelo describe una sucesión de fases y un encadenamiento entre ellas.
Un modelo es más adecuado que otro para desarrollar un proyecto dependiendo de un conjunto de características de éste.
Un proceso del software es un conjunto de actividades que conducen a la creación de un producto software.

MODELO CASCADA
Este modelo considera a cada actividad del proceso como una fase autónoma que produce una salida o documento aprobado. La siguiente fase comienza cuando se ha finalizado con la anterior. Las fases se suceden en orden estrictamente secuencial.

Ventajas: * Fácil de administrar. permite detectar fácilmente el avance en el desarrollo, debido a que cada actividad produce un artefacto * En cada fase están bien definidas las salidas a producir para avanzar a la siguiente etapa. * El proceso de desarrollo es claro de entender por los clientes. * La separación de análisis, diseño e implementación conduce a sistemas robustos

Desventajas: * Modelo inflexible: presenta dificultades para hacer cambios entre etapas. * Este modelo tiene una visión estática de la ingeniería de requisitos, ignora la volatilidad natural de los requisitos y cómo repercute ésta en las etapas del desarrollo. * El congelamiento prematuro de los requisitos puede implicar que el sistema no haga lo que los usuarios desean. * Los clientes y usuarios no participan en etapas posteriores a la especificación de requisitos sino hasta la prueba de aceptación. * Este modelo no trata al proceso de software como un proceso de resolución de problemas * Errores y omisiones en los requisitos originales se descubren recién en las fases finales del ciclo.

MODELO EN ESPIRAL
Este modelo resulta de un refinamiento exhaustivo del modelo en cascada al que se le agregó el desarrollo incremental.
Cada ciclo del espiral comienza con la identificación de objetivos de la porción de producto que se va a elaborar
Cada espira produce un producto software que puede ser una versión del software o un componente del mismo puede darse que se realicen diferentes espirales en paralelo para desarrollar diferentes componentes o incrementos.
Es un modelo dirigido a los riesgos, Este análisis de riesgos implica detectarlos, evaluarlos y prever caminos alternativos si es necesario.

Ventajas: * Incorpora muchas de las ventajas de los otros ciclos de vida * Conjuga la naturaleza iterativa de los prototipos con los aspectos controlados y sistemáticos del modelo clásico * El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. * Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos. * El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. * El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas. * Proporciona el potencial para el desarrollo rápido de versiones incrementales * Permite aplicar el enfoque de construcción de prototipos en cualquier momento para reducir riesgos

Desventajas: * Solo resulta aplicable para proyectos de gran tamaño * Supone una carga de trabajo adicional, no presente en otros ciclos de vida * Requiere una considerable habilidad para la evaluación y resolución del riesgo, y se basa en esta habilidad para el éxito * Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas * Es bastante complicado de realizar y su complejidad puede incrementarse hasta hacerlo impracticable * El modelo no se ha utilizado tanto como otros, por lo que tendrán que pasar años

Estrategia de PROTOTIPADO
La estrategia de Prototipado consiste en construir un mecanismo para generar software que sea evaluado por el cliente en conjunto con el programador.
Esta estrategia debe ser considerado como un procedimiento dentro de la construcción del software.
Existen tres enfoques para utilizar prototipos: el prototipo exploratorio, el prototipo experimental y el prototipo evolutivo.
El prototipo exploratorio se utiliza en etapas muy tempranas del desarrollo con el objetivo de clarificar o elicitar requisitos del software.
El prototipo experimental sirve para simular aspectos o partes de un sistema de software para evaluar aspectos técnicos desconocidos.
Existen dos tipos de Prototipo Evolutivo:
1) Desarrollo incremental (“slowly growing systems”). El sistema evoluciona gradualmente en incrementos parciales. No hay cambios en el diseño.
Las necesidades del usuario son conocidas al principio y se realiza un diseño completo que se realiza en incrementos con un prototipo.
2) Desarrollo evolutivo. Mira al desarrollo como una secuencia de ciclos: rediseño, re-implementación, re-evaluación. Producción del software en un ambiente dinámico y de cambios. El sistema evoluciona de manera continua.

MODELO DE TRANSFORMACIÓN
Aplica una serie de transformaciones usando un soporte automatizado para convertir una especificación formal (modelo matemático) en un sistema implementable (ejecutable). Es decir, este paradigma intenta automatizar las etapas de diseño e implementación usando el concepto de transformación.
La especificación de requisitos se refina en una especificación formal detallada, expresada en notación matemática. Los procesos de diseño, implementación y prueba de unidades se reemplaza por un proceso de transformaciones donde la especificación formal se refina hasta llegar a un software.

Ventajas: * La especificación formal representa los requisitos del sistema en una forma precisa y no ambigua. * Reduce la posibilidad de error por la eliminación de varios pasos de Desarrollo * Buena visibilidad: en cada transformación se genera un registro o documento. * Reduce el esfuerzo de mantenimiento, * Reduce o elimina el esfuerzo de verificación de la especificación formal.

Desventajas: * Se requiere mucho tiempo y esfuerzo para construir una especificación formal con precisión. Requiere tecnología específica y personal altamente especializada. * Dificultad de validación * Es difícil la automatización del proceso de transformación.
ENFOQUE INCREMENTAL
La propuesta del enfoque es diseñar sistemas que puedan entregarse por piezas. * A partir de la evaluación se planea el siguiente incremento y así sucesivamente * Es interactivo por naturaleza * Es útil cuando el personal no es suficiente * con cada incremento que entrega parte de la funcionalidad requerida * Los requerimientos del usuario se priorizan * Los usuarios no tiene que esperar. * Pueden aumentar el coste debido a las pruebas. * siempre incrementando subconjuntos de requerimientos del sistema. * conjunto completo de requerimientos es conocido al comenzar * Se evitan proyectos largos * El usuario se involucra más * Riesgos largos y complejos. * Difícil de aplicar a sistemas transaccionales * Requiere gestores experimentados * Los errores en los requisitos se detectan tarde.
Beneficios:
* Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande. * fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos. * Si un error importante es realizado, sólo la última iteración necesita ser descartada. * decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo. * El resultado puede ser muy positivo
BASADO EN REUTILIZACION
El Modelo basado en Reutilización se centra en integrar un gran número de componentes de software existentes para construir un sistema, más que en desarrollarlos desde cero. El proceso de ingeniería de requisitos involucra una primera fase de definición de requisitos, seguida de un análisis de componentes existentes que cubran los requisitos especificados y posteriormente una fase de modificación de requisitos en función de los componentes disponibles.

ORIENTADO A ASPECTOS
Este mecanismo se enfoca principalmente en la separación de intereses de un sistema para obtener una mejor modularización.
El desarrollo de software orientado a aspectos (DSOA) se enfoca en crear una mejor abstracción modular del sistema. Incluye las siguientes fases:
- Captura de requisitos
- Análisis
- Diseño
- Implementación
- Pruebas
La primera fase trata la separación de intereses tanto los funcionales como los no funcionales; los requisitos funcionales son modelados con casos de uso y los requisitos no funcionales se representan con casos de uso de infraestructura.

DESARROLLO ÁGIL
Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto.

XP (XTREME PROGRAMING)

Las características fundamentales del método XP son: * Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras. * Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. * Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. * Frecuente integración del equipo de programación con el cliente o usuario * Corrección de todos los errores antes de añadir nueva funcionalidad. * Hacer entregas frecuentes. * Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. * Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. * Simplicidad en el código
SCRUM
Lista de requisitos priorizada
El cliente crea y gestiona la lista de requisitos del producto o proyecto

Demostración de los resultados de proyecto en cada iteración
Al final de cada iteración el equipo demuestra al cliente los requisitos que ha conseguido completar. el cliente solicita los cambios que necesita y replanifica el proyecto.

Priorización de requisitos por valor y coste
Al inicio de cada iteración el cliente prioriza la lista de requisitos del producto o proyecto en función del valor que le aportan
Replanificación en el inicio de cada iteración
Se asume que los cambios son parte natural del proyecto. El hecho los requisitos se completen en función del valor que aportan al cliente minimiza la probabilidad de que se produzcan grandes cambios en el transcurso del proyecto.

Priorización de requisitos por valor
Cada iteración el cliente dispone de unos requisitos completados y replanifica el proyecto en función del valor que le aportan los requisitos pendientes respecto del coste de desarrollo que tienen.

Desarrollo iterativo e incremental
Un requisito se debe completar en una iteración. De esta manera no se deja para el final del proyecto ninguna actividad arriesgada relacionada con la entrega de requisitos.
Mejora continua
Cada iteración el equipo realiza una retrospectiva para analizar su manera de trabajar e identificar los obstáculos que le impiden avanzar al mejor ritmo posible.

Comunicación diaria del equipo
Todo miembro del equipo conoce cómo el trabajo de los otros miembros impacta en el suyo y cuáles son las necesidades de los otros.

TimeBoxing
Cada actividad de Scrum siempre tiene la misma duración , con lo que las personas aprenden lo que pueden conseguir en este tiempo

Equipo multidisciplinar
El equipo está formado por todas las personas con las especialidades necesarias para llevar a cabo el proyecto.

Estimación de esfuerzo conjunta
En el inicio de la iteración los miembros del equipo estiman de manera conjunta el esfuerzo necesario para completar requisitos y sus tareas.

Compromiso del equipo
En el inicio de cada iteración el equipo selecciona los requisitos que se compromete a completar y entregar al final de la iteración.

Demostración de resultados preparados para ser utilizados y velocidad sostenida
Al final de cada iteración el equipo demuestra al cliente los requisitos que ha conseguido completar
Cliente y equipo trabajando “en equipo”
Cada iteración el equipo y el cliente trabajan juntos en la creación de los requisitos del proyecto

Equipo autogestionado
Es el equipo quien se autoorganiza y quien planifica cómo trabajará en la iteración.

Demostración
Cada iteración el equipo muestra al cliente los resultados que consigue

PROCESO UNIFICADO
El proceso unificado conocido como RUP, es un modelo de software que permite el desarrollo de software a gran escala, mediante un proceso continuo de pruebas y retroalimentación, garantizando el cumplimiento de ciertos estándares de calidad.
El proceso de desarrollo constituye un marco metodológico que define en términos de metas estratégicas, objetivos, actividades y artefactos (documentación) requerido en cada fase de desarrollo

CONCLUSIONES
El problema crucial que atraviesan los métodos de la Ingeniería de Software es tratar con requisitos siempre cambiantes. La evolución de los errores y la evolución de los requisitos son dos características del desarrollo de software estrechamente vinculadas.
Los modelos desarrollados con posterioridad al modelo convencional han mejorado de distintas formas los inconvenientes presentados por el modelo de cascada, cuyas consecuencias se manifestaron en los fracasos paradigmáticos de la crisis del software y posteriores. Pero además, se desprende que la evolución de los requisitos es prácticamente ignorada durante el desarrollo del software por cualquiera de los modelos. Es por ello que nuevos enfoques deben producir versiones de sistemas de software que atiendan la totalidad de las necesidades a un momento dado y que sean altamente flexibles para satisfacer rápidamente los próximos nuevos requisitos.
Los modelos de prototipado, operacional y transformación formal surgieron como solución al problema planteado por el modelo de cascada referido a la poca participación del usuario en el desarrollo. Por lo tanto, los tres modelos proponen la creación de un artefacto (prototipo, especificación operacional, especificación formal) tempranamente en el ciclo de vida, que pueda ser usado para comprender y validar los requisitos.
Cabe destacar por otro lado que los modelos que más soportan la evolución de los requisitos son aquellos que presentan procesos iterativos, como el modelo evolutivo, el incremental y el espiral.
Estos métodos ágiles, basados en prácticas IID, sí tienen en cuenta la evolución de los requisitos, ya que en ellos todo evoluciona, pero no presentan un proceso dedicado a la definición de requisitos sino que éste es más bien informal.

Gestión de Configuración de SW * Cuando se construye software de computadora, los cambios son inevitables. * Los cambios aumentan el grado de confusión * La confusión surge cuando: * no se han analizado los cambios antes de realizarlos * no se han registrado antes de implementarlos, * no se les han comunicado a aquellas personas que necesitan saberlo * no se han controlado de manera que mejoren la calidad y reduzcan los errores.

Los cambios
Los cambios se producen por: * Nuevos requerimientos del negocio * Nuevas necesidades del usuario * Reorganización comercial * Restricciones de presupuestos o planificaciones
Gestión de Configuración de Software - Definición
“La gestión de configuración es una actividad de auto protección que se aplica a lo largo del proceso de la Ingeniería de Software y que tiene como objetivo identificar, organizar y controlar las modificaciones que sufre el software que construye un equipo.”

Los cambios
La GCS es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida del software.
La GCS es una actividad de garantía de calidad que se aplica en todas las fases del proceso de la ingeniería del software.

Actividades de la GCS
1. Identificar el cambio
2. Controlar el cambio
3. Garantizar que el cambio se implementa adecuadamente
4. Informar del cambio a los interesados.

Elementos de Configuración * La Ingeniería del software produce: * Programas * Datos * Documentos
Todos ellos se transforman en elementos de configuración del software.

Objetos de configuración * Los ECSs se organizan como objetos de configuración que han de ser catalogados en la base de datos del proyecto con un nombre único. * Un objeto de configuración tiene un nombre y unos atributos y está «conectado» a otros objetos mediante relaciones.

Línea Base * Una línea de base es una especificación o producto que se ha revisado formalmente, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios. * La Línea de base es un punto de referencia en el desarrollo del software que queda marcado con la aprobación de uno o más elementos de configuración del SW.

El proceso de la GCS
1. Identificación los elementos de configuración
2. Control de versiones
3. Control de cambios
4. Auditorías de Configuración:
1. Revisiones formales
2. Auditorías de configuración
5. Generación de informes
1.- Identificación los elementos de configuración
1. Identificar y organizar los objetos como básicos y compuestos
2. Identificar al objeto con un nombre que lo identifique unívocamente.
3. Identificar las relaciones entre los objetos.
4. Documentarlos con gráficos o notaciones.

2.- Control de versiones
1. Combina procedimientos y herramientas para gestionar las versiones de los objetos de configuración creados durante el proceso de ingeniería de software.
2. Cada versión del software es un colección de ECS y cada versión puede estar compuesta de diferentes variantes.
3. A cada componente se le asigna una tupla de atributos,

3.- El proceso del Control de cambios * Combina procedimientos humanos y herramientas. * Elementos del control de cambios: * Petición del cambio * Autoridad de control de cambios (ACC) * Orden de Ingeniería de cambios (OCI) * Procesos de alta y baja de objetos (control de acceso y sincronización) * Nivel del cambio: informal (antes de la línea de base), a nivel del proyecto (cambio local) o formal (cuando el software está en los clientes).

4.- Auditorías de Configuración
1. Revisiones técnicas formales: se centra en la corrección técnica del ECS que ha sido modificado
2. Auditorías de configuración: es llevada a cabo por el grupo de garantía de calidad y tiene como objetivo asegurar que se ha hecho, revisado, implementado y comunicado correctamente el cambio, de acuerdo a los estándares.

5.- Generación de informes de estado de configuración (IEC)
Es una actividad que documenta (contabiliza): * ¿Qué pasó? * ¿Quién lo hizo? * ¿Cuándo pasó? * ¿Qué más se vio afectado?
En cada paso del proceso formal del control de cambios.
Su objetivo es el de mejorar la comunicación entre todas las personas involucradas en el proyecto

GCS para IWeb * Sin controles eficaces cualquier cambio inadecuado en una WebApp puede conducir a: * una ubicación no autorizada de la información del producto nuevo; * una funcionalidad errónea y pobremente comprobada que frustra a los visitantes del sitio Web; * agujeros de seguridad que ponen en peligro a los sistemas internos de las compañías, y otras consecuencias económicamente desagradables e incluso desastrosas. * Contenido. Una WebApp normal contiene una gran cantidad de contenido * El reto es organizar este mar de contenido en un conjunto razonable de objetos de configuración y entonces establecer los mecanismos de control de configuración adecuados para estos objetos. * modelar el contenido de la WebApp mediante la utilización de técnicas convencionales de modelado de datos. * A medida que crece el tamaño y la complejidad, los pequeños cambios pueden tener efectos inalcanzables.

Conclusiones * La gestión de configuración para la IWeb está todavía en su infancia. * Un proceso convencional de GCS puede resultar demasiado pesado y torpe. * La gran mayoría de las herramientas GCS no tienen las características que permiten adaptarse fácilmente a la IWeb. * creación de un proceso de gestión de configuración que sea lo suficientemente hábil * aplicación de mejores conceptos y herramientas de gestión de configuración para aquellos que desarrollan y no están familiarizados con la tecnología; * suministro del soporte a los equipos de desarrollo de WebApps distribuidos; * suministro de control en un entorno de cuasipublicación, donde el contenido cambia de forma casi continua; * consecución de la granularidad necesaria para controlar una gran cantidad de objetos de configuración; * incorporación de la funcionalidad de gestión de configuración en las herramientas IWeb existentes; * gestión de cambios en objetos que contienen enlaces con otros objetos.

SISTEMAS SOCIO-TÉCNICOS
ENFOQUE SOCIO-TÉCNICO
Se puede resumir que un sistema es un conjunto de componentes que interactúan entre sí para lograr un objetivo común define sistema como una combinación de recursos integrados de forma tal que cumplan una función específica en respuesta a una necesidad designada de un usuario.
La comunicación formal es establecida con el objetivo de hacer llegar la información en el momento preciso y a quien realmente corresponde. Estas líneas de comunicación respetan la jerarquía organizacional. La comunicación informal surge espontáneamente de las relaciones entre las personas por la afinidad o necesidades personales. Esta comunicación satisface las necesidades sociales de los integrantes de la organización.

ACEPCIÓN LABORAL Y CULTURAL DE SISTEMAS SOCIOTÉCNICOS
El fordismo promovió la especialización, la transformación del esquema industrial y la reducción de costos.
Aunque se tiende así a la humanización de las tareas, esta concepción de sistema socio-técnico considera a las personas sólo como un ingrediente del proceso productivo, los recursos humanos, cuya función es sólo proveer la energía e información necesarias para obtener un buen producto final.
La acepción cultural de sistema socio-técnico considera de modo integral la interacción entre las personas y los medios que usan para modificar su ambiente, las tecnologías.

SISTEMAS DE SOFTWARE SOCIO-TÉCNICOS
Los sistemas socio-técnicos son aquellos en los que se identifica la reciproca relación hombremáquina u hombre-tecnología contemplando los aspectos sociales en los cuales se desarrolla dicha relación. los sistemas socio-técnicos incluyen uno o más sistemas técnicos pero crucialmente incluyen conocimiento de cómo el sistema deberá ser usado para cumplir algún objetivo más amplio.
Esto significa que estos sistemas tienen definidos procesos operacionales, incluyen personas como partes inherentes del sistema, se rigen por políticas y reglas organizacionales que pueden ser afectadas por restricciones externas como leyes o políticas regulatorias.
Las características * Tienen propiedades emergentes que son propiedades del sistema como un todo más que asociadas con partes individuales del sistema. * A menudo son no determinísticos. Esto significa que no siempre ante una misma entrada se obtiene la misma salida. El comportamiento de los sistemas dependen de la operación de una persona, y la gente no siempre reacciona de la misma manera. * El grado en el cual el sistema es compatible con los objetivos de la organización no sólo depende del propio sistema. Esto también depende de la estabilidad de los objetivos, las relaciones y conflictos entre los objetivos organizacionales y como la gente de la organización interpreta estos objetivos.

USO DEL LENGUAJE NATURAL
El Lenguaje Natural (LN) es un enfoque que facilita la comprensión de cualquier conocimiento.
Para lograr estos objetivos es necesario controlar el principal problema que enfrenta el LN: la ambigüedad. Esta es una desventaja ante la posibilidad de automatizar cualquier proceso que lo utilice.

Clasifica
i) ambigüedad léxica (una palabra con varios significados), ii) ambigüedad sintáctica o ambigüedad estructural (una oración con más de una posible estructura), iii) ambigüedad semántica (una oración con más de una manera de leerse), iv) ambigüedad pragmática (una oración cuyo significando depende del contexto),
v) vaguedad (una oración con falta de detalles) y vi) error idiomático (una oración con errores como la puntuación).

EL ORGANIGRAMA INFORMAL EN LOS PROCESOS DE REQUISITOS
Organigramas han demostrado, en muchos casos, ser muy diferentes a los obtenidos al considerar los aspectos sociales y culturales que juegan un rol importante a la hora de hacer su trabajo o tomar decisiones.
No considerar ciertos aspectos socio-culturales inherentes a la organización y de cada persona en particular, puede afectar a la hora de obtener los requisitos del software desde dos vistas diferentes: * Que se definan procesos del negocio incorrectos o no aplicables * Que falle el propio proceso de requisitos.
En el primer caso existe una gran probabilidad de no detectar problemas o caminos alternativos que están íntimamente asociados con los aspectos informales pero que modifican el conocimiento adquirido.
En el segundo caso, las influencias en la toma de decisiones durante el proceso de requisitos puede ser errónea ya que “la gente tratará de influenciar en el proceso de requisitos para mantener o aumentar su propia influencia política en la organización”

CULTURA ORGANIZACIONAL
La Cultura Corporativa o también denominada Cultura Organizacional, es el conjunto de valores, costumbres, hábitos y creencias existentes en una organización.
Esta cultura puede estar disponible y visible a través de documentos o normativas de la organización y en los comportamientos observables: * Los valores y las creencias * Las normas de comportamiento * Las políticas escritas de la organización * La motivación vertical * Los sistemas y procesos formales e informales * Las redes internas existentes en la organización

Sistemas socio-técnicos según Sommerville
Un sistema es una colección de componentes interrelacionados que trabajan conjuntamente para cumplir algún objetivo.
Los sistemas que incluyen software se dividen en dos categorías: * Sistemas técnicos informáticos. Son sistemas que incluyen componentes HW y SW, pero no procedimientos y procesos. * Sistemas socio técnicos: comprende uno o más sistemas técnicos pero también incluyen conocimiento de cómo debe usarse el sistema para alcanzar algún objetivo más amplio.

Las características del sistema socio-técnico son: * Tiene propiedades emergentes: que son propiedades del sistemas como un todo más que asociadas con partes individuales del sistema. * Son a menudo no deterministas. Esto significa que no siempre producen la misma salida. * El grado en que el sistema apoya los objetivos organizacionales no solo depende del sistema en si mismo
Una característica de los sistemas es que las propiedades y el comportamiento de los componentes del sistema están inseparablemente entremezclados.

Propiedades emergentes de los sistemas:
Las complejas relaciones entre componentes de un sistema indican que el sistema es más que simplemente la suma de sus partes

Existen dos tipos de propiedades emergentes:
1- Las propiedades emergentes funcionales: aparecen cuando todas las partes de un sistema trabajan de forma conjunta para cumplir con algún objetivo.
2- Las propiedades emergentes no funcionales: se refieren al comportamiento de los sistemas en su entorno operativo.

Los sistemas socio-técnicos son sistemas empresariales que tienen la intención de ayudar a conseguir algunos objetivos organizaciones o de negocio. La consecución, desarrollo y uso de estos sistemas están influenciados por las políticas y procedimientos de la organización y por su cultura de trabajo.

Los factores humanos y organizacionales del entorno del sistema que afectan a sus diseños son: * Cambios en el proceso: el sistema modificar los procesos de la organización y del entorno. * Cambios en el trabajo: el sistema modificación de la forma de trabajo de los usuarios * Cambios organizacionales: el sistema cambia la estructura organizativa o el poder de esta.
Estos factores humanos, sociales y organizacionales son a menudo críticos para determinar si un sistema cumple con éxito los objetivos.

COMPETENCIAS CONDUCTUALES competencias conductuales son “comportamientos” que algunas personas dominan mejor que otras y por consecuencia las hacen más eficaces en una situación determinada.

Competencias generales
Las competencias generales son características o habilidades del comportamiento general de la persona o personas dentro de la organización observables en el puesto de trabajo, esta competencia excluye aspectos de dominio de la tecnología o conocimientos específicos (especialización).

Competencias técnicas
Estas competencias implican en correcto desempeño de puestos de un área técnica o de una función específica y estás van ligadas muchas veces con el área de trabajo en la cual nos desempeñemos dentro de la organización,

Habilidades:
Meta-habilidades
Son las habilidades y conocimientos del más alto nivel, son tan básicas que cualquier persona las necesita para operar en forma efectiva en su interacción con otras.

Habilidades Interpersonales
Estás habilidades están relacionadas con el éxito en las tareas que se suponen contacto interpersonal para el correcto desempeño del puesto de trabajo

Habilidades Directivas
Se trata de habilidades que resultan imprescindibles para dirigir a otros dentro de la organización, orientando y acompañando su desempeño en diferentes niveles o grados de supervisión y distintos grados de responsabilidad

Desarrollo de software dirigido por modelos

Desarrollo
1. ¿Qué es un modelo?
Un modelo es una representación abstracta de un sistema y la porción del mundo que interactúa con él.

1.1 ¿Qué es un modelo del software?
Un modelo de software es una descripción de un aspecto de un sistema software, escrita en un lenguaje bien definido.
Los modelos permiten especificar aspectos del sistema software tales como los requisitos, la estructura, el comportamiento o el despliegue.

1.2 El metamodelo
El metamodelo de un lenguaje es una descripción de todos los conceptos que pueden usarse en el mismo.

1.3 Modelo Conceptual
El Modelo Conceptual se utiliza para representar las actividades que elicitan y describen el conocimiento general que un sistema particular debe ofrecer

2. Desarrollo de Software Dirigido por Modelos
El Desarrollo de Software Dirigido por Modelos es un paradigma de ingeniería del software que propone el uso de modelos para conducir las distintas fases del desarrollo. MDD propone el uso de modelos como elementos de primera clase para el desarrollo de software.
MDD utiliza un tipo determinado de lenguaje de programación que son los lenguajes específicos de dominio (DSL por sus siglas en inglés),

Ventajas

* Proporcionan implementaciones prediseñadas que representan los conceptos fundamentales del dominio. * Proporcionan notación natural y evita el desorden sintáctico. * Permiten analizadores estáticos que pueden detectar más errores. * Permiten la opción de generar código optimizado. * Permiten mejorar herramientas del entorno de desarrollo.

Tecnología de Transformación de Modelos (TTM), el cual se define como la capacidad de tomar un modelo abstracto y transformarlo de forma automática en otro modelo o código.

El Modelo Conceptual está compuesto por varios modelos y cada modelo representa una vista diferente del sistema. Los modelos tienen relaciones entre sí que permiten la transformación de un modelo a otro de un nivel menos abstracto. El procedimiento que transforma los modelos al código de un lenguaje de programación se denomina Compilación de Modelos.

2.1 Objetivos principales del enfoque MDD * Mejorar la calidad del software. * Mejorar la mantenibilidad del software. * Mejorar los niveles de reusabilidad. * Manejo de la complejidad – abstracción. * Productividad. * Interoperabilidad.

2.2 Etapas de MDD * La construcción de un modelo del dominio, que expresa la lógica del negocio. * La construcción de los Modelos Independientes de la Plataforma (PIM), que expresa la funcionalidad del sistema en forma independiente de las características de plataformas de implementación específicas. * La transformación de un Modelo Independiente de la Plataforma (PIM), en uno o más Modelos Específicos de la Plataforma (PSM). * La transformación de modelos específicos de la plataforma (PSM) a modelos de implementación, denominados ISM.

2.4 Ejes principales de MDD

* modelos con alto nivel de abstracción e independientes de cualquier tecnología de implementación, llamados PIM y modelos que especifican el sistema en términos de construcciones de implementación disponibles en alguna tecnología específica, conocidos como PSM . * Un PIM es transformado en uno o más PSMs, es decir que para cada plataforma tecnológica específica se genera un PSM específico. La transformación entre modelos constituye el motor del MDD y de esta manera los modelos pasan de ser entidades meramente contemplativas a ser entidades productivas

2.6 Ventajas de MDD * Proporciona una elevación del nivel de abstracción debido a que se estudian los niveles de conceptos cercanos al dominio del problema. * El código fuente final se genera a partir de especificaciones de alto nivel

2.7 Deficiencias * Pobre usabilidad de las herramientas. * Problemas de interoperabilidad entre herramientas. * Problemas de escalabilidad de los modelos. * Falta base teórica, tecnología actual desarrollada ad-hoc. * Falta concienciación sobre su potencial.

* Dificultad de introducir nuevos métodos en la empresa.

* Mentalidad conservadora de muchos profesionales, inercia al cambio.

* Empresas centradas en el corto plazo para conseguir el ROI.

Conclusiones
Los beneficios radican en poder manejar proyectos complejos, acortar los ciclos de desarrollo y gestionar adecuadamente los niveles de expectativas de los interesados (stakeholders).

Control, Gestión y Garantía de la Calidad del Software

¿Qué es la Calidad del Software?
A la hora de definir la calidad del software se pueden adoptar diferentes aproximaciones. Como primera aproximación es importante diferenciar entre la calidad del PRODUCTO software y la calidad del PROCESO de desarrollo. No obstante, las metas que se establezcan para la calidad del producto van a determinar las metas a establecer para la calidad del proceso de desarrollo, ya que la calidad del producto va a estar en función de la calidad del proceso de desarrollo.
Sin un buen proceso de desarrollo es casi imposible obtener un buen producto.
La calidad del producto software se diferencia de la calidad de otros productos de fabricación industrial, ya que el software tiene ciertas características especiales:
El software es un producto mental, es algo abstracto, y su calidad también lo es.
Se desarrolla, no se fabrica. El coste está fundamentalmente en el proceso de diseño, no en la producción.

Los principales problemas a los que nos enfrentamos a la hora de hablar de la calidad de un producto software son:

1. La definición misma de la calidad del software: ¿Es realmente posible encontrar un conjunto de propiedades en un producto software que nos den una indicación de su calidad? Para dar respuesta a estas preguntas aparecen los Modelos de Calidad.

Modelos de calidad: En los modelos de calidad, la calidad se define de forma jerárquica. Resuelven la complejidad mediante la descomposición. La calidad es un concepto que se deriva de un conjunto de sub-conceptos.

2. La comprobación de la calidad del software: ¿Cómo medir el grado de calidad de un producto software? Aquí aparece el concepto de Control de Calidad, del que hablaremos en la unidad 2. Control de Calidad: Actividades para evaluar la calidad de los productos desarrollados.

3. La mejora de la calidad del software: ¿Cómo utilizar la información disponible acerca de la calidad del producto software para mejorar su calidad a lo largo del ciclo de vida? Tal y como veremos, no sólo es posible “medir” la calidad, sino también “construir” la calidad durante el proceso de desarrollo del producto. En este eje aparecen dos conceptos importantes: Gestión de Calidad: Determinación y aplicación de las políticas de calidad de la empresa (objetivos y directrices generales).

Garantía o Aseguramiento de Calidad: Conjunto de actividades planificadas y sistemáticas necesarias para proporcionar confianza en que el producto software satisfará los requisitos dados de calidad.

Principios de Calidad de Software:
Estos Principios de Gestión de la Calidad se encuentran descritos en la norma ISO 9000:2005 “Sistemas de Gestión de la Calidad. Fundamentos y Vocabulario”

1) Enfoque al cliente: Las organizaciones dependen de sus clientes y por lo tanto deberían comprender las necesidades actuales y futuras de los clientes, satisfacer los requisitos de los clientes y esforzarse en exceder las expectativas de los clientes.

2) Liderazgo: Los líderes establecen la unidad de propósito y la orientación de la organización. Ellos deberían crear y mantener un ambiente interno, en el cual el personal pueda llegar a involucrarse totalmente en el logro de los objetivos de la organización.

3) Participación del personal: El personal, a todos los niveles, es la esencia de una organización y su total compromiso posibilita que sus habilidades sean usadas para el beneficio de la organización.

4) Enfoque basado en procesos: Un resultado deseado se alcanza más eficientemente cuando las actividades y los recursos relacionados se gestionan como un proceso.

5) Enfoque de sistema para la gestión: Identificar, entender y gestionar los procesos interrelaciones como un sistema, contribuye a la eficacia y eficiencia de una organización en el logro de sus objetivos. ISO 9000:2000 (traducción certificada)

6) Mejora continua: La mejora continua del desempeño global de la organización debería ser un objetivo permanente de ésta.

7) Enfoque basado en hechos para la toma de decisión: Las decisiones eficaces se basan en el análisis de los datos y la información.

8) Relaciones mutuamente beneficiosas con el proveedor: Una organización y sus proveedores son independientes, y una relación mutuamente beneficiosa aumenta la capacidad de ambos para crear valor.

Es importante tener presente a estos principios como pilares básicos a tener en cuenta si se quieren implantar sistemas o modelos de gestión orientados a obtener buenos resultados empresariales de manera eficaz y eficiente.

Modelos de Calidad

Modelo de McCall: Este modelo se focaliza en el producto final identificando atributo claves desde el punto de vista del Cliente. Esto atributos se denominan factores de calidad y son normalmente atributos externos pero también se incluyen algunos atributos internos.

Cada atributo externo se domina factor de calidad. Los factores de calidad son abstractos para ser medidos directamente, por lo cual se introduce un atributo de bajo nivel denominado criterios de calidad.

Según McCall algunos criterios de calidad son atributos internos que tienen efectos directos en atributos externos.
El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto: Puntos De Vista O Ejes | Factor | Criterios | OPERACIÓN DEL PRODUCTO | Facilidad de uso | - Facilidad de operación: Atributos del software que determinan la facilidad de operación del software.- Facilidad de comunicación: Atributos del software que proporcionan entradas y salidas fácilmente asimilables.- Facilidad de aprendizaje: Atributos del software que facilitan la familiarización inicial del usuario con el software y la transición del modo actual de operación.- Formación: El grado en que el software ayuda para permitir que nuevos usuarios apliquen el sistema. | | Integridad | - Control de accesos. Atributos del software que proporcionan control de acceso al software y los datos que maneja.- Facilidad de auditoría: Atributos del software que facilitan la auditoría de los accesos al software.- Seguridad: La disponibilidad de mecanismos que controlen o protejan los programas o los datos. | | Corrección | - Completitud: Atributos del software que proporcionan la implementación completa de todas las funciones requeridas.- Consistencia: Atributos del software que proporcionan uniformidad en las técnicas y notaciones de diseño e implementación.- Trazabilidad o rastreabilidad: Atributos del software que proporcionan una traza desde los requisitos a la implementación con respecto a un entorno operativo concreto. | OPERACIÓN DEL PRODUCTO | Fiabilidad | - Precisión: Atributos del software que proporcionan el grado de precisión requerido en los cálculos y los resultados.-Tolerancia a fallos: Atributos del software que posibilitan la continuidad del funcionamiento bajo condiciones no usuales.-Modularidad: Atributos del software que proporcionan una estructura de módulos altamente independientes.-Simplicidad: Atributos del software que posibilitan la implementación de funciones de la forma más comprensible posible.- Exactitud: La precisión de los cálculos y del control. | | Eficiencia | -Eficiencia en ejecución: Atributos del software que minimizan el tiempo de procesamiento.-Eficiencia en almacenamiento: Atributos del software que minimizan el espacio de almacenamiento necesario. | REVISION DEL PRODUCTO | Facilidad de mantenimiento | -Concisión: Atributos del software que posibilitan la implementación de una función con la menor cantidad de códigos posible.-Auto descripción: Atributos del software que proporcionan explicaciones sobre la implementación de las funciones. | | Facilidad de prueba | -Instrumentación: Atributos del software que posibilitan la observación del comportamiento del software durante su ejecución para facilitar las mediciones del uso o la identificación de errores. | | Flexibilidad | -Capacidad de expansión: Atributos del software que posibilitan la expansión del software en cuanto a capacidades funcionales y datos.-Generalidad: Atributos del software que proporcionan amplitud a las funciones implementadas. | | Reusabilidad | -Independencia entre sistema y software: Atributos del software que determinan su dependencia del entorno operativo.- Independencia del hardware: Atributos del software que determinan su dependencia del hardware. | | Interoperabilidad | -Compatibilidad de comunicaciones: Atributos del software que posibilitan el uso de protocolos de comunicación e interfaces estándar.-Compatibilidad de datos: Atributos del software que posibilitan el uso representaciones de datos estándar.-Estandarización en los datos: El uso de estructuras de datos y de tipos estándar a lo largo de todo el programa. | | Portabilidad | -Independencia entre sistema y software.- Independencia del hardware. |

Modelo ISO 9126
El modelo ISO 9126 es una variante del modelo McCall fue propuesta como estándar internacional para la medición de la calidad en el software. La ISO 9126 clasifica la calidad del software en un conjunto estructurado de características y sub-características a su vez está dividida en atributos. Un atributo es una entidad la cual puede ser verificada o medida en el producto software. Los atributos no están definidos en el estándar, ya que varían entre diferentes productos software. Factor de calidad | Sub Característica | Funcionabilidad |  Idoneidad Exactitud Interoperabilidad Seguridad Cumplimiento de normas | Fiabilidad |  Madurez Recuperabilidad Tolerancia a fallos | Usabilidad |  Aprendizaje Comprensión Operatividad Atractividad | Eficiencia |  Comportamiento en el tiempo Comportamiento de recursos | Mantenibilidad |  Estabilidad Facilidad de análisis Facilidad de cambio Facilidad de pruebas | Portabilidad |  Capacidad de instalación Capacidad de reemplazamiento Adaptabilidad Co-Existencia |

La integración de ISO 9126 e ISO 15939 permiten plantear un proceso de 4 pasos:
1. Identificación de los requerimientos relacionados a la calidad del producto, es decir, seleccionar la parte del modelo de calidad (ISO/IEC 9126-n) que resulta relevante para la evaluación de calidad.
2. Identificación del contexto de interpretación. Es decir, selección de los valores de 227 referencias y determinación de los target especificados en un contexto determinado
3. Uso de las medidas derivadas de la etapa de preparación de los datos
4. Comparación y análisis de los resultados obtenidos respecto de un conjunto de valores de referencia.
Conclusión:
La calidad de un producto ya no está centrada en la satisfacción plena del cliente, la evolución de la calidad ahora nos permite y exige tener un producto de calidad debido a un proceso de calidad y este a su vez guiado por una gestión de calidad. La calidad debe estar implícita en cada área y proceso de la empresa y no así solo en el producto final.
Para lograr que las empresas produzcan productos de calidad deben regirse a normas, estándares de calidad a nivel mundial, para ello hay organizaciones dedicadas a elaborar, modelos, parámetros para lograr la calidad de nuestra empresa.

Control De Calidad Del Software
El objetivo de las actividades de Control de Calidad es comprobar si un producto posee o no posee una determinada característica de calidad en el grado requerido. Cuando un producto no posee una determinada característica de calidad se dice que tiene un DEFECTO. Por lo tanto, se puede decir también que el objetivo del Control de Calidad es identificar defectos en el producto y corregirlos. * Control de calidad: "Conjunto de técnicas y actividades de carácter operativo, utilizadas para verificar los requerimientos relativos a la calidad del producto o servicio". * Control de la calidad del software: Técnicas y actividades de carácter operativo, utilizadas para verificar los requisitos relativos a la calidad, centradas en mantener bajo control el proceso de desarrollo y eliminar las causas de los defectos en las diferentes fases del ciclo de vida.
El control de la calidad del software está centrado en dos objetivos fundamentales: * Mantener bajo control un proceso. * Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.
Las estrategias de trabajo se representan como sigue:

Se pueden clasificar las actividades de control de calidad en dos categorías: controles estáticos y controles dinámicos. Los primeros analizan el objeto sin necesidad de ejecutarlo mientras que los segundos requieren la ejecución del objeto que está siendo probado.

Controles Estáticos

Controles estáticos manuales informales:

Estas actividades las realizan los propios autores de los objetos a comprobar, o personas de su misma categoría y ocupación.

Comprobación de escritorio (desk checking):
Consiste en examinar a mano e individualmente el objeto que se acaba de desarrollar. Es el método más tradicional para analizar un programa.
Se debe aplicar a los requisitos, especificaciones de diseño y código según se van desarrollando.

Debe ser cuidadoso y concienzudo para que sea efectivo. Es más efectivo si se hace intercambiando el objeto a examinar con otro compañero.

Revisión por pares o iguales (peer review):
Consiste en la revisión del código de un programador por otros programadores (sus pares).

.

Controles estáticos manuales disciplinados
Las revisiones y auditorías son la evolución natural de la Comprobación de Escritorio, pero a diferencia de aquélla pasan a ser técnicas de grupo. Su misión principal es conseguir que la responsabilidad del control de calidad no recaiga sólo sobre el propio desarrollador.

Auditorías:

Una auditoría consiste en realizar una investigación para determinar:

- El grado de cumplimiento y la adecuación de los procedimientos, instrucciones, especificaciones, códigos, estándares u otros requisitos de tipo contractual establecidos y aplicables.

- La efectividad y adecuación de la implementación realizada.

Se pueden considerar tres tipos de auditorías:

- Auditoría del producto: El objetivo es cuantificar el grado de conformidad del producto con las características requeridas. Las auditorías del producto software más comunes son la auditoría Funcional y la auditoría Física.

- Auditoría del proceso: El objetivo es evaluar el proceso de desarrollo o de gestión, y evaluar su completitud y efectividad, determinando dónde se puede mejorar. En el desarrollo de software se suelen realizar dos tipos de auditorías del proceso:

* Auditorías de proyecto: cuyo objetivo es evaluar la productividad y eficacia del equipo que trabaja en un proyecto así como la efectividad de los métodos y herramientas utilizados.

* Auditorías de gestión de proyecto: cuyo objetivo es evaluar la efectividad de las prácticas de gestión realizadas y la organización del proyecto.

- Auditoría del sistema de calidad: El objetivo es evaluar la completitud y efectividad del propio sistema de calidad establecido.

Revisiones
Se puede definir una revisión como una reunión formal en la que se presenta el estado actual de los resultados de un proyecto a un usuario, cliente u otro tipo de persona interesada, y se realiza un análisis estructurado de los mismos.
Las revisiones son, hoy en día, el único método de control de calidad eficaz en las fases iniciales del desarrollo a la hora de identificar desviaciones con respecto a las especificaciones de calidad.
Las diferencias más importantes entre las revisiones y las auditorías son las siguientes:

- Las revisiones se llevan a cabo desde las primeras fases del desarrollo, mientras que las auditorías se llevan a cabo en las fases finales.

- El objetivo de las revisiones es detectar defectos, mientras que el objetivo de las auditorías es certificar conformidad e identificar desviaciones.

Tipos de revisiones:
Hay dos tipos fundamentales de revisiones: las inspecciones y los walkthrough. La diferencia entre ellos está en la forma en que se desarrolla la reunión de revisión.

- Inspecciones: En las que los participantes van leyendo el documento, paso a paso, guiados por el autor del mismo, y comprobando en cada paso el cumplimiento de los criterios de una lista de comprobación.

- Walkthrough (visita guiada): En las que se demuestra la funcionalidad del objeto revisado mediante la simulación de su funcionamiento con casos de prueba y ejemplos. Se introducen al objeto los casos de prueba y se van registrando los resultados intermedios.

Controles Estáticos Automáticos

Dentro de esta categoría tenemos el análisis estático automático y la verificación formal de programas.

La mayor parte del análisis estático automático del código lo realizan los compiladores, que pueden detectar desde expresiones sintácticamente incorrectas hasta incompatibilidades de tipo y otros errores de tipo semántico.

Otras técnicas de análisis estático automático de programas son:

- Análisis de Flujo:
Se basa en una representación gráfica. Se usan grafos en los que los nodos representan sentencias o segmentos de programa y los arcos posibles transiciones de control desde un segmento a otro.

- Ejecución simbólica:
Consiste en la ejecución simbólica de ciertos caminos dentro del programa, durante la cual se verifican ciertas expresiones simbólicas con respecto a ciertas condiciones y afirmaciones preestablecidas.

Verificación formal

Consiste en demostrar matemáticamente la corrección de un programa con respecto a sus especificaciones.

Controles Dinámicos:
Se llama controles dinámicos a aquellos que requieren la ejecución del objeto que se está probando o de un modelo del mismo.
Se llama PRUEBA del Software al proceso en el que se ejecuta un sistema con el objetivo de detectar fallos.

Se llama DEPURACIÓN al proceso en el que se localiza el defecto que es la causa de un fallo, se determina la forma de corregirlo, se evalúa el efecto de la corrección y se lleva a cabo la corrección. Por lo general, después del proceso de depuración será necesario repetir el proceso de prueba, para garantizar que el defecto quedó efectivamente corregido y que no se introdujeron nuevos defectos.

Garantía De Calidad De Software
¿Qué es la Garantía de Calidad?

Realizando un compendio de las definiciones de diversos autores, se puede decir que la garantía de calidad abarca todas aquellas actividades o prácticas que se realizan con el objetivo de asegurar un cierto nivel de calidad en el producto desarrollado.
Las áreas que caen bajo la responsabilidad del grupo de Garantía de Calidad son tres:

1. Las metas y objetivos:
Debe asegurar que las metas de la organización en primer lugar, y los objetivos del usuario en segundo lugar se están satisfaciendo, y que no existen conflictos entre ellos, o entre los objetivos de diferentes usuarios.

2. Los métodos:
Debe asegurar que las actividades de desarrollo de software siguen los procedimientos establecidos, se ajustan a los estándares seleccionados, están de acuerdo con las políticas de la organización y se ejecutan según las guías de trabajo y recomendaciones disponibles.

3. Rendimiento:
Debe asegurar que se optimiza la utilización del hardware y software en los productos desarrollados, que son económicos (se desarrollan con el menor coste posible), eficientes (sacan el máximo partido posible a los recursos utilizados) y efectivos (alcanzan el resultado deseado con la menor cantidad posible de recursos, tiempo y esfuerzo).

Las principales tareas del grupo de garantía de calidad, por lo tanto, son:

1. Planificación de la calidad: Consiste en seleccionar, clasificar y ponderar las propiedades de calidad que se van a establecer como requisitos, con respecto al producto y con respecto al proceso. Se elegirán también los mecanismos de control de calidad a utilizar para medir y evaluar estas características y se determinarán las metas a alcanzar.

2. Supervisión de la calidad: Consiste en supervisar y corregir, si es necesario, el trabajo que se está realizando (según los resultados obtenidos con las actividades de control de calidad), con el objetivo de llegar a satisfacer los requisitos establecidos.
Para ello, es necesario revisar y auditar objetivamente los productos y las actividades para verificar que estén conformes con los procedimientos y estándares, y proporcionar los resultados de estas revisiones o auditorías informando a la dirección.

3. Construcción de la calidad: Actividades constructivas son aquellas que sirven para “construir” la calidad, es decir, son actividades preventivas cuyo objetivo es evitar la introducción de errores mediante la puesta en práctica de ciertos principios, métodos, formalismos y herramientas.

Gestión De Calidad Del Software
¿Qué es un Sistema de Calidad?
El Sistema de Calidad es el que define cómo implementar la Garantía de Calidad. Es un marco en el que se establecen las diferentes estrategias, actividades y herramientas de garantía de calidad que se van a utilizar.

Se puede definir un sistema de calidad en tres niveles diferentes:

- Organización: Es este el nivel en el que normalmente se establece el sistema de calidad.
- Proyecto
- Fase de desarrollo

El Sistema de Calidad establece también de qué forma se reparten las tareas y responsabilidades de garantía de calidad entre las diferentes unidades organizativas de la empresa y el personal. La forma en que esto se realice dependerá mucho de la estructura organizativa de la empresa y aún no existe un modelo generalmente aceptado de cómo hacerlo.

El Manual de Calidad debe ser una guía al Sistema de Calidad. Debe especificar la terminología, políticas, principios, responsabilidades y procesos del sistema, así como los estándares en los que se basa (por ejemplo, ISO 9001, 9002 o 9003). Debe dar respuesta a las cuestiones de Quién, Dónde y Por qué la Garantía de Calidad.