SlideShare una empresa de Scribd logo
1 de 12
Descargar para leer sin conexión
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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
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/

Más contenido relacionado

La actualidad más candente

El ciclo de vida del desarrollo de los sistemas de información
El ciclo de vida del desarrollo de los sistemas de informaciónEl ciclo de vida del desarrollo de los sistemas de información
El ciclo de vida del desarrollo de los sistemas de informaciónJose Daniel Pacheco Mejia
 
Tecnicas de recoleccion_de_informacion
Tecnicas de recoleccion_de_informacionTecnicas de recoleccion_de_informacion
Tecnicas de recoleccion_de_informacionJose Luis Buenaño
 
Ciclo de vida de un sistema de informacion fase 7
Ciclo de vida de un sistema de informacion fase 7Ciclo de vida de un sistema de informacion fase 7
Ciclo de vida de un sistema de informacion fase 7IUTA
 
Analisis y Diseño de sistemas de información
Analisis y Diseño de sistemas de informaciónAnalisis y Diseño de sistemas de información
Analisis y Diseño de sistemas de informaciónysik granja
 
Fases De Analisis
Fases De AnalisisFases De Analisis
Fases De AnalisisJosse Perez
 
Ventajas y desventajas modelos
Ventajas y desventajas modelosVentajas y desventajas modelos
Ventajas y desventajas modelosCristHian Martinez
 
Etapas de analisis de sistemas
Etapas de analisis de sistemasEtapas de analisis de sistemas
Etapas de analisis de sistemasKaarlOoss Gaarcia
 
Inv preliminar,estudio de factibilidad, ciclo de vida pst21
Inv preliminar,estudio de factibilidad, ciclo de vida pst21Inv preliminar,estudio de factibilidad, ciclo de vida pst21
Inv preliminar,estudio de factibilidad, ciclo de vida pst21duberlisg
 
Tipos de ciclos de vida
Tipos de ciclos de vidaTipos de ciclos de vida
Tipos de ciclos de vidasandrasig
 
Fase de implementación de sistemas de información
Fase de implementación de sistemas de informaciónFase de implementación de sistemas de información
Fase de implementación de sistemas de informaciónNAHAMA19
 
Metodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De SistemasMetodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De Sistemasgrupo7inf162
 
Metodos del desarrollo de sistema de informacion
Metodos del desarrollo de sistema de informacionMetodos del desarrollo de sistema de informacion
Metodos del desarrollo de sistema de informacioncaroyu
 
Analisis y diseño de Sistemas - Capitulo 4 (Resumen)
Analisis y diseño de Sistemas - Capitulo 4 (Resumen)Analisis y diseño de Sistemas - Capitulo 4 (Resumen)
Analisis y diseño de Sistemas - Capitulo 4 (Resumen)Alexis Cáceres Montes
 

La actualidad más candente (20)

El ciclo de vida del desarrollo de los sistemas de información
El ciclo de vida del desarrollo de los sistemas de informaciónEl ciclo de vida del desarrollo de los sistemas de información
El ciclo de vida del desarrollo de los sistemas de información
 
Libro analisis de sistemas
Libro analisis de sistemasLibro analisis de sistemas
Libro analisis de sistemas
 
Metodologia kendall y Kendall
Metodologia kendall y KendallMetodologia kendall y Kendall
Metodologia kendall y Kendall
 
Tecnicas de recoleccion_de_informacion
Tecnicas de recoleccion_de_informacionTecnicas de recoleccion_de_informacion
Tecnicas de recoleccion_de_informacion
 
Ciclo de vida de un sistema de informacion fase 7
Ciclo de vida de un sistema de informacion fase 7Ciclo de vida de un sistema de informacion fase 7
Ciclo de vida de un sistema de informacion fase 7
 
Analisis y Diseño de sistemas de información
Analisis y Diseño de sistemas de informaciónAnalisis y Diseño de sistemas de información
Analisis y Diseño de sistemas de información
 
Fases De Analisis
Fases De AnalisisFases De Analisis
Fases De Analisis
 
Ventajas y desventajas modelos
Ventajas y desventajas modelosVentajas y desventajas modelos
Ventajas y desventajas modelos
 
Etapas de analisis de sistemas
Etapas de analisis de sistemasEtapas de analisis de sistemas
Etapas de analisis de sistemas
 
I ciclos de vida
I ciclos de vidaI ciclos de vida
I ciclos de vida
 
El ciclo de vida del desarrollo de sistemas
El ciclo de vida del desarrollo de sistemasEl ciclo de vida del desarrollo de sistemas
El ciclo de vida del desarrollo de sistemas
 
Inv preliminar,estudio de factibilidad, ciclo de vida pst21
Inv preliminar,estudio de factibilidad, ciclo de vida pst21Inv preliminar,estudio de factibilidad, ciclo de vida pst21
Inv preliminar,estudio de factibilidad, ciclo de vida pst21
 
Tipos de ciclos de vida
Tipos de ciclos de vidaTipos de ciclos de vida
Tipos de ciclos de vida
 
Fase de implementación de sistemas de información
Fase de implementación de sistemas de informaciónFase de implementación de sistemas de información
Fase de implementación de sistemas de información
 
Metodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De SistemasMetodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De Sistemas
 
Ciclo de vida de un sistema informático
Ciclo de vida de un sistema informáticoCiclo de vida de un sistema informático
Ciclo de vida de un sistema informático
 
Capitulo 12
Capitulo 12Capitulo 12
Capitulo 12
 
Ciclo de vida de un Sistema
Ciclo de vida de un SistemaCiclo de vida de un Sistema
Ciclo de vida de un Sistema
 
Metodos del desarrollo de sistema de informacion
Metodos del desarrollo de sistema de informacionMetodos del desarrollo de sistema de informacion
Metodos del desarrollo de sistema de informacion
 
Analisis y diseño de Sistemas - Capitulo 4 (Resumen)
Analisis y diseño de Sistemas - Capitulo 4 (Resumen)Analisis y diseño de Sistemas - Capitulo 4 (Resumen)
Analisis y diseño de Sistemas - Capitulo 4 (Resumen)
 

Destacado

Ledenraad_24jun2011_Antwoordformulier
Ledenraad_24jun2011_AntwoordformulierLedenraad_24jun2011_Antwoordformulier
Ledenraad_24jun2011_AntwoordformulierVU Connected
 
Un país orgulloso de sus instituciones
Un país orgulloso de sus institucionesUn país orgulloso de sus instituciones
Un país orgulloso de sus institucionesMIL404
 
3stepstoeffectivelycommunicating 090302170413-phpapp01
3stepstoeffectivelycommunicating 090302170413-phpapp013stepstoeffectivelycommunicating 090302170413-phpapp01
3stepstoeffectivelycommunicating 090302170413-phpapp01maher-othman
 
Sampling in Research
Sampling in ResearchSampling in Research
Sampling in ResearchEnzo Engada
 
Dt gtea activitat_poesia
Dt gtea activitat_poesiaDt gtea activitat_poesia
Dt gtea activitat_poesiagtea2011
 

Destacado (8)

Parte3
Parte3Parte3
Parte3
 
Capitulo 2
Capitulo 2Capitulo 2
Capitulo 2
 
Ledenraad_24jun2011_Antwoordformulier
Ledenraad_24jun2011_AntwoordformulierLedenraad_24jun2011_Antwoordformulier
Ledenraad_24jun2011_Antwoordformulier
 
Un país orgulloso de sus instituciones
Un país orgulloso de sus institucionesUn país orgulloso de sus instituciones
Un país orgulloso de sus instituciones
 
3stepstoeffectivelycommunicating 090302170413-phpapp01
3stepstoeffectivelycommunicating 090302170413-phpapp013stepstoeffectivelycommunicating 090302170413-phpapp01
3stepstoeffectivelycommunicating 090302170413-phpapp01
 
Sampling in Research
Sampling in ResearchSampling in Research
Sampling in Research
 
Dt gtea activitat_poesia
Dt gtea activitat_poesiaDt gtea activitat_poesia
Dt gtea activitat_poesia
 
Ley 122 05
Ley 122 05Ley 122 05
Ley 122 05
 

Similar a Index

Ciclo de vida del desarrollo de sistemas
Ciclo de vida del desarrollo de sistemasCiclo de vida del desarrollo de sistemas
Ciclo de vida del desarrollo de sistemasMILUGO
 
Inv preliminar,estudio de factibilidad, ciclo de vida pst21
Inv preliminar,estudio de factibilidad, ciclo de vida pst21Inv preliminar,estudio de factibilidad, ciclo de vida pst21
Inv preliminar,estudio de factibilidad, ciclo de vida pst21duberlisg
 
Analisis de sistemas de informacion
Analisis de sistemas de informacionAnalisis de sistemas de informacion
Analisis de sistemas de informacionLuis Cambal
 
Sistemas de informacion
Sistemas de informacionSistemas de informacion
Sistemas de informacioneduingonzalez2
 
Análisis de Sistemas - 1.pptx
Análisis de Sistemas - 1.pptxAnálisis de Sistemas - 1.pptx
Análisis de Sistemas - 1.pptxJimmyGonzlez14
 
principales actividades de la ingenieria de Requerimientos
principales actividades de la ingenieria de Requerimientosprincipales actividades de la ingenieria de Requerimientos
principales actividades de la ingenieria de RequerimientosMariaTeresaRenteriaO
 
Desarrollo de prototipos
Desarrollo de prototiposDesarrollo de prototipos
Desarrollo de prototiposTensor
 
Presentación digital Eliezer Alas
Presentación digital Eliezer AlasPresentación digital Eliezer Alas
Presentación digital Eliezer AlasEliezer Alas
 
Ciclo de Vida de Sistemas de Información
Ciclo de Vida de Sistemas de InformaciónCiclo de Vida de Sistemas de Información
Ciclo de Vida de Sistemas de Informaciónzet69lie
 
Sistemas_de_Informacion.ppt
Sistemas_de_Informacion.pptSistemas_de_Informacion.ppt
Sistemas_de_Informacion.pptPedroFalcn
 
Rediseño de la Organizacion con Sistemas de Información
Rediseño de la Organizacion con Sistemas de InformaciónRediseño de la Organizacion con Sistemas de Información
Rediseño de la Organizacion con Sistemas de InformaciónJOSE LUIS LIÑAN HERRERA
 
Taller en clases
Taller en clasesTaller en clases
Taller en clases3045433345
 
Metodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De InformaciónMetodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De Informaciónjorgeluisguzmntorres1
 
Sistemas de Informacion.pptx
Sistemas de Informacion.pptxSistemas de Informacion.pptx
Sistemas de Informacion.pptxDimas Carpio
 

Similar a Index (20)

Ciclo de vida del desarrollo de sistemas
Ciclo de vida del desarrollo de sistemasCiclo de vida del desarrollo de sistemas
Ciclo de vida del desarrollo de sistemas
 
Inv preliminar,estudio de factibilidad, ciclo de vida pst21
Inv preliminar,estudio de factibilidad, ciclo de vida pst21Inv preliminar,estudio de factibilidad, ciclo de vida pst21
Inv preliminar,estudio de factibilidad, ciclo de vida pst21
 
Analisis de sistemas de informacion
Analisis de sistemas de informacionAnalisis de sistemas de informacion
Analisis de sistemas de informacion
 
Sistemas de informacion
Sistemas de informacionSistemas de informacion
Sistemas de informacion
 
Análisis de Sistemas - 1.pptx
Análisis de Sistemas - 1.pptxAnálisis de Sistemas - 1.pptx
Análisis de Sistemas - 1.pptx
 
Yo rifo lml
Yo rifo lmlYo rifo lml
Yo rifo lml
 
principales actividades de la ingenieria de Requerimientos
principales actividades de la ingenieria de Requerimientosprincipales actividades de la ingenieria de Requerimientos
principales actividades de la ingenieria de Requerimientos
 
Desarrollo de prototipos
Desarrollo de prototiposDesarrollo de prototipos
Desarrollo de prototipos
 
Tipos de requerimeintos
Tipos de requerimeintosTipos de requerimeintos
Tipos de requerimeintos
 
sistemas
sistemassistemas
sistemas
 
Sesion11
Sesion11Sesion11
Sesion11
 
Analisis de sistemas
Analisis de sistemasAnalisis de sistemas
Analisis de sistemas
 
Presentación digital Eliezer Alas
Presentación digital Eliezer AlasPresentación digital Eliezer Alas
Presentación digital Eliezer Alas
 
Ciclo de Vida de Sistemas de Información
Ciclo de Vida de Sistemas de InformaciónCiclo de Vida de Sistemas de Información
Ciclo de Vida de Sistemas de Información
 
Sistemas_de_Informacion.ppt
Sistemas_de_Informacion.pptSistemas_de_Informacion.ppt
Sistemas_de_Informacion.ppt
 
Sesion 07 analisis de sistemas
Sesion 07   analisis de sistemasSesion 07   analisis de sistemas
Sesion 07 analisis de sistemas
 
Rediseño de la Organizacion con Sistemas de Información
Rediseño de la Organizacion con Sistemas de InformaciónRediseño de la Organizacion con Sistemas de Información
Rediseño de la Organizacion con Sistemas de Información
 
Taller en clases
Taller en clasesTaller en clases
Taller en clases
 
Metodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De InformaciónMetodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De Información
 
Sistemas de Informacion.pptx
Sistemas de Informacion.pptxSistemas de Informacion.pptx
Sistemas de Informacion.pptx
 

Index

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