index

12
Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 1 Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII La Historia de la Falla del Sistema LAS-CAD (London Ambulance Service Computer-Aided Dispatch) Muerte de pacientes por demora en el arribo de ambulancias. Costó 1.5 millones de liras esterlinas. Sistema totalmente automatizado para tratar las llamadas de emergencias y el despacho de ambulancias: Un buscador automático para localizar incidentes con los números de teléfono. Localización de las ambulancias a través de la transmisión de sus señales de radio. Pantallas controladoras para mostrar ambulancias y accidentes. Propuesta del sistema de los recursos disponibles más adecuados para contestar una llamada particular. Comunicación de radio en las terminales de datos móbiles de las ambulancias. En la mañana del 26 de octubre, los trabajadores en la sala de control debieron enfrentar cambios en el modo en que ellos hacían sus trabajos: La introducción del sistema incluyendo el sistema propuesto de ubicación de ambulancias solamente; El reemplazo total de los registros en papel anteriores; La ausencia de cualquier sistema de respaldo en papel o sistema; Reconfiguración y reamoblamiento de la sala de control; Remosión de la división previa de Londres en tres zonas, cada una con su control dedicado; Reemplazo de los controladores por asistentes de control en la sala de control; Aspecto social No hubo capacitación de los asistentes de control, ni de choferes en el sistema. Aspecto técnico el sistema estaba corriendo sin respaldo de testeo y el software no estaba completo, no ajustado apropiadamente y no totalmente testeado. Había problemas con la transmisión de datos hacia y desde las terminales móbiles. Los problemos fueron causados por un número de causas operacionales que se automantuvieron y se reforzaron una vez que el sistema comenzó a tener atascamiento de llamadas. Los resultados finales fueron: varios o ningún vehículo fue enviado a un accidente; llamadas perdidas o largas demoras de atención; recursos erróneamente mostrados como no disponibles; y un creciente número de llamadas para preguntar porqué no arribaban las ambulancias. Como consecuencia un número de pacientes esperaron varias horas por una ambulancia, hasta 17 horas en un caso. Muertes por no arribo de unidades coronarias a tiempo. Mientras se debatían los problemas de LAS se puso en operación parcial, hasta el 4 de noviembre, en el que una falla de programación lo saco de servicio y se volvió al sistema manual original.

Upload: roger-romero

Post on 22-Dec-2014

62 views

Category:

Documents


0 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Index

Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 1

Manual del estudiante de Ingeniería en Sistemasde UTN/Ingeniería de requerimientos/Unidad VII

La Historia de la Falla del Sistema LAS-CAD(London Ambulance Service Computer-Aided Dispatch)•• Muerte de pacientes por demora en el arribo de ambulancias.•• Costó 1.5 millones de liras esterlinas.Sistema totalmente automatizado para tratar las llamadas de emergencias y el despacho de ambulancias:•• Un buscador automático para localizar incidentes con los números de teléfono.•• Localización de las ambulancias a través de la transmisión de sus señales de radio.•• Pantallas controladoras para mostrar ambulancias y accidentes.•• Propuesta del sistema de los recursos disponibles más adecuados para contestar una llamada particular.•• Comunicación de radio en las terminales de datos móbiles de las ambulancias.En la mañana del 26 de octubre, los trabajadores en la sala de control debieron enfrentar cambios en el modo en queellos hacían sus trabajos:•• La introducción del sistema incluyendo el sistema propuesto de ubicación de ambulancias solamente;•• El reemplazo total de los registros en papel anteriores;•• La ausencia de cualquier sistema de respaldo en papel o sistema;•• Reconfiguración y reamoblamiento de la sala de control;•• Remosión de la división previa de Londres en tres zonas, cada una con su control dedicado;•• Reemplazo de los controladores por asistentes de control en la sala de control;Aspecto social

No hubo capacitación de los asistentes de control, ni de choferes en el sistema.Aspecto técnico

el sistema estaba corriendo sin respaldo de testeo y el software no estaba completo, no ajustadoapropiadamente y no totalmente testeado. Había problemas con la transmisión de datos hacia y desde lasterminales móbiles.

Los problemos fueron causados por un número de causas operacionales que se automantuvieron y se reforzaron unavez que el sistema comenzó a tener atascamiento de llamadas.Los resultados finales fueron: varios o ningún vehículo fue enviado a un accidente; llamadas perdidas o largasdemoras de atención; recursos erróneamente mostrados como no disponibles; y un creciente número de llamadaspara preguntar porqué no arribaban las ambulancias. Como consecuencia un número de pacientes esperaron variashoras por una ambulancia, hasta 17 horas en un caso. Muertes por no arribo de unidades coronarias a tiempo.Mientras se debatían los problemas de LAS se puso en operación parcial, hasta el 4 de noviembre, en el que una fallade programación lo saco de servicio y se volvió al sistema manual original.

Page 2: Index

Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 2

Grupo Objetivos Organizacionales Actitud frente a laTecnología

Interés en el Sistema

Gerencia LAS Visión de Negocio, Cambio Cultural, Menores costos,By-Pass NUPE

Instrumental Alcanzar los objetivos de LAS

NUPE Mas recursos, Mejores condiciones de trabajo, Perpetuarla NUPE

Dependiente del contexto Mejorar las condiciones de trabajo yhacerlo mejor

Gerente deSistemas

Producir y dirigir buenos sistemas Funcional - Ingenieril Provisión de buen servicio y sistemas aLAP

Gobierno Buen ejemplo de la política de salud, Menor poder deNUPE

Política Solucionar problemas

La falla o éxito de un proyecto está siempre en relación a un grupo de interés. Los intereses y objetivos siempre estánen relación a su ambiente social y político más que tecnológico. El éxito no está asociado a haber encontrado latecnología adecuada o haber ajustado la tecnología a la organización. Puede que los tecnólogos, en determinadassituaciones, no puedan influir en la percepción de falla del sistema o no. El papel de la IR no está claro en este caso,pero sí es claro que no puede asumir una barrera entre el sistema y la organización social/empresaria. Sí necesitainvolucrarse en la articulación de esos límites.

Metodología de Sistemas de Software (SSM)SSM es un enfoque orientado a objetivos. Se dirige al sistema deseado y cómo lograrlo. SSM soporta puntos devista. Diferentes perspectivas.Tiene siete etapas distintas1.1. Examinando la Situación Problemática.2.2. Expresando la Situación Problemática. Dibujo enriquecido de la situación real.3.3. Selección. Vistas.4.4. Construcción de modelos conceptuales.5.5. Comparación del modelo con el mundo real.6.6. Identificación de cambios deseables y posibles.7.7. Recomendación de cursos de acción.

Etapa 1: La situación - no estructuradaEl propósito es describir el problema en términos de:•• Quién está involucrado.•• Cuáles son sus percepciones de la situación.•• Cuál es la estructura de la organización.•• Cuáles los procesos.

Page 3: Index

Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 3

Etapa 2: La situación - expresadaEl propósito es expresar el problema de modo que ayude a la elección de los sistemas relevantes de la etapa 3.Consiste en:• Construir un dibujo enriquecido (Boceto).•• Deberá mostrar las estructuras principales y el patrón de comunicaciones formales e informales.•• Elementos del proceso que se desea investigar.•• La intención es que los usuarios se encuentren en él.

Etapa 3: Sistemas RelevantesObjetivo: encontrar sistemas que sean relevantes para la situación problemática.Debe incorporar un punto de vista particular.Cada sistema encontrado debe tener una Razón o Definición. Para saber si esta es bien formulada se da el siguientenemónico:• Cliente que es beneficiario o víctima.• Actor que lleva a cabo la actividad.• Transformación de inputs en outputs.• Vista del mundo o punto de vista.• Dueño, el que tiene el poder de autorizar o comprar el sistema.• Ambiente, restricciones del entorno del sistema.Ejemplo sobre una compañía de renta de autos:• CGerentes corporativos.• ALos servicios de la empresa.• TClientes con necesidad de autos satisfechos.• 'ViProvisión de autos a empresas que necesitan movilidad.• DGerencia adiministrativa.• AExitencia y actividad de empresas competidoras.

Etapa 4: Modelos ConceptualesUn modelo conceptual es un modelo de una actividad humana que rigurosamente se ajusta a una de las definicionesraíz.Las actividades pueden ser derivadas de los verbos consignados en las definiciones, y los modelos mostrarán lasdependencias entre actividades.Se deben mostrar las entradas y salidas implicadas en las transformaciones.En el Modelo Formal de un Sistema, una actividad humana en el sistema, S, es válida (formal), si y solo si:•• S tiene un propósito o misión.•• S tiene una medida de performance.•• S contiene un proceso de toma de decisión.•• S tiene componentes, que son ellos mismos sistemas con las mismas propiedades que S.•• S tiene componentes que interactúan de tal modo que sus efectos se transmiten a través del sistema.•• S exite en sistemas más amplios y en ambientes con los que interactúa.•• S tiene un límite, una interfase con el entorno.•• S tiene recursos, objetos de los procesos de toma de decisión.•• S tiene cierta garantía de continuidad.

Page 4: Index

Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 4

Etapa 5: ComparaciónEl Modelo Conceptual es comparado respecto del Sistema Real•• ¿Es esta actividad realizada en el Mundo Real?•• ¿Cómo se hace?•• ¿Como se mide su performance?•• ¿Se lleva a cabo eficientemente?

Etapa 6 y 7: ImplementaciónDe cambios deseables y factiblesSSM provee:•• Un modo de pensar sobre la organización e identificar el potencial de cambio.•• Ayuda para identificar stakeholders claves y sus intereses.•• Ayuda para identificar grupos de trabajos claves y sus intereses.•• Ayuda para identificar los roles de trabajo a soportar y porqué.•• Ayuda a describir esos roles.•• Ayuda a desarrollar visiones y propuestas de diseño.•• Comunicación entre personas.•• Ayuda a identificar conflictos entre stakeholders, y entre PdV.

ETHICS( Effective Technical and Human Implementation of Computer based Systems)•• Soporta identificación de objetivos del sistema para el usuario, administrador y puntos de vistas organizacionales.•• Lleva adelante una optimización conjunta de los sistemas social y técnico.La metodología es descripta para ser usada por administradores y usuarios de nuevas tecnologías. En IR se usa comouna técnica para problemas de análisis ya que provee una guia de cómo realizarlo.De acuerdo a Munford la técnica tiene 12 pasos: 1. Especificar el Objetivo del trabajo 2. Describir las actividades ynecesidades del trabajo actual 3. Considerar la Satisfacción del Trabajo 4. Decidir que necesidades cambiar 5.Ajustar los objetivos de eficiencia, efectividad y satisfacción del trabajo 6. Considerar opciones organizacionales 7.Reorganizar (Reingeniería?) 8. Elegir el sistema computacional 9. Entrenar al staff 10. Rediseñar los puestos detrabajo 11. Implementar 12 EvaluarLos pasos 1 a 5 tienen que ver con IR. No hay DR

Paso 1: Especificar la Misión y porqué es necesario el cambioMediante entrevistas al Gerente se trata de establecer: Misión del negocio, razón de su existencia y de lo que trata dealcanzar. Principales actividades para alcanzar los objetivos. Maneras de ser más eficiente, efectivos y de estar mássatisfecho con el trabajo. "Tratar de encontrar las razones por las cuales cambiar el modo actual de trabajar"

Paso 2: Describir las actividades y necesidades actualesSe debe describir lo siguiente: 1. Tareas diarias, cn tiempo de cada una. 2. Los problemas más frecuentes o másserios en el trabajo. 3. Los aspectos del trabajo que requieren coordinación. 4. Los aspectos del trabajo donde seestán llevando a cabo nuevos desarrollos. (nuevos procedimientos, productos, etc.) 5. Cómo se controla el trabajo.

Page 5: Index

Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 5

Paso 3: Considerar la satisfacción del trabajoSi la gente disfruta su trabajo, tendrán alta su moral y motivación y probablemente serán eficientes y efectivos a lavez que satisfechos

Se usan cuestionarios apropiados para este tipo de determinaciones.

Paso 4: Decidir que necesidades cambiarPor comparación de los resultados del paso 1 con el 2 y 3 determinar las tareas innecesarias, las que siendonecesarias no se llevan a cabo y las tareas nuevas. Se debe identificar lo siguiente:•• Cambios que ayuden a los objetivos del negocio, mejorando la eficiencia de administración - gerencia•• Cambios para mejorar la eficiencia global•• Cambios que mejoren la efectividad del personal•• Cambios que mejoren la efectividad del negocio•• Cambios que mejoren la satisfacción.•• Cambios futuros

Paso 5: Definir los objetivos de eficiencia, efectividad y satisfacciónAyudan a:•• Entender lo que el gerente desea obtener, exactamente, de cualquier cambio de trabajo o nueva tecnología, antes

de implementar•• Evaluar el éxito de cualquier reorganización del trabajo o la introducción de nuevas tecnologías

Paso 6: Considerar opciones organizacionalesEstá comprobado que se puede Informatizar el desorden

Munford considera que la respuesta positiva a las siguientes cuestiones, implica considerar una reorganización:•• ¿La reorganización ayudará al gerente a mejorar los objetivos de efectividad del personal o los del negocio?•• ¿Se pueden eliminar algunos de los problemas, dando un control más efectivo y rápido al resto?•• ¿La reorganización permitirá al gerente ser más efectivo en áreas críticas?•• ¿Aumentará la satisfacción del trabajo?•• ¿Hará al negocio más flexible y capaz de adaptarse a cambios futuros

Paso 7: Reorganizar: principios de un buen diseño organizacionalSe aconseja un enfoque incremental. De acuerdo a: a. La gente trabaja bien en grupos de 6 a 8 b. Dandoresponsabilidades aumenta el interés, la responsabilidad y la motivación c. Permitir la autocorrección de errores. =>Prevención d. Asegurar que la información llegue a quien la necesita en forma directa. => se evitan demoras e. Darobjetivos claros, pero permitir que cada uno sea libre de cómo alcanzarlos. Aumento de la responsabilidad y lainiciativa f. Dar responsabilidades claras g. Dar oportunidades de desarrollo, nuevos métodos o actividades h. Incluiral staff en los cambios organizacionales i. Guardar una estructura organizacional flexible.

Page 6: Index

Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 6

Paso 8: Elegir un sistema computacionalLa técnica no da ninguna guía de selección

Paso 9: Entrenar al staffEntrenamiento del staff y del personal en general, teniendo en cuenta el rediseño de los puestos de trabajo del paso10.

Paso 10: Rediseñar puestosSe debe considerar el puesto de cada miembro del staff y cada uno debe cumplir con los siguientes principios: a.Buen ajuste con la persona que hace el trabajo. Evitar el aburriento y el stress b. Variedad de trabajo y oportunidadesde desarrollar habilidades c. Permitir el juicio propio y la toma de decisiones d. Realizar trabajos completos e.Permitir aprender f. Sentimiento de importancia del trabajo.

Paso 11: ImplementaciónImportancia de adueñarse del cambio.

Paso 12: EvaluaciónSe debe realizar nuevas encuestas de satisfacción del trabajo para evaluar los cambios. Se deben tomar medidas deperformance que permitan medir las mejoras introducidas.

Enfoque de EASON para IT y el Cambio OrganizacionalEs un enfoque de diseño centrado en el usuario. Los aspectos claves son:•• Soporta alineación de estrategias técnicas, organizacionales y de negocios•• Soporta la construcción de sistemas en grupos de desarrollo•• Provee guías para evaluar costos y beneficios de soluciones alternativas, desde una perspectiva del usuario y de la

organización.Se debe resolver la brecha entre los dos sistemas, el técnico y el social.Las leyes y principios de las dos clases de sistemas son bastante diferentes y los métodos de construcción pertenecena distinto tipos de especialistas. En todas las etapas de desarrollo están separados, quizá detrás de objetivosconflictivos.

La brecha es cerrada si los usuarios y los técnicos trabajan en forma conjunta.Se basa en 10 Principios agrupados en cuatro categorías.

Integración de Sistemas1. Diseño socio-técnico: Desarrollo progresivo de los sistemas socio técnicos para servir a los objetivos del negocio.2. Sistemas para objetivos diversos: desarrollo de soluciones integrales que sirven para objetivos distintos y flexibles.

Estructuras de Diseño Centradas en el Usuario3. Desarrollando el sentido de pertenencia del usuario: La comunidad de usuarios debe sentir como propios lossistemas. 4. Incluyendo a Todos los Grupos de Interés: el diseño debe ser un puente entre usuarios y diseñadores. 5.Integrando las contribuciones entre Disciplinas: para posibilitar el desarrollo de soluciones integrales.

Page 7: Index

Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 7

Procesos de Diseño Centrados en el Usuario6. Requerimientos y valores de usuarios: Se debe incluir los requerimientos de los usuarios con objetivos y valores,naturaleza de las tareas y características de los usuarios. 7. Representación de Soluciones. 8. Revisar Opciones: losuusarios necesitan tiempo, recursos y estructura que les permita comparar las opciones o alternativas de solución.

Implementación del Sistema9. Adaptación y Evaluación Organizacional: adaptación incremental y revisión de los usuarios de los objetivos y elcrecimiento evolutivo de los sistemas. 10. Soporte de Usuarios: para que los usuarios puedan progresivamentedesarrollar competencias para explotar las facilidades tecnológicas provistas.

JADJoint Application DesignMetodología Estructurada de AnálisisEs una herramienta que permite a los usuarios finales y a los profesionales de SI, diseñar sistemas en forma conjunta,en sesiones grupales.Gibson y Jackson afirman que los resultados de los estudios realizados aplicando esta técnica aumentan de un 20% aun 60% la productividad sobre los métodos de diseño tradicionales.Además, afirman que promueve la cooperación, el entendimiento y el trabajo grupal entre distintos grupos deusuarios y el staff de SI.JAD define seis roles diferentes que deben estar representados en una sesión de grupo. Ellos son:•• Líder de la sesión.•• Representante de los usuarios.•• Especialista.•• Analista.•• Representante de SI.•• Patrocinador (sponsor) ejecutivo o dueño del sistema.Líder de la sesiónEs el facilitador de JAD. Dirige el proceso, facilita el debate y la preparación de documentos. Tiene, además de lasresponsabilidades como facilitador, otras actividades a su cargo fuera de la situación del encuentro:•• Tratar con el patrocinador (sponsor) de JAD para llegar a un acuerdo sobre quién debe asistir las reuniones.•• Acordar la agenda con los participantes.•• Encontrar una ubicación apropiada para los participantes.•• Asegurarse de la preparación correcta y a tiempo de los documentos y presentaciones.

Niveles y ActividadesEl método JAD puede ser utilizado a varios niveles de detalle, utilizando la visión del negocio, análisis de conceptos(a través de análisis de requerimientos) y especificación de diseños.Distintas actividades JAD serán necesarias para cada nivel de detalle. Las actividades JAD típicas son lasconsistentes en un Plan JAD seguido por uno o más Diseños JAD. Cada actividad está compuesta por tres fases:acostumbramiento, sesión y conclusión.

Page 8: Index

Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 8

Plan JADLa sesión de Plan JAD usualmente dura entre uno y cinco días, dependiendo en el tamaño y la complejidad delsistema. El líder de la sesión guía a los participantes a lo largo de ocho tareas predefinidas. Ellas son:•• Orientación. (Explicación de objetivos y tareas a desarrollar).•• Definición de requerimientos de alto nivel (incluyendo objetivos, beneficios anticipados del sistema,

consideraciones estratégicas y futuras, suposiciones y beneficios, seguridad, auditoría y control derequerimientos).

•• Límites y alcances del sistema (incluyendo diagrama de flujo de negocio, usuarios y ubicaciones, áreasfuncionales fuera del alcance del sistema).

•• Identificar y estimar tiempos de los Diseños JAD.•• Identificar los participantes de los Diseños JAD.•• Programar días y horarios para los Diseños JAD.•• Acordar los puntos y consideraciones de la documentación a generar del Plan JAD.•• Concluir la sesión.

Diseño JADLa sesión de Diseño JAD dura aproximadamente entre tres y diez días. El líder de la sesión guía a los participantes alo largo de las siguientes tareas:•• Orientación. (Explicación de objetivos y tareas a desarrollar).•• Revisión y refinación de los requerimientos y alcance del Plan JAD.•• Desarrollar diagrama de flujo del trabajo.•• Desarrollar descripción del flujo de trabajo.•• Identificar funciones y grupos de datos del sistema.•• Especificar los requerimientos de procesamiento.•• Acordar los puntos y consideraciones de la documentación a generar del Diseño JAD.•• Concluir la fase de sesión.Las sesiones de JAD están acompañadas por 'libros de trabajo' que contienen una colección de formas predefinidaspara los grupos, para que sean completadas durante la sesión. Ejemplos de estas formas predefinidas son:formularios de participantes, de resultados, de estimaciones, de salidas por pantalla, de reportes, de descripción deinterfaces y de descripción de funciones.Además de proveer soporte para analizar requerimientos en sesiones grupales, JAD también contribuye en las áreasde comunicación humana y desarrollo de conocimiento.Para el proceso de requerimientos, JAD soporta:•• la articulación del concepto de producto, requerimientos, medición de resultados.•• análisis de problemas.•• estudios de factibilidad y análisis de opciones de costo-beneficio.•• análisis y modelado.•• la documentación de requerimientos.En términos de comunicación humana, JAD soporta:•• la identificación de varios puntos de vista.•• la conciliación de los puntos de vista.•• la revisión por parte del usuario de los modelos desarrollados.•• el análisis de los propios problemas del usuario y la identificación de la necesidad de cambio.JAD colabora con el desarrollo de conocimiento de:

Page 9: Index

Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 9

•• Estructuras relevantes en el trabajo actual del usuario.•• Visiones y propósitos de diseño.•• Revisión de las distintas opciones tecnológicas.

QFDQuality Function DeploymentQFD se basa, al igual que JAD, en sesiones grupales, en donde la Casa de la Calidad del estudiante de Ingeniería en

Sistemas de UTN/Ingeniería de requerimientos/Unidad VII#endnote_1 [1] es utilizada como foco de atención.

QFD House of Quality for Enterprise Product DevelopmentProcesses

La Casa de la Calidad está centrada alrededor de unamatriz que muestra la relación entre los requerimientosdel cliente y las características propuestas del producto.

En el QFD los requerimientos del cliente constituyenun tema central a ser tratado y son utilizados como labase para fijar objetivos de diseño e implementación.El método de QFD tradicional se divide en cuatro fasesiterativas:•• Planeamiento del producto,•• Planeamiento del diseño,•• Planeamiento de proceso y control, y•• Planeamiento de producción.Las cuatro fases son similares. Cada una tiene su propiaCasa de Calidad y sesiones de grupo asociadas. Laspersonas que dirijan las sesiones grupales seránaquellas que son responsables de una fase particular delproducto.

Los reportes del uso del QFD en varias partes de laindustria de la computación demostraron reduccionesdel 17% en el tiempo de definición del producto y en laclaridad de la trazabilidad de los requerimientos desdeel diseño inicial hasta la producción completa.

El facilitadorUn desempeño apropiado del rol de facilitador, según varios autores, ayudará a que el estudio se completesatisfactoriamente y a que se integren completamente los distintos talentos existentes en el grupo, así como lashabilidades y potencial creativo de cada miembro.El facilitador tiene un rol de coordinador en la planificación, diseño, ejecución y finalización de un proyecto QFD.Juega un papel neutral, no evaluativo ni manipulativo en el grupo.

Page 10: Index

Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 10

Fases

Fase 1 - PlanificaciónActividades asociadas con la fase 1- PlanificaciónPASO 1

Establecer los requerimientos del producto en términos del cliente. Se colocan en la columna de la izquierda,bajo el título "Requerimientos del Cliente".

•• Los requerimientos pueden ser divididos en primarios, secundarios y terciarios.• Los requerimientos primarios son los más generales, como por ejemplo fácil de aprender; los demás son más

específicos.PASO 2

En este paso se listan las características del producto a lo largo de las columnas superiores de la matriz.•• Estas son las características finales del producto que serán necesarias para lograr alcanzar los requerimientos del

cliente.•• Deben ser capaces de ser expresadas en términos medibles.PASO 3

En este paso se desarrolla la Matriz de Relación, que muestra la relación existente entre los requerimientos delcliente y las características del producto.

•• Las distintas relaciones se describen como fuertes, medias o débiles.•• El beneficio de completar la matriz utilizando símbolos apropiados, es que rápidamente se demuestra si las

características del producto final cubren adecuadamente los requerimientos del cliente.• La ausencia de símbolos (o mayoría de símbolos débiles indican que los requerimientos del cliente no están

siendo alcanzados. Deberán ser modificadas las características del producto para modificar esta situación.PASO 4

Este paso es para agregar a la matriz la evaluación del mercado.•• Se muestra el rating de la importancia de cada requerimiento del cliente y una evaluación de cómo hace la

competencia para alcanzar cada uno.PASO 5

Este paso es una comparación de las características del producto final contra la performance de lacompetencia.

•• Este paso involucra la identificación numérica y medible del rating de performance, por ejemplo, de los productosA, B, C y D de la competencia contra cada una de nuestras características de producto.

PASO 6Este paso requiere del equipo QFD para identificar los objetivos medibles reales que deben ser alcanzados.

•• Estos objetivos están basados en el rating de importancia del cliente y las actuales fortalezas y debilidades delproducto.

PASO 7En este paso se seleccionan las características del producto que serán desarrolladas y producidas a lo largo delresto del proceso QFD.

Page 11: Index

Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 11

ConclusionesAdemás de proveer soporte para analizar requerimientos en sesiones grupales, QFD:•• Colabora en el desarrollo de distintas visiones y propósitos de diseño.•• Es capaz de trabajar conjuntamente con técnicas de análisis de mercado.•• Soporta el análisis de productos de la competencia.•• Soporta predicciones de usuarios y usos futuros.•• Soporta la identificación y especificación de atributos de calidad.

^  Graphic tool for defining the relationship between customer desires and the firm/product capabilities.

Referencias[1] http:/ / en. wikipedia. org/ wiki/ :Manual

Page 12: Index

Fuentes y contribuyentes del artículo 12

Fuentes y contribuyentes del artículoManual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII  Fuente: http://es.wikibooks.org/w/index.php?oldid=197531  Contribuyentes: Rgfernan, 1ediciones anónimas

Fuentes de imagen, Licencias y contribuyentesArchivo:A1 House of Quality.png  Fuente: http://es.wikibooks.org/w/index.php?title=Archivo:A1_House_of_Quality.png  Licencia: Public Domain  Contribuyentes: Original uploader wasCask05 at en.wikipedia

LicenciaCreative Commons Attribution-Share Alike 3.0 Unported//creativecommons.org/licenses/by-sa/3.0/