EEE 24765

examen de ingreso

1. La prueba de un sistema o unidad funcional realizado generalmente por el comprador en su establecimiento después de la instalación

con la participación del distribuidor para asegurarse de que se cumplen los requisitos contractuales. ISO / IEC

2382-20: 1990, Tecnología de la información - Vocabulario - Parte 20: Desarrollo de sistemas 20.05.07..

cf. las pruebas de aceptación, pruebas de validación

test de aceptación

1. pruebas realizadas para determinar si un sistema cumple con sus criterios de aceptación y con objeto de

al cliente para determinar si acepta el sistema. IEEE Std 829-2008 Norma IEEE para Software y

Documentación Prueba del sistema 3.1.1 Syn:.. Las pruebas de validación, prueba de aceptación 2. pruebas formales realizado a.

permitir a un usuario, cliente, u otra entidad autorizada para determinar si se acepta un sistema o componente.

IEEE Std 829-2008 Norma IEEE para software y la documentación de prueba del sistema. 3.1.1.

cf. las pruebas de validación, prueba de aceptación

acceso

1. para obtener el uso de un recurso. / IEC 2382-1 ISO: 1993, Tecnología de la información - Vocabulario - Parte 1:

01.01.04 términos fundamentales.

Se trata de una muestra de 12 páginas libre. Accede a la versión completa en línea. 

IEEE/IEC 27002:2005

ISO / IEC 27002: 2005 comprende la norma ISO / IEC 17799: 2005 e ISO / IEC 17799: 2005 / Cor.1: 2007. Su contenido técnico es idéntica a la de la norma ISO / IEC 17799: 2005. ISO / IEC 17799: 2005 / Cor.1: 2007 cambia el número de referencia del estándar a partir de 17799 a la 27002.

ISO / IEC 27002: 2005 establece las directrices y principios generales para iniciar, implementar, mantener y mejorar la gestión de seguridad de la información en una organización. Los objetivos descritos proporcionan una guía general sobre las metas comúnmente aceptadas de gestión de seguridad de la información. ISO / IEC 27002: 2005 contiene las mejores prácticas de los objetivos de control y controles en las siguientes áreas de gestión de seguridad de la información:
•política de seguridad;
• organización de seguridad de la información;
•gestión de activos;
• Seguridad de los recursos humanos;
• física y la seguridad del medio ambiente;
• comunicaciones y gestión de operaciones;
•control de acceso;
• sistemas de información de la adquisición, desarrollo y mantenimiento;
• Gestión de la información de seguridad incidente;
• Gestión de la continuidad del negocio;
•conformidad.

Los objetivos de control y controles de la norma ISO / IEC 27002: 2005 están destinadas a ejecutarse para satisfacer los requisitos identificados por una evaluación del riesgo. ISO / IEC 27002: 2005 pretende ser una base común y guía práctica para el desarrollo de estándares de seguridad de la organización y las prácticas eficaces de gestión de la seguridad, y para ayudar a construir la confianza en las actividades ínter-nacionalizarles.

ISO / IEC 27002: 2005 comprende la norma ISO / IEC 17799: 2005 e ISO / IEC 17799: 2005 / Cor.1: 2007. Su contenido técnico es idéntica a la de la norma ISO / IEC 17799: 2005. ISO / IEC 17799: 2005 / Cor.1: 2007 cambia el número de referencia del estándar a partir de 17799 a la 27002.

• sistemas de información de la adquisición, desarrollo y mantenimiento;
• Gestión de la información de seguridad incidente;
• Gestión de la continuidad del negocio;
•conformidad.

 

---

IEEE 1012

En todo momento durante el desarrollo del software. En las metodologías ágiles se aplica en todo durante el proceso de desarrollo de un producto funcional, mientras que en las metodologías robustas se aplica después de terminar el desarrollo actual.
¿Qué es?
El estándar IEEE 1012-2004 para la verificación y validación de software es un procedimiento organizado y estandarizado basado en normas de calidad el cual es aplicado en alguno modelos del ciclo de vida del software.
¿Dónde se aplica?
Se aplica al software adquirido, desarrollado, mantenido o modificado. Se integra al proceso de ciclo de vida del software en cada una de sus fases y procesos.

Validación: ¿Estamos construyendo el producto correcto? Se ocupa de controlar si el producto satisface los r
Mejorar la visión de la gestión de riesgos.IEEE 1012 - Verificación y Validación de Software

Objetivos de IEEE 1012
Procesos en los que interviene V&V
1. Proceso de Gestión
2. Proceso de Adquisición
3. Proceso de Suministro
Técnicas para aplicar V&V
Técnicas de control dinámicas.
También conocidas como
testing

IEEE 1016

)titulada Norma IEEE sobre Tecnología de la Información-Sistemas-Design Software Descripción Diseño, es un IEEE estándar que especifica "el contenido de la información requerida y la organización" para un SDD. IEEE 1016 no especifica el medio de un SDD; es "aplicable a las bases de datos automatizadas y descripción del diseño idiomas, pero puede ser utilizado para documentos de papel y otros medios de descripciones.IEEE 1471 

IEEE 1471

IEEE 1471 es un sustituida Norma IEEE para describir la arquitectura de un "sistema de software intensivo", también conocida como arquitectura de software .
En 2011 fue reemplazado por ISO / IEC / IEEE 42010: 2011 , Sistemas e ingeniería de software - Descripción Arquitectura.

Información general

IEEE 1471 es el nombre abreviado de un estándar conocido formalmente como ANSI / IEEE 1471-2000, Práctica Recomendada para Arquitectura Descripción del Software Systems-intensivo. Dentro Instituto de Ingenieros Eléctricos y Electrónicos jerga (IEEE), se trata de una "práctica recomendada", lo más mínimo normativa de sus normas. En 2007 esta norma fue adoptada por la norma ISO / IEC JTC 1 / SC7 como ISO / IEC 42010: 2007 ., Sistemas e Ingeniería de Software - Práctica recomendada para la descripción arquitectónica de los sistemas intensivos en software [1]
Durante mucho tiempo se ha reconocido [ por quién? ] Que "la arquitectura" tiene una fuerte influencia sobre el ciclo de vida de un sistema. Sin embargo, hasta hace relativamente poco, [ cuando? ] Problemas de hardware han tendido a dominar el pensamiento arquitectónico, y los aspectos de software, cuando se considera en absoluto, eran a menudo los primeros en ser comprometida bajo las presiones del desarrollo. IEEE 1471 fue creado para proporcionar una base para pensar acerca de la arquitectura de los sistemas intensivos en software.
Las contribuciones de IEEE 1471 pueden resumirse de la siguiente manera (en esta lista, los elementos en cursiva son términos definidos por y utilizados en la norma):

• Proporciona definiciones y un meta-modelo para la descripción de la arquitectura
• Afirma que una arquitectura debería tratar de un sistema de grupos de interés preocupaciones
• Se afirma que la descripción de la arquitectura s son inherentemente múltiples vistas , sin vistas solo capta adecuadamente todas las preocupaciones de los interesados
• Se especifican las nociones de vista y el punto de vista , donde un punto de vista identifica el conjunto de las preocupaciones y las representaciones / técnicas de modelado, etc. utilizados para describir la arquitectura de abordar estas preocupaciones y una vista es el resultado de aplicar un punto de vista de un sistema en particular.
• Establece requisitos de contenido para las descripciones de la arquitectura y la idea de que una descripción de la arquitectura conformando tiene una correspondencia 1 a 1 entre sus puntos de vista y sus opiniones.
• Proporciona una guía para la captura de la arquitectura lógica y la identificación de inconsistencias / problemas no resueltos entre los puntos de vista dentro de una descripción de la arquitectura IEEE 1471 proporciona anexos informativos que se relacionan con sus conceptos de arquitectura conceptos ito en otras normas, incluyendo RM-ODP y IEEE 12207

 

IEEE/ISO/IEC 24765

 

IAAMI/ISO 13485

La norma especifica de calidad para productos sanitarios es la ISO 13485. La edición actual es la 1 del año 2003 y tiene 69 páginas en su versión española.

En México se publicó en el diario oficial de fecha 11 de octubre de 2012 la NOM 241- SSA1- 2012, Buenas Prácticas de Fabricación para establecimientos dedicados a la fabricación de productos sanitarios. Esta entra en vigor 180 días posteriores a su publicación. El campo de aplicación es de observancia obligatoria en el territorio nacional, para todos los establecimientos dedicados al proceso de productos sanitarios comercializados en el país. La Cofepris es el órgano asignado para su control, verificación y para otorgar los registros de cumplimiento a las empresas que implementan esta norma de Buenas Prácticas de Fabricación. Esta norma concuerda parcialmente con la ISO 13485:2003 y la ISO 9001:2008.

Los productos sanitarios son aquellos utilizados en la práctica médica y que cumplen la definición establecida por las reglamentaciones nacionales. Algunos ejemplos son los equipos electro médicos, los implantes, las prótesis y los kits de diagnóstico clínico.

Esta norma adoptada por el CEN como EN ISO 13485:2003/AC:2007 está armonizada con respecto a las directivas de producto sanitario europeas 93/42/EEC, 90/385/EEC y 98/79/EC. 

Esta norma internacional especifica los requisitos para un sistema de gestión de la calidad que puede ser utilizado por una organización para el diseño y desarrollo, producción, instalación y servicio de productos sanitarios, y el diseño, desarrollo, y prestación de servicios relacionados.

Así pues pueden certificarse organizaciones tales como:

• Fabricantes de productos sanitarios
• Distribuidores de productos sanitarios
• Servicios de asistencia técnica productos sanitarios
• Servicios de Electro medicina - Ingeniería Clínica del Hospital
• Centrales de Esterilización del Hospital

Puede también ser utilizada por partes internas y externas, incluyendo organismos de certificación, para evaluar la capacidad de la organización para cumplir los requisitos reglamentarios y del cliente.

IEEE 730

5- 730-2014 - Norma IEEE para los procesos de software de garantía de calidad.

Conocer la norma IEEE 830 Aprender a formular especificaciones de software Escribir especificaciones de software que Indiquen exactamente lo que desea el cliente

Permitan al proveedor entender exactamente lo que quiere el cliente Aprender a establecer las bases de acuerdo entre cliente y proveedor sobre lo que debe hacer un determinado software Aprender a elaborar una línea base para validación y verificación

Proveedor:

Persona(s) que produce(n) un producto para un cliente

Usuario:

Persona(s) que operan o actúan recíprocamente directamente con el producto.

El(los) usuario(s) y el(los) cliente(s) a menudo no son la(s) misma(s) persona(s)

IEEE 830

Las características de una buena ERS son definidas por el estándar IEEE 830-1998. Una buena ERS debe ser:

• Completa. Todos los requerimientos deben estar reflejados en ella y todas las referencias deben estar definidas.
• Consistente. Debe ser coherente con los propios requerimientos y también con otros documentos de especificación.
• Inequívoca. La redacción debe ser clara de modo que no se pueda mal interpretar.
• Correcta. El software debe cumplir con los requisitos de la especificación.
• Trazable. Se refiere a la posibilidad de verificar la historia, ubicación o aplicación de un ítem a través de su identificación almacenada y documentada.
• Priorizable. Los requisitos deben poder organizarse jerárquicamente según su relevancia para el negocio y clasificándolos en esenciales, condicionales y opcionales.
• Modificable. Aunque todo requerimiento es modificable, se refiere a que debe ser fácilmente modificable.
• Verificable. Debe existir un método finito sin costo para poder probarlo.

Tipos de requisitos

Existen varios tipos de requisitos como lo son:

• Requisitos de Usuarios: Necesidades que los usuarios expresan verbalmente
• Requisitos del Sistema: Son los componentes que el sistema debe tener para realizar determinadas tareas
• Requisitos Funcionales: Servicios que el sistema debe proporcionar
• Requisitos no funcionales: Restricciones que afectaran al sistema

  IEEE 1012

ISSO/IEC 42010:2007

ISO/ IEC 42010: 2007 se ocupa de las actividades de la creación, el análisis y el mantenimiento de las arquitecturas de sistemas intensivos en software, y el registro de este tipo de arquitecturas en términos de descripciones arquitectónicas. ISO / IEC 42010: 2007 establece un marco conceptual para la descripción arquitectónica y define el contenido de una descripción arquitectónica. Anexos proporcionan el fundamento de los conceptos clave y la terminología, las relaciones con otras normas y ejemplos de uso.

ISO/IEC 12207:2008

ISO / IEC 12207: 2008 establece un marco común para los procesos del ciclo de vida del software, con la terminología bien definida, que puede ser diferenciado por la industria del software. Contiene los procesos, actividades y tareas que se van a aplicar durante la adquisición de un producto de software o servicio y durante el suministro, desarrollo, operación, mantenimiento y eliminación de productos de software. El software incluye la parte de software de firmware.

ISO / IEC 12207: 2008 se aplica a la adquisición de sistemas y productos de software y servicios, con el suministro, desarrollo, operación, mantenimiento y eliminación de productos de software y la parte de software de un sistema, bien sea interna o externamente a una organización. se incluyen aquellos aspectos de la definición del sistema necesario para proporcionar el contexto para los productos y servicios de software.

ISO / IEC 12207: 2008 también proporciona un procedimiento que puede ser empleado para definir, controlar y mejorar los procesos del ciclo de vida del software.

AAMI/ISO 13485