Loading

Module 1: Diseño del sistema

Apuntes
Study Reminders
Support
Text Version

Sistema de autotinta

Set your study reminders

We will email you at these times to remind you to study.
  • Monday

    -

    7am

    +

    Tuesday

    -

    7am

    +

    Wednesday

    -

    7am

    +

    Thursday

    -

    7am

    +

    Friday

    -

    7am

    +

    Saturday

    -

    7am

    +

    Sunday

    -

    7am

    +

Por lo tanto, hoy discutiremos acerca de las estrategias de aceptación y los métodos de estrés de aceptacióny cómo planeamos para la prueba de aceptación y cuáles son los pasos importantes involucrados enlas pruebas de aceptación, cuáles son las cosas a probar y cómo planeamos para su; nosotrosdiscutiremos sobre estos aspectos en la conferencia de hoy.
(Consulte el tiempo de la diapositiva: 01:42)
Por lo tanto, la prueba de aceptación es básicamente la prueba final en la calificación. Como he mencionado, esto esseparado de la validación tal como lo llevan a cabo las partes interesadas y no los ingenieros del sistemay si esto falla, el sistema debe cambiarse. Por lo tanto, si la prueba de aceptación falla entoncesdefinitivamente entonces este sistema tiene que ser cambiado excepto por algunas excepciones; la mayoría de las vecestendremos que cambiar el sistema, porque esto no es aceptable para el cliente.Y el umbral de aceptación necesita ser definido en el principio mismo; por lo tanto, no podemostener un umbral identificado después del diseño del sistema. Por lo tanto, ¿cuáles son los valores de umbral para el diseño de varios sistemaso los aspectos del sistema o el rendimiento del sistema debende la prueba y, o incluso antes del inicio del diseño del sistema,necesitamos garantizar que los umbrales se definen.Por lo tanto, que no haya ambigüedad de los umbrales y no haya cambios en el umbraldespués de que el sistema se haya diseñado o basado en el diseño del sistema real, no podemos cambiarel umbral; por lo tanto, tiene que estar predefinido. Y la prueba de aceptación básicamente se centrará en el uso dede un sistema por un pequeño grupo de personas o un grupo representativo porque esto no eshecho por los ingenieros del sistema, necesitamos tener un grupo de personas que serán los usuariosya que no es posible tener un grupo muy grande de personas probando el sistema, necesitamosidentificar a un pequeño grupo de personas que realmente pueden hacer las pruebas y luego averiguarsi realmente cumple con los requisitos.
Por lo tanto, varios aspectos del sistema utilizado serán probados por este conjunto de personas y, a continuación, sicumple los valores de umbral, se aceptará. Las dos preguntas principales que se hacen aquíes básicamente ¿qué hacer, y cómo probar? Por lo tanto, ¿cuáles son las cosas que deben probarse en la prueba de aceptación dey cómo realizar esta prueba? Por lo tanto, estos son los dos aspectos importantes en las pruebas de aceptación de.(Consulte la hora de la diapositiva: 03:49)
La pregunta de qué probar es la primera; básicamente la respuesta es todo lo posible.Por lo tanto, no hay restricciones en esto, así que cualquiera que sea las cosas que podemos probar; podemos hacer las pruebas deque es todo lo posible que se puede probar. Y la pregunta clave debe ser preguntada oqué debe ser la prueba? ¿Y qué nos olvidamos de probar? Por lo tanto, esto también es muy importante lo quedebemos probar es un aspecto que debemos cuidar en las pruebas, pero máses importante lo que nos olvidamos de probar también es importante.A veces podemos olvidarnos de probar algunos parámetros importantes y eso puede llevar a una fallaen el sistema. Hay muchos estudios de caso que realmente mostraron que algunosde los aspectos fueron probados y exactamente estos parámetros se convirtieron en la causa del fracaso en el sistema. Por lo tanto, tenemos que ver que no sólo es importante que lo que nosotrosestamos probando? Pero, ¿cuáles son las cosas que nos olvidamos de probar? También es muy importante.Por lo tanto, en este caso la prueba de aceptación que sustituyen a los probadores de desarrollo con los usuarios. Por lo tanto,esto ya lo he mencionado; por lo tanto, el desarrollo en los probadores son diferentes de los usuarios y
por lo tanto, y la prueba de aceptación debe ser realizada por los usuarios solamente, esto no lo hacepor los probadores del desarrollo.Así que, esa parte necesita ser cuidado y no es posible tener una repetición exhaustivade la prueba; principalmente porque hay mucha prueba que se va a realizar y hay muchos subsistema, componentes e interfaces. Por lo tanto, no es posible tener una prueba exhaustiva del sistemaen el nivel de aceptación. Así que la mayoría de las veces, tendremos que confiar en la prueba pasadatambién. Por lo tanto, algunos de los datos de la prueba pasada básicamente en la etapa de calificación y otras etapas de integración del subsistema, algunos de los datos de prueba se utilizarán aquí y que mucha de la confianza deen estos datos estará allí durante la prueba de aceptación.Por lo tanto, dependiendo del tipo del sistema y dependiendo de la naturaleza del requisito de prueba, los diseñadores pueden decidir realmente; ¿cuáles son las pruebas importantes que se realizarándurante la aceptación? ¿Y cuáles son los datos que se utilizarán de la prueba anterior?Por lo tanto, eso es importante aquí porque hay muchas cosas por probar. Por lo tanto, es posible que no sea posiblesiempre durante la prueba de aceptación.(Consulte la hora de la diapositiva: 06:07)
Y los resultados de la prueba de aceptación; así que cuando haremos una prueba de aceptación básicamentela idea es ver, si realmente puede cumplir con el requisito de los interesados.Así que, qué tipo de resultados podemos obtener de aquí, después del final de los stakeholders de pruebaen realidad puede aceptar el sistema tal y como es. Por lo tanto, esa es una opción que el sistema puede aceptar
tal como está sin cambios importantes. Por lo tanto, la mayoría de los parámetros son probados yrealmente cumplen con el umbral de aceptación, los interesados pueden aceptar el sistema tal cual es.Pero entonces otra opción es que lo acepten sujeto a ciertos cambios. Por lo tanto, hay pocos cambiosnecesarios en el sistema basados en la prueba de aceptación de pruebas que los interesadospueden sugerir algunos cambios y luego aceptarlo en función de estos cambios. Por lo tanto, en este casose aceptará el sistema, pero pueden solicitar algunos cambios y las partes interesadaspueden empezar a utilizar el sistema, pero los cambios se implementarán más tarde en función de los resultados de la prueba de aceptación de; es una segunda opción.La tercera opción es que acepte; sólo después de cambiar esto, el sistema no se puede aceptaren el estado actual y se considera que son algunos cambios y el sistema sólo puede aceptarsedespués de realizar los cambios. Por lo tanto, en este caso en comparación con el anterior aquí, el sistemano será utilizado por las partes interesadas, esperarán a que se realicen los cambios y luegosólo será aceptado y la última opción no es también excepto.Por lo tanto, los interesados simplemente pueden decir que no está cumpliendo los requisitos y, por lo tanto,no podemos aceptar el sistema y necesita ser rediseñado. Por lo tanto, hay otra opciónaquí, el sistema debe rediseñarse y, a continuación, la prueba de aceptación que se debe repetir y launa vez que se haya calificado después de la prueba de aceptación, sólo será aceptada por los grupos de interés, por lo que estas son las cuatro opciones para los interesados. Por lo tanto, basándose en la prueba de aceptación de, decidirán si aceptan el sistema, ya que no es necesario realizar más cambios en.Por lo tanto, en este caso los interesados pueden empezar a utilizar el sistema sin ningún cambio, pero la segunda opción dees que pedirán algunos cambios o se han encontrado que hay algunospequeños cambios que se deben realizar en la interfaz o en el rendimiento funcional, queson menores y no afectan realmente al rendimiento del sistema.Por lo tanto, en este caso los interesados aceptarán el sistema tal como está con los cambios menores.Por lo tanto, los cambios menores ser intimado a los diseñadores y diseñadores hará las modificaciones dey agregará al sistema existente. Por lo tanto, las partes interesadas empezarán a utilizar el sistemaa pesar de que los cambios menores sean necesarios y de estos cambios menores;vendrá como una versión siguiente o una actualización del sistema existente. El tercero es el sistemaque cumple la mayoría de los requisitos casi que califica en la mayoría de los casos, pero que requieren algunos
los cambios que son muy importantes y el sistema sólo se pueden aceptar después de que se realicen estos cambios.Por lo tanto, en este caso los interesados no saben utilizar el sistema que le pedirán a los diseñadores para quehagan los cambios y luego se lo den por utilizar. Por lo tanto, esa es la tercera opción y la última dees rechazar el sistema, por lo que no califica ninguno de los requisitos o la mayoría de los requisitosno los cumple el sistema. Por lo tanto, en este caso rechazarán el sistema y pedirán a los diseñadores deque rehagan el sistema o rediseñen el sistema.Y luego tiene que pasar por la etapa de integración y calificación y la prueba de calificación, así como la prueba de aceptación para ser repetida y luego será aceptada. Por lo tanto, estasson las diversas opciones para las partes interesadas después de la prueba de aceptación, pero hay algunos casosen los que hay pocas aceptación, donde el sistema se aceptará incluso sihay algún problema con el sistema.(Consulte la hora de la diapositiva: 10:08)
Por lo tanto, estos son los casos especiales que los interesados aceptan el sistema sin una prueba de aceptación positiva completa de. Por lo tanto, aunque el sistema no satisface completamente los requisitos de, los interesados aceptarán el sistema. Esto se debe a que la variante existenteestá causando demasiados problemas, por lo que lo que están teniendo actualmente; está causando demasiados problemasy, por lo tanto, un producto parcialmente mejorado aceptado y liberado con una notapara que el equipo de ingeniería complete la tarea dada rápidamente.
Por lo tanto, aquí lo aceptarán porque la versión anterior o lo que exista enestá causando demasiados problemas. Por lo tanto, quieren tener muchas mejoras enque uno sea aceptable para ellos. Por lo tanto, empezarán a usarlo, pero darán una nota al equipo de diseño depara pedirle que cambie el diseño o que pida mejorarlo. Y el sistema esinaceptable en algunos casos, aunque está cumpliendo con la mayor parte del requisito; no esaceptable porque causa más problemas que el sistema existente.Así que en esa situación es posible que no lo acepten, aunque en realidad cumple con los muchos de los requisitos de. Por lo tanto, si causa más problema que el sistema actual, entonces no seráaceptado y en la mayoría de estas pruebas, harán dos suposiciones y luego seguirán adelantecon las pruebas. Básicamente uno es eso; asumen que es totalmente aceptable oinaceptable. Por lo tanto, si esto se asume es totalmente aceptable entonces la mayor parte de la prueba serádiseñada de tal manera que demuestre que no es aceptable.Así que, usted asume que es inaceptable y luego realiza la prueba para demostrar que, no esaceptable y si esta prueba falla, entonces es aceptable. Del mismo modo, usted asume que esinaceptable y luego lleva a cabo la prueba para probar que es aceptable y si la pruebatiene éxito entonces el sistema será aceptado. Por lo tanto, de esta manera podemos tener dos tipos de suposiciones y pruebas depara llevar a cabo la prueba de aceptación.(Consulte el tiempo de la diapositiva: 12:04)
La siguiente es cómo probar? Por lo tanto, hay varias maneras de probar y varias cosaspara ser probadas y hay diferentes opciones para los interesados después de la prueba. Pero cómo
hacer las pruebas es de nuevo un aspecto importante porque hay varios aspectos a probary cómo llevamos a cabo estas pruebas es importante. Por lo tanto, aquí vemos un aspecto como la usabilidaddel sistema y luego vemos cómo hacer las pruebas de usabilidad.Por lo tanto, las pruebas de usabilidad son para determinar el éxito en el cumplimiento de los requisitos de las partes interesadas.Así que básicamente los requisitos de los interesados; cuánto se satisface, cómo la usabilidad deel sistema por parte de los interesados es satisfecha por el sistema se prueba. Hay cinco aspectosen la prueba de usabilidad; básicamente, se mira la capacidad de aprendizaje del sistema que es el tiempo paradominar un nivel de eficiencia definido.Así que, miramos el sistema y luego vemos cómo el usuario depuede aprender primero o dominar. Tendremos un nivel de eficiencia predefinido y veremos cuánto tiempo tardapara que un usuario alcance ese nivel de eficiencia; ese es el test de aprendizaje. La siguiente es la facilidad de uso de; ahora la facilidad para utilizar el sistema, por lo que aquí el tiempo para que un usuario frecuente completeuna tarea de definición.Por lo tanto, busca el tiempo necesario para que un usuario frecuente complete una tarea definida. Por lo tanto, allíson usuarios con varias capacidades; algunos de ellos son usuarios muy frecuentes, algunos de ellosrara vez utilizan el sistema, algunos de los expertos en el uso del sistema. Por lo tanto, tomamos un usuario de nivel medio de, un usuario frecuente para completar una tarea de definición y averiguar cuánto tiempo tomapara completar una tarea en particular.Así que, eso realmente nos da el uso del sistema y el tercero es memorabilidad del sistema. Así, el tiempo para que un usuario casual logre la tasa de producción previamente alcanzada. Por lo tanto,aquí es un usuario casual no es un usuario frecuente, por lo que se le pedirá que use el sistemay ver cuánto tiempo tarda en alcanzar una tasa de producción previamente alcanzada.Así que, puede estar teniendo cierto nivel de producción usando una versión anterior de un sistema o un sistema similar. Por lo tanto, se le pedirá a este usuario que utilice el sistema y ver qué tan rápidorealmente alcanza la tasa normal de producción y que en realidad nos da el valor de la memorabilidaddel sistema. Y la cuarta es la tasa de error, el número de matrices en un periodo determinado depara una tarea determinada. Por lo tanto, dependiendo del número de errores podemos averiguar¿cuál es la tasa de error del sistema? Y luego, durante un período determinado, para una tarea determinada,intentará averiguar cuántos errores están ocurriendo en el sistema y que realmente da una tasa de errordel sistema.
A continuación, el nivel de satisfacción, el nivel de satisfacción es el nuevo es un poco sujeto,, pero luego es el nivel de estrés o diversión asociado con el usuario. Por lo tanto, básicamente una persona que estáusando el sistema; qué feliz está o qué tan problemático está o qué tan frustrado está; en el uso del sistema. Por lo tanto, esto es una medida de la satisfacción del sistema; por lo tanto, la usabilidaddel sistema se puede probar utilizando estas cinco medidas.Y la última; ese nivel de satisfacción sólo se puede probar cuando el sistema completo está disponible. Por lo tanto, cuando tenemos el sistema completo; podemos hacer la prueba de satisfacción, pero la otra, la prueba se puede completar incluso cuando el sistema completo no está disponible también. Por lo tanto,estos son los cinco niveles de pruebas de usabilidad y en realidad podemos tomar estos parámetros ymedir sus valores y ver qué tan utilizable es el sistema y cuáles son los obstáculosbásicamente allí en las pruebas de usabilidad.(Consulte el tiempo de la diapositiva: 15:34)
Aunque hay un factor emitido, hay algún problema en llevar a cabo las pruebas de usabilidad. Por lo tanto, estos son básicamente el primero es, por supuesto, conseguir los participantes de la prueba; ¿Quiénel usuario real? Por lo tanto, tenemos que tener un conjunto de usuarios para hacer las pruebas, pero entoncespuede no ser siempre fácil encontrar a los usuarios o a los usuarios de prueba el número suficiente de usuarios de pruebaque realmente pueden participar en las pruebas del sistema. Por lo tanto, eso realmente da un problema dey necesitamos asegurarnos de que quiénes estamos seleccionando para la prueba del sistema;representan a los usuarios reales o existe la posibilidad de que utilicen o haya un potencial paraestas personas que utilizan el sistema.
Por lo tanto, sólo habrá alguna validez para la prueba. Por lo tanto, conseguir que estas personas seandifíciles porque encontrarlas para las pruebas o conseguir que las pruebas lleguen ala instalación de prueba y hacer la prueba puede no ser siempre posible. Por lo tanto, ese es uno de los problemas deen hacer la prueba de usabilidad y luego obtener una muestra representativa de cómo la población deevaluará el sistema; es decir, necesitamos tener un grupo de personas, queen realidad puede evaluar el sistema usando una persona o unos cuantos números pueden no sersuficientes porque necesitamos obtener una muestra representativa de cómo la poblaciónevaluará el sistema.Puede haber varias secciones de personas usando el sistema; puede haber un sistema, puede ser utilizadoadultos o puede ser niños o personas discapacitadas físicamente o personas de edad avanzada. Por lo tanto, necesitamos obtener una muestra representativa de todas estas personas para evaluar el sistemaque también podría ser una tarea difícil. A continuación, seleccione las tareas más críticas para las necesidades de, por lo que, como he mencionado, tenemos que ver la tarea; que son necesarias para que los usuarios deprueben la tarea, pero entonces es importante seleccionar la tarea más crítica para las necesidades de usabilidad.Por lo tanto, los diseñadores necesitan analizar toda la tarea y luego ver cuáles son la tarea más críticay, por consiguiente, necesitan hacer las pruebas. Y, a continuación, escribir los casos de ejemplo de prueba querepresenta con precisión la situación real. Por lo tanto, es necesario definir correctamente los escenarios y escribirpara que se pueda realizar toda la prueba en función de estos casos de ejemplo. Por lo tanto, escribir estos escenariostambién; un gran reto y predecir qué interfaz de usuario es más crítica. Así queesto de nuevo es difícil de predecir inicialmente porque dependiendo del uso y que dependiendode las personas que están utilizando, por lo que algunos de la interfaz tal vez crítico, entonces muchos noser críticos.Así que, identificar esta interfaz crítica también un desafío, por lo que estos son los principales obstáculos enhacer las pruebas. Por lo tanto, tenemos que asegurarnos de que cada vez que hacemos una prueba de usabilidad,necesita asegurarse de que tenemos un representante, una muestra de la población que utiliza el sistemay tenemos los escenarios identificados correctamente y tenemos las interfaces de usuario críticasidentificadas y escribimos los escenarios y para probar y cuáles son las tareas importantes deque se deben probar.Por lo tanto, todas estas necesitan ser analizadas y registradas correctamente para asegurarse de que hacemos una pruebaadecuada y que esos ensayos son realmente importantes. Y estos valores de prueba realmente representanla aceptación del sistema por parte del usuario. Por lo tanto, aunque estos retos en la usabilidad
es necesario identificar las etapas iniciales y las medidas que se deben tomar para superar estas dificultades; de modo que se trata de los obstáculos en las pruebas de usabilidad.(Consulte la hora de la diapositiva: 19:12)
Por lo tanto, como he mencionado estas son las diversas etapas en la prueba de aceptación. Por lo tanto, tenemos queidentificar los escenarios de prueba, necesitamos identificar los escenarios de prueba, así como necesitamosidentificar la tarea que se va a probar y muchas de las pruebas que se han probado que las pruebas de usabilidad.¿Cómo hacemos las pruebas de usabilidad? Por lo tanto, aquí voy a tomar dos estudios de caso para mostrar que la importancia dees la prueba de prueba y aceptación en la calificación del sistema. Discutimossobre el caso de la falla de THERAC 25, pero esto era un médico, un dispositivo; una máquina de terapia de radiación controlada por computadoray desarrollada para dar radiación controlada a los pacientes dey luego en el período de 1985 a 87; 3 pacientes fueron muertos por radiaciónsobredosis y aunque se suponía que la máquina protegía a estos pacientes, fueron asesinadosdebido a las sobredosis en radiación.Por lo tanto, la razón de esto fue que los cuatro operadores diferentes entraron en un aceptable, pero enla secuencia de comandos utilizada con frecuencia. Por lo tanto, la razón de la sobredosis fue básicamente el usodel sistema por parte de varios operadores. Por lo tanto, cuatro operadores diferentes entraron en un aceptable,pero en la secuencia de comandos utilizada con frecuencia y que realmente condujo a la sobredosis yestos errores pueden ser rastreados al análisis de requisitos y defectos de diseño.Así que, cuando empezamos el diseño del sistema fue; como mencioné anteriormente, necesitamosidentificar el requisito correctamente y luego grabarlos. Por lo tanto, se ha producido un error en
al identificar el requisito, no se ha identificado el requisito adecuado. ¿Cuál es la condición debajo la que se deben especificar estos parámetros? ¿Y cuál es la secuencia enque hay que introducir? Esas cosas no estaban debidamente identificadas y el sistema de clasificación diseñado correctamente porpodría haber detectado estos defectos.Por lo tanto, aunque hubo errores al principio en la etapa de análisis o en la etapa de análisis del requisito, si teníamos un sistema de calificación diseñado correctamente entonces estos flujos podríansido adjudicados o se podría haber detectado en la etapa inicial o antes de queimplementara la máquina o antes del despliegue de la máquina, podríamos haber identificadoestas fallas. Por lo tanto, no se llevaron a cabo los ensayos adecuados; donde podemos identificarestos requisitos o estos escenarios.Por lo tanto, los escenarios operativos como el; en el escenario utilizado con frecuencia podrían haberse simuladoy se podrían haber llevado a cabo las pruebas para averiguar qué es lo que realmente, lo que serála salida y luego se podrían haber identificado los errores y luego se podría haber rectificado. Por lo tanto, ese fue el problema realmente lo que realmente causó la muerte trágica de muchos pacientes dedebido a una sobredosis.Por lo tanto, este fue un caso claro donde toda la secuencia de entrada de datos posible debería haber probado. Por lo tanto,esto realmente muestra la importancia de las pruebas de aceptación. Por lo tanto, si toda la posible entrada de datosse debe haber probado para asegurarse de que no puede haber error en la entrada de datosy que puede hacer que el sistema vea algunos errores. Por lo tanto, esto realmente muestra ala importancia de la prueba de aceptación e identificar todos los escenarios de prueba y estees un caso de estudio que es el otro de nuevo de los accidentes industriales o las fallas de.
(Consulte la hora de la diapositiva: 22:39)
La falla ARIANE 5, discutimos sobre esto en una de las conferencias. Por lo tanto, ARIANE 5fue el vehículo de lanzamiento desarrollado por la agencia espacial europea, que causó alrededor de 500 millones37 segundos en su vuelo ARIANE 5 se salió del curso yse desintegró en breve.De nuevo la falla fue rastreada a dos sistemas de referencia inercial, uno de los cuales estaba en calienteen espera, prestamos sobre el sistema en espera que básicamente es un sistema tolerante a la caída. Por lo tanto,había dos sistemas de referencia iniciales; uno de los cuales estaba en espera activa, por lo que incluso sifalla, el otro puede ser utilizado para obtener la salida del sistema y luego puede averiguarla ubicación del sistema en el vehículo.Ambos SRI ’ s fallaron cuando su software convirtió 64 bits de coma flotante en un número entero de 16 bits. Por lo tanto, esta fue la causa básica para el fracaso hubo una conversión de un número de punto flotante de 64 bitsa un entero con signo de 16 bits que no estaba planeado en el sistemao nunca esperaban este tipo de conversación. Y como se ha convertido en estey el sistema no ha podido aceptar, la interfaz no ha podido aceptar los datos y, por lo tanto,se ha producido un error.Ahora, durante la etapa de diseño se han identificado siete variables que podrían causar un error de operando. Por lo tanto, en las etapas iniciales del diseño, los ingenieros de diseño han identificado siete variablesque en realidad pueden causar este tipo de problema e identificaron cuatro de. Por lo tanto, se tomó una decisión deliberada para proteger las SRI de cuatro de estas variables; por lo tanto,
de los siete, identificaron cuatro variables y tomaron las medidas necesarias paraproteger el sistema o el SRI ’ s de este problema. Y cuatro de ellos han sido protegidosy se supone que los otros tres tienen un gran margen de seguridad.Por lo tanto, de nuevo ellos para tomar una decisión aquí diciendo que hay una posibilidad de quetresen esto hay como resultado un error de operando es muy remoto y entonces se decidenpara no protegerlos contra estas tres variables y no se hizo ninguna prueba en SRI aexaminar el escenario operativo asociado con la cuenta regresiva y la trayectoria. Por lo tanto, elSRI ’ s es el básicamente utilizado durante la etapa inicial del vuelo. Por lo tanto, no hicieron ninguna prueba de aceptación depara ver si este tipo de escenario se generará o no.Por lo tanto, dado que han identificado tres parámetros o tres variables que en realidad puedencausar un error de oponente, podrían haber probado estas condiciones para asegurarse de que estono cause un problema. Pero por desgracia, exactamente una de estas variables resultó en un error de operando dey eso realmente causó el problema en todo el lanzamiento, el vehículo fuedestruido por ese simple problema y más tarde cuando cambiaron ese y luegoidentificaron la razón de la falla, pudieron rectificarlo muy fácilmente y luego solucionaron el problema de.Pero si hubo una prueba adecuada que realmente examinó el escenario en particular, dondeestas tres variables pueden resultar en un error de operando; entonces este fracaso podría haber sido eliminado. Por lo tanto, esto muestra de nuevo la importancia de una prueba de aceptación en el sistema yidentificando todos los posibles escenarios de desarrollo de un error. Y luego asegurarse de quela prueba de aceptación en realidad aseguró que tales errores no sucedieran y realmentecalifica a través de esta prueba de aceptación. Por lo tanto, una vez que esté calificado, el sistema está preparado para el despliegue de.
(Consulte la hora de la diapositiva: 26:20)
Por lo tanto, en las últimas tres conferencias discutimos sobre la integración del sistema y la calificacióny aquí mencionamos que, tenemos varias etapas en la integración del sistema. Por lo tanto,se inicia con los subsistemas y luego los componentes y, a continuación, el subsistema. A continuación, las interfaces, lasempiezan a integrarlas y hay diferentes métodos de integración, el sistema que esbásicamente, el enfoque de abajo hacia arriba, el enfoque de arriba hacia abajo, luego el enfoque de big bang; por lo quepodemos utilizar cualquiera de estos métodos para integrar el sistema.Del mismo modo, discutimos acerca de las estrategias de calificación básicamente la validación, verificación y aceptación de. Por lo tanto, la validación y la verificación se llevan a cabo básicamente porlos diseñadores del sistema y la prueba de aceptación es llevada a cabo básicamente por los usuarios con la ayuda dede los diseñadores. Por lo tanto, los diseñadores identificarán la tarea que se va a probar y los escenariosque se probarán y a continuación se les pedirá a los usuarios que los prueben y, a continuación, se basen en el; para el valor de umbral determinado de, el sistema se aceptará.Por lo tanto, los usuarios tienen opciones diferentes; después de probar que realmente pueden aceptar el sistema opueden aceptarlo con algunos cambios o pueden rechazar el sistema. En algunos casos yalgunos casos especiales, los usuarios se verán obligados a aceptar el sistema incluso si hay algunos errores deporque el sistema existente está dando muchos problemas. Por lo tanto, quieren evitar estos problemas dey luego continuar; quieren un nuevo sistema, sólo para escapar de los errores dedel sistema anterior. Estas son las opciones para los usuarios y luego discutimos
acerca de los procedimientos de prueba de aceptación en los procedimientos de prueba de usabilidad. Y luegovimos pocos estudios de caso, donde las fallas en la prueba de aceptación causaron la falla del sistema.Por lo tanto, estos fueron los temas que discutimos en las últimas tres conferencias y como mencioné en las conferencias anteriores de, así que este es el último paso en el proceso de diseño que las seis funciones del proceso de diseño de. Por lo tanto, si completamos estos en realidad para cada ciclo de vida, tenemos quecompletar estas seis funciones del proceso de diseño. En las próximas conferencias, vamos adiscutir sobre algunos temas complementarios que son realmente útiles en el diseño del sistema. Por lo tanto,antes de ir a los temas complementarios; voy a tomar pocos estudios de caso o pocos ejemplos de diseño de sistemapara mostrarles; cómo utilizar realmente los principios, lo que aprendimosen un escenario real o un escenario de diseño de sistema real y cómo ir de una manera sistemática dediseñando el sistema.Por lo tanto, voy a realizar tres estudios de caso y explicar el procedimiento y no vamos a entrar enlos detalles de todas y cada una de las etapas, pero voy a dar una visión general de cómo se pueden utilizar los principios deen el diseño del sistema.(Consulte la hora de la diapositiva: 29:04)
Y después de eso, vamos a ir a los otros temas complementarios como modelado gráficoy métodos de modelado, análisis de decisiones; herramientas de toma de decisiones y análisis de decisiones.Entonces vamos a ver la fiabilidad del sistema; cómo diseñan el sistema para la fiabilidad de. Del mismo modo, ¿cómo evitar las fallas en el sistema? ¿Cómo incorporar el análisis de errores deen el diseño del sistema? Y de forma similar, nos fijamos en algunas de las estadísticas
herramientas que se pueden utilizar en el diseño del sistema como el diseño de experimentos y otros métodos de.Para empezar, vamos a buscar los ejemplos de diseño del sistema; ahora voy a tomar algunos ejemplosaquí y luego explicar el procedimiento de un diseño de sistema utilizando los principios de ingeniería dedel sistema estándar.(Consulte la hora de la diapositiva: 29:53)
Por lo tanto, este es el primer ejemplo para el diseño del sistema.(Consulte la hora de la diapositiva: 29:57)
Tomaremos el caso de un sistema de enlace automático, mencioné al respecto en una de las conferencias anteriores demientras explicaba una de las descomposición funcional. Voy a explicar acerca del sistema de enlace automático, así que vamos a ver en el detalle de este sistema y luego cómo realmenteempezar con el diseño del sistema, con los procedimientos o los métodos que ya hemos discutido.El sistema de enlace automático es un sistema de información para los conductores para asistirlos en la navegación y situaciones de emergencia de. Por lo tanto, en realidad estamos tratando de diseñar un sistema que en realidad puede serutilizado por los conductores o pasajeros en un coche o cualquier otro vehículo en una situación de emergenciao para obtener alguna otra información sobre los aspectos de navegación.Por lo tanto, si alguien está conduciendo en una carretera o viajando en un largo