Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII                            ...
Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII                            ...
Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII                           3...
Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII                            ...
Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII                            ...
Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII                            ...
Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII                            ...
Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII                            ...
Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII                            ...
Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII                            ...
Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII                  11    Conc...
Fuentes y contribuyentes del artículo                                                                                     ...
Próxima SlideShare
Cargando en…5
×

Index

219 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
219
En SlideShare
0
De insertados
0
Número de insertados
1
Acciones
Compartido
0
Descargas
1
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Index

  1. 1. 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.
  2. 2. Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 2 Grupo Objetivos Organizacionales Actitud frente a la Interés en el Sistema Tecnología Gerencia LAS Visión de Negocio, Cambio Cultural, Menores costos, Instrumental Alcanzar los objetivos de LAS By-Pass NUPE NUPE Mas recursos, Mejores condiciones de trabajo, Perpetuar Dependiente del contexto Mejorar las condiciones de trabajo y la NUPE hacerlo mejor Gerente de Producir y dirigir buenos sistemas Funcional - Ingenieril Provisión de buen servicio y sistemas a Sistemas LAP Gobierno Buen ejemplo de la política de salud, Menor poder de Política Solucionar problemas NUPE La falla o éxito de un proyecto está siempre en relación a un grupo de interés. Los intereses y objetivos siempre están en relación a su ambiente social y político más que tecnológico. El éxito no está asociado a haber encontrado la tecnología adecuada o haber ajustado la tecnología a la organización. Puede que los tecnólogos, en determinadas situaciones, 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í necesita involucrarse 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 de vista. Diferentes perspectivas. Tiene siete etapas distintas 1. Examinando la Situación Problemática. 2. Expresando la Situación Problemática. Dibujo enriquecido de la situación real. 3. Selección. Vistas. 4. Construcción de modelos conceptuales. 5. Comparación del modelo con el mundo real. 6. Identificación de cambios deseables y posibles. 7. Recomendación de cursos de acción. Etapa 1: La situación - no estructurada El 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.
  3. 3. Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 3 Etapa 2: La situación - expresada El 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 Relevantes Objetivo: 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 siguiente nemó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 Conceptuales Un modelo conceptual es un modelo de una actividad humana que rigurosamente se ajusta a una de las definiciones raíz. Las actividades pueden ser derivadas de los verbos consignados en las definiciones, y los modelos mostrarán las dependencias 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.
  4. 4. Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 4 Etapa 5: Comparación El 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ón De cambios deseables y factibles SSM 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 como una 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 y necesidades 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 de trabajo 11. Implementar 12 Evaluar Los pasos 1 a 5 tienen que ver con IR. No hay DR Paso 1: Especificar la Misión y porqué es necesario el cambio Mediante entrevistas al Gerente se trata de establecer: Misión del negocio, razón de su existencia y de lo que trata de alcanzar. Principales actividades para alcanzar los objetivos. Maneras de ser más eficiente, efectivos y de estar más satisfecho con el trabajo. "Tratar de encontrar las razones por las cuales cambiar el modo actual de trabajar" Paso 2: Describir las actividades y necesidades actuales Se debe describir lo siguiente: 1. Tareas diarias, cn tiempo de cada una. 2. Los problemas más frecuentes o más serios en el trabajo. 3. Los aspectos del trabajo que requieren coordinación. 4. Los aspectos del trabajo donde se están llevando a cabo nuevos desarrollos. (nuevos procedimientos, productos, etc.) 5. Cómo se controla el trabajo.
  5. 5. Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 5 Paso 3: Considerar la satisfacción del trabajo Si la gente disfruta su trabajo, tendrán alta su moral y motivación y probablemente serán eficientes y efectivos a la vez que satisfechos Se usan cuestionarios apropiados para este tipo de determinaciones. Paso 4: Decidir que necesidades cambiar Por comparación de los resultados del paso 1 con el 2 y 3 determinar las tareas innecesarias, las que siendo necesarias 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ón Ayudan 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 organizacionales Está 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 organizacional Se aconseja un enfoque incremental. De acuerdo a: a. La gente trabaja bien en grupos de 6 a 8 b. Dando responsabilidades 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. Dar objetivos claros, pero permitir que cada uno sea libre de cómo alcanzarlos. Aumento de la responsabilidad y la iniciativa f. Dar responsabilidades claras g. Dar oportunidades de desarrollo, nuevos métodos o actividades h. Incluir al staff en los cambios organizacionales i. Guardar una estructura organizacional flexible.
  6. 6. Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 6 Paso 8: Elegir un sistema computacional La técnica no da ninguna guía de selección Paso 9: Entrenar al staff Entrenamiento del staff y del personal en general, teniendo en cuenta el rediseño de los puestos de trabajo del paso 10. Paso 10: Rediseñar puestos Se 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 oportunidades de 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ón Importancia de adueñarse del cambio. Paso 12: Evaluación Se debe realizar nuevas encuestas de satisfacción del trabajo para evaluar los cambios. Se deben tomar medidas de performance que permitan medir las mejoras introducidas. Enfoque de EASON para IT y el Cambio Organizacional Es 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 pertenecen a distinto tipos de especialistas. En todas las etapas de desarrollo están separados, quizá detrás de objetivos conflictivos. 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 Sistemas 1. 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 Usuario 3. Desarrollando el sentido de pertenencia del usuario: La comunidad de usuarios debe sentir como propios los sistemas. 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.
  7. 7. Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 7 Procesos de Diseño Centrados en el Usuario 6. 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: los uusarios necesitan tiempo, recursos y estructura que les permita comparar las opciones o alternativas de solución. Implementación del Sistema 9. Adaptación y Evaluación Organizacional: adaptación incremental y revisión de los usuarios de los objetivos y el crecimiento evolutivo de los sistemas. 10. Soporte de Usuarios: para que los usuarios puedan progresivamente desarrollar competencias para explotar las facilidades tecnológicas provistas. JAD Joint Application Design Metodología Estructurada de Análisis Es 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% a un 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 de usuarios 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ón Es el facilitador de JAD. Dirige el proceso, facilita el debate y la preparación de documentos. Tiene, además de las responsabilidades 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 Actividades El 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 las consistentes 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.
  8. 8. Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 8 Plan JAD La sesión de Plan JAD usualmente dura entre uno y cinco días, dependiendo en el tamaño y la complejidad del sistema. 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 de requerimientos). • Límites y alcances del sistema (incluyendo diagrama de flujo de negocio, usuarios y ubicaciones, áreas funcionales 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 JAD La 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 a lo 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 predefinidas para 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 de interfaces y de descripción de funciones. Además de proveer soporte para analizar requerimientos en sesiones grupales, JAD también contribuye en las áreas de 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:
  9. 9. 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. QFD Quality Function Deployment QFD 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. La Casa de la Calidad está centrada alrededor de una matriz que muestra la relación entre los requerimientos del cliente y las características propuestas del producto. En el QFD los requerimientos del cliente constituyen un tema central a ser tratado y son utilizados como la base para fijar objetivos de diseño e implementación. El método de QFD tradicional se divide en cuatro fases iterativas: • 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 propia Casa de Calidad y sesiones de grupo asociadas. Las personas que dirijan las sesiones grupales serán aquellas que son responsables de una fase particular del producto. Los reportes del uso del QFD en varias partes de la industria de la computación demostraron reducciones del 17% en el tiempo de definición del producto y en la QFD House of Quality for Enterprise Product Development Processes claridad de la trazabilidad de los requerimientos desde el diseño inicial hasta la producción completa. El facilitador Un desempeño apropiado del rol de facilitador, según varios autores, ayudará a que el estudio se complete satisfactoriamente y a que se integren completamente los distintos talentos existentes en el grupo, así como las habilidades 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.
  10. 10. Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 10 Fases Fase 1 - Planificación Actividades asociadas con la fase 1- Planificación PASO 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 del cliente 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 la competencia. • Este paso involucra la identificación numérica y medible del rating de performance, por ejemplo, de los productos A, B, C y D de la competencia contra cada una de nuestras características de producto. PASO 6 Este 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 del producto. PASO 7 En este paso se seleccionan las características del producto que serán desarrolladas y producidas a lo largo del resto del proceso QFD.
  11. 11. Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad VII 11 Conclusiones Ademá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
  12. 12. Fuentes y contribuyentes del artículo 12 Fuentes y contribuyentes del artículo Manual 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, 1 ediciones anónimas Fuentes de imagen, Licencias y contribuyentes Archivo: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 was Cask05 at en.wikipedia Licencia Creative Commons Attribution-Share Alike 3.0 Unported //creativecommons.org/licenses/by-sa/3.0/

×