You are on page 1of 85

Proyecto de Informacin Federal

Normas de procesamiento de publicacin 183


1993 21 de de diciembre de
Al anunciar la Norma para
DEFINICIN DE INTEGRACIN DE FUNCIN
Modelado (IDEF0)
Procesamiento de Informacin Normas Publicaciones FIPS (Federal
pubs) son emitidas por la Nacional Instituto de Estndares y
Tecnologa despus de la aprobacin por el Secretario de Comercio de
conformidad con Seccin 111 (d) de la Ley de Propiedad Federal y
Servicios de administracin, de 1949, modificada por la Ley de
Seguridad del ordenador, de 1987, Ley Pblica 100-235.
1. Nombre de la norma. Integracin Definicin de Modelado de
funciones (IDEF0).
2. Categora de la norma. El software estndar, Tcnicas de
modelacin.
3. Explicacin. Esta publicacin anuncia la aprobacin de la
Integracin Definicin
Modelado de la funcin (IDEF0) como Federal Information Processing
Standard (FIPS). Esta norma se basa en la Fuerza Area Wright
Aeronutica
Laboratorios
integrado
asistido
por
ordenador
Manufactura (ICAM) Arquitectura, Parte II, Volumen IV - Manual de
funciones de modelado (IDEF0),06 1981.
Esta norma describe el lenguaje de modelado IDEF0 (semntica y
sintaxis), y normas y tcnicas asociadas, para el desarrollo de
representaciones grficas de un sistema estructurado o de la
empresa. El uso de este estndar permite la construccin de modelos
que comprenden el sistema funciones (actividades, acciones,
procesos, operaciones), relaciones funcionales, y los datos
(informacin u objetos) que apoyan la integracin de sistemas.
Esta norma es la autoridad de referencia para su uso por el sistema o
empresa requiere modeladores utilizar la tcnica de modelado IDEF0,
por los ejecutores en el desarrollo de herramientas para la
implementacin esta tcnica, y por otros profesionales de la
informtica en la comprensin de la sintctica precisa y reglas
semnticas de la norma.
4. La aprobacin de la Autoridad.
Secretario de Comercio.
5. Agencia de Mantenimiento.
Departamento de Comercio, Instituto Nacional de Estndares y
Tecnologa, Laboratorio de Sistemas Informticos.
6. ndice de Cross.
a. Arquitectura ICAM-Parte II Volumen IV - Manual de funciones de
modelado (IDEF0), AFWAL-TR-81-4023, Laboratorio de Materiales, de
la Fuerza Area Wright Aeronutica laboratorios, Aire Fuerza Comando
de Sistemas, Wright-Patterson Air Force Base, Ohio 45433, junio 1981.
7. Documentos relacionados.

a. Federal de Informacin de Recursos Reglamento de Gestin


Subparte 201.20.303, Normas y Subparte 201.39.1002, las normas
federales.
Sistema de Soporte Integrado de Informacin (IISS), Volumen V Modelo de Datos Comn Subsistema, Parte 4 - Manual de Modelado
de Informacin - IDEF1 Extended, diciembre de 1985.
ICAM Arquitectura Parte II, Volumen V - Manual de Modelado de
Informacin (IDEF1),AFWAL-TR-81-4023, Laboratorio de Materiales, de
la Fuerza Area Wright Aeronutica laboratorios, Aire Fuerza Comando
de Sistemas, Wright-Patterson Air Force Base, Ohio 45433, junio 1981.
Gestin de la Configuracin ICAM, Volumen II - Normas para la
documentacin ICAM
Metodologa para el desarrollo de sistemas (SDM), AFWAL-TR-82-4157,
Air sistemas de la fuerzaBase de comandos, Wright-Patterson de la
Fuerza Area, Ohio 45433, octubre de 1983.
8. Objetivos Los objetivos principales de esta norma son:
a. Para proporcionar un medio para modelar completamente y
consistentemente las funciones (actividades, acciones, procesos,
operaciones) requeridos por un sistema o de la empresa, y lo
funcional las relaciones y los datos (informacin u objetos) que
apoyan la integracin de las personas funciones; segundo. Para
proporcionar una tcnica de modelado que es independiente de
Software Asistida por Ordenador Ingeniera (CASE) mtodos o
herramientas, pero que se pueden utilizar conjuntamente con las
mtodos o herramientas;
Para proporcionar una tcnica de modelado que tiene las siguientes
caractersticas:
- Genrico (para el anlisis de los sistemas de distinta finalidad, el
alcance y la complejidad);
- Riguroso y preciso (para la produccin de los modelos correctos,
utilizables);
- Conciso (para facilitar la comprensin, la comunicacin, el consenso
y validacin);
- Conceptual (para la representacin de los requisitos funcionales ms
que fsica o implementaciones de organizacin);
- Flexible (para apoyar varias fases del ciclo de vida de un proyecto).
9. Aplicabilidad.
El uso de este estndar es muy recomendable para los proyectos que:
a. Requerir una tcnica de modelado para el anlisis, desarrollo,
reingeniera, la integracin, o la adquisicin de sistemas de
informacin; segundo. Incorporar una tcnica de modelado de
sistemas o de la empresa en un anlisis de procesos de negocio o la
metodologa de la ingeniera de software.
Las especificaciones de esta norma son aplicables cuando el sistema
de modelado o tcnicas de la empresa se aplican a lo siguiente:
a. Los proyectos que requieren IDEF0 como la tcnica de modelado;
segundo. Desarrollo de herramientas de software automatizado de
aplicacin del modelado IDEF0 tcnica.

Las especificaciones de este estndar no son aplicables a los


proyectos que requieren una funcin de modelado tcnica distinta de
IDEF0.
Caractersticas no estndar de la tcnica IDEF0 se deben utilizar slo
cuando la necesita operacin o funcin que no pueden
razonablemente ser ejecutadas con las caractersticas estndar
solamente.
Aunque las caractersticas no estndar pueden ser muy tiles, se
debe reconocer que el uso de estos o cualesquiera otros elementos
no estndar pueden hacer que la integracin de los modelos ms
difcil y costoso.
10. Presupuesto.
Esta norma adopta la definicin de integracin para la funcin
Modelado (IDEF0) como Federal Information Processing Standard
(FIPS).
11. Implementacin.
La aplicacin de esta norma implica dos reas de consideracin:
adquisicin de las implementaciones y la interpretacin de la norma.
11.1 Adquisicin de IDEF0 Implementaciones.
Esta publicacin (FIPS 183) es a partir del 30 de junio de 1994. Para
las adquisiciones federales despus de esta fecha, los proyectos que
utilizan el IDEF0 tcnica de modelado de funcin o software que
implementa la tcnica de modelado IDEF0, debe conforme a la norma
FIPS 183. La conformidad con esta norma se debe considerar si el
proyecto o software utilizando la
tcnica de modelado IDEF0 se
adquiere como parte de un sistema de ADP adquisiciones, adquirida
por la adquisicin por separado, que se utiliza en virtud de un
contrato de arrendamiento de ADP, o especificado para su uso en los
contratos de servicios de programacin.
Un perodo de transicin proporciona tiempo para que la industria
desarrolle productos que se ajusten a esta estndar. El perodo de
transicin comienza en la fecha efectiva y se prolonga durante un (1)
ao despus de eso. Las disposiciones de la presente publicacin se
aplican a los pedidos realizados despus de la fecha de la presente
publicacin; sin embargo, la utilizacin de una tcnica de modelado
de funcin que no se ajusta a esta estndar puede ser permitida
durante el perodo de transicin.
11.2 La interpretacin de esta FIPS.
NIST contempla la resolucin de cuestiones con respecto a la
aplicacin y la aplicabilidad de esta FIPS. Todas las cuestiones
relativas a la interpretacin de esta norma debe ser dirigida a:
Director del Laboratorio de Sistemas de Computacin
Atencin: FIPS IDEF0 Interpretacin
Instituto Nacional de Estndares y Tecnologa Gaithersburg, MD 20899
12 Dispensas.
Bajo ciertas circunstancias excepcionales, los jefes de los
departamentos federales y las agencias pueden aprobar las renuncias
a las Normas Federales de Procesamiento de Informacin (FIPS). Los
jefe de esos organismos puede redelegate dicha autoridad slo a un

alto funcionario designado de conformidad a la seccin 3506 (b) del


Ttulo 44, Cdigo de Estados Unidos. Solicitudes de exencin slo se
conceder cuando:
a. El cumplimiento de una norma afectara adversamente
theaccomplishment de la misin de un operador de un Computer
system Federal, o segundo. El cumplimiento de una norma causara
un gran impacto econmico adverso sobre el operador que no est
compensado por el ahorro de todo el gobierno.
Jefes de los organismos pueden aprobar solicitudes de exencin por
decisin awritten cuales explica la base sobre la cual el director del
organismo efectu la verificacin (s) requerida. Una copia de cada tal
decisin, con adquisiciones sensibles o porciones clasificadas
claramente identificados, se enviar a:
Director del Laboratorio de Sistemas de Computacin
La atencin de: FIPS las suspensiones
Instituto Nacional de Estndares y Tecnologa
Gaithersburg, MD 20899
Adems, la notificacin de cada dispensa concedida, y cada
delegacin de la autoridad para aprobar renuncias se enviarn sin
demora al Comit de Operaciones Gubernamentales de la Cmara de
Representantes y el Comit de Asuntos Gubernamentales del Senado
y se publicarn prontitud en el Registro Federal.
Cuando la determinacin en una solicitud de exencin se aplica a la
adquisicin de equipos y / o servicios, una notificacin de la
determinacin de renuncia deber ser publicado en el Comercio
El diario de negocios como parte de la notificacin de la solicitud de
ofertas de una adquisicin o, si la renuncia determinacin se hace
despus de que el anuncio se publica, mediante una modificacin de
dicha notificacin.
Una copia de la solicitud de exencin, los documentos de apoyo, el
documento que se aprueba el solicitud de exencin y de cualquier
documentacin que acompaa y, con deleciones tales como el la
agencia est autorizada y decide hacer bajo 5 USC Sec. 552 (b), ser
parte de la documentacin de adquisicin y retenido por el
organismo.
13. Donde obtener copias.
Las copias de esta publicacin estn a la venta por la National
Servicio de Informacin Tcnica, Departamento de Comercio,
Springfield, VA 22161. Cuando EE.UU.
Pedidos, consulte Federal Information Processing Standards
Publication 183 (FIPSPUB 183) y ttulo. El pago puede hacerse por
cheque, giro postal o ingreso en cuenta.
Introduccin:
Este estndar se compone de secciones normativas e informativas. El
cumplimiento de la secciones de carcter normativo (secciones 1 a 3)
se requiere. Las secciones informativas (Anexos A a D) proporcionar
sugerencias y orientaciones adicionales. El cumplimiento de las
informativas secciones no est obligado a cumplir con la norma, a

menos que dicho cumplimiento se establece por una organizacin de


la adopcin de esta norma.
Esta introduccin informativa se expone los antecedentes y el
enfoque de IDEF0 (prnciado I- def cero). Se proporciona al lector una
orientacin y enfoque de las secciones de carcter normativo.
Fondo:
Durante la dcada de 1970, el Programa de la Fuerza Area de los
Estados Unidos para Computer Integrated Manufacturing Aided
(ICAM) trat de aumentar la productividad de fabricacin mediante la
aplicacin sistemtica de tecnologa computacional. El programa
ICAM identific la necesidad de un mejor anlisis y tcnicas de
comunicacin para las personas involucradas en la mejora de la
productividad de fabricacin.
Como resultado, el programa ICAM desarrollado una serie de tcnicas
conocidas como la IDEF (ICAM Definicin) tcnicas que incluan lo
siguiente:
1. IDEF0, utilizado para producir un "modelo de funcin". Un modelo
es una funcin estructurada la representacin de las funciones,
actividades o procesos dentro del sistema modelado ni la materia.
2. IDEF1, utilizado para producir un "modelo de informacin". Un
modelo de informacin representa la estructura y la semntica de la
informacin dentro del sistema modelado ni la materia.
3. IDEF2, utilizado para producir un "modelo de dinmica". Un modelo
de dinmica representa la variable en el tiempo las caractersticas de
comportamiento del sistema modelado o materia.
En 1983, el programa de Sistema de Soporte Integrado de
Informacin de la Fuerza Area de Estados Unidos aument la IDEF1
tcnica de modelado de informacin para formar IDEF1X (IDEF1
ampliada), un modelado de datos semntica tcnica.
Actualmente, las tcnicas de IDEF0 y IDEF1X son ampliamente
utilizados en el gobierno, industrial y sectores comerciales, el apoyo a
los esfuerzos de modelado para una amplia gama de empresas y
aplicaciones dominios.
En 1991, el Instituto Nacional de Estndares y Tecnologa (NIST) ha
recibido el apoyo del Departamento de Defensa de Estados Unidos,
Oficina de Gestin de Informacin Empresarial (DoD / CIM), que
desarrollar una o ms normas de Procesamiento de Informacin
Federal (FIPS) para las tcnicas de modelado.
Las tcnicas fueron seleccionadas para el modelado IDEF0 funcin y
IDEF1X para obtener informacin modelado. Estos documentos FIPS
se basan en los manuales publicados por el IDEF Area de los EE.UU.
Vigor a principios de 1980.
El enfoque IDEF0:
IDEF0 (Integracin del lenguaje de definicin) se basa en SADT
(anlisis estructurado y Diseo Technique), desarrollado por Douglas
T. Ross y SofTech, Inc. En su forma original, IDEF0 incluye tanto una
definicin de un lenguaje grfico de modelado (sintaxis y la
semntica) y una descripcin de una metodologa completa para el
desarrollo de modelos.

IDEF0 se puede usar para modelar una amplia variedad de sistemas


automatizados y no automatizados. Para el nuevo sistema, IDEF0 se
pueden utilizar en primer lugar definir los requisitos y especificar las
funciones, y luego para disear una implementacin que cumple con
los requisitos y realiza las funciones. Por los sistemas existentes,
IDEF0 se puede utilizar para analizar las funciones y el sistema realiza
para grabar los mecanismos (medios) por el cual estos se realizan.
El resultado de aplicar IDEF0 a un sistema es un modelo que consiste
en una serie jerrquica de diagramas, texto, y glosario referencias
cruzadas entre s. Los dos modelado primaria componentes son
funciones (representado en un diagrama de cajas) y los datos y los
objetos que interrelacionar esas funciones (representadas por
flechas).
Como un lenguaje de modelado funcin, IDEF0 tiene las siguientes
caractersticas:
1. Es amplio y expresivo, capaz de representar grficamente una
amplia variedad de negocios, fabricacin y otros tipos de
operaciones de la empresa a cualquier nivel de detalle.
2. Es un lenguaje coherente y sencillo, proporcionando una
rigurosa y precisa expresin, y la promocin de la consistencia
del uso e interpretacin.
3. Se mejora la comunicacin entre los analistas de sistemas,
desarrolladores y usuarios a travs de la facilidad de
aprendizaje y su nfasis en la exposicin jerrquica de detalle.
4. Est bien probado y demostrado, a travs de muchos aos de
uso en la Fuerza Area y otros proyectos de desarrollo del
gobierno y la industria privada.
5. Puede ser generado por una variedad de herramientas de
grficos de ordenador; numerosos comercial productos apoyan
especficamente el desarrollo y anlisis de diagramas IDEF0 y
modelos.
Adems de la definicin del lenguaje IDEF0, la metodologa IDEF0
tambin prescribe procedimientos y tcnicas para el desarrollo y la
interpretacin de los modelos, incluyendo las de datos recoleccin,
construccin
diagrama,
los
ciclos
de
revisin
y
documentacin. Materiales
relacionados
nicamente
con
la
procedimientos de modelado se presentan en los anexos informativos
de este documento.
1. Informacin general
1.1 Alcance
Esta norma describe el lenguaje de modelado (sintaxis y semntica),
que apoya la Tcnica IDEF0 para el desarrollo de representaciones
grficas estructurados de un sistema o rea de tema.
El uso de este estndar permite la construccin de modelos IDEF0
que comprenden las funciones del sistema (acciones, procesos,
operaciones), relaciones funcionales, y los datos y objetos que
soportan anlisis y diseo de sistemas, anlisis de la empresa, y el
proceso de reingeniera de negocios.

Este documento proporciona tres secciones de carcter normativo, las


secciones 1, 2 y 3, que definen el lenguaje que soporta el modelado
IDEF0. En esta seccin, Seccin 1, ofrece una visin general del
documento.
Seccin 2 se definen los principales trminos utilizados en las
secciones de carcter normativo. Seccin 3 define la sintaxis y la
semntica del lenguaje.
Adems de las tres secciones normativas, este documento tambin
proporciona cuatro informativo anexidades. Anexo A se discutirn los
conceptos que subyacen IDEF0. Anexo B proporciona directrices para
la creacin, la interpretacin y la recoleccin de datos para IDEF0
diagramas. Anexo C describe estructurado procedimientos orientados
al equipo (incluyendo formas) para su revisin y validacin del
modelo IDEF0. Anexo D define los trminos clave que se utilizan en
los anexos.
Esta norma cubre IDEF0 como se define por la Fuerza Area de los
EE.UU. integrado asistido por ordenador Manufactura (ICAM) Manual
de funciones de modelado (IDEF0), junio de 1981, y por lo general
practicada por muchos usuarios IDEF desde entonces.
1.2 Propsito
Los objetivos principales de esta norma son:
1. Para documentar y aclarar la tcnica de modelado IDEF0 y
cmo utilizar correctamente eso;
2. Para proporcionar un medio para modelar completamente y
consistentemente las funciones requerido por un sistema o
materia, y los datos y objetos que interrelacionan esas
funciones;
3.
Para proporcionar un lenguaje de modelado que es
independiente de Computer-Aided Ingeniera de Software
(CASE) mtodos o herramientas, pero que se puede utilizar en
junto con estos mtodos o herramientas;
4. Para proporcionar un lenguaje de modelado que tiene las
siguientes caractersticas:
Genrica (para el anlisis de los sistemas y las materias de distinta
finalidad, alcance y complejidad); segundo)
Rigurosa y precisa (para la produccin de los modelos correctos,
utilizables);
Concisa (para facilitar la comprensin, la comunicacin, el consenso y
validacin);
Conceptual (para la representacin de los requisitos funcionales
independientes de implementaciones fsicas o de organizacin);
Flexible (para apoyar varias fases del ciclo de vida de un proyecto).
2. Definiciones
Esta seccin contiene las definiciones que se relacionan con las
secciones de carcter normativo de este documento. Ver
Anexo D para las definiciones de los anexos informativos. Un trmino,
si est definido, se define en cualquiera Seccin 2 o en el Anexo D.
2.1 A-0 Diagrama: El caso especial de un diagrama de un cuadro de
IDEF0 contexto, que contiene las lminas superior funcin de nivel

que se est modelando y sus entradas, salidas, controles y


mecanismos, adems de declaraciones de propsito de modelo y
punto de vista.
2.2 Flecha: Una lnea dirigida, compuesta por uno o ms segmentos
de flecha, que los modelos de un proceso abierto canal o conducto de
transporte de datos u objetos de fuente (sin punta de flecha) para
usar (con punta de flecha). Hay 4 clases de flecha: Flecha de entrada,
de salida Flecha, Flecha de control, y
Mecanismo de Arrow (Flecha incluye Call). Ver Flecha segmento,
Lmite Flecha, Interna
Flecha.
2.3 Flecha Label: Un sustantivo o un sintagma nominal asociado
con una flecha IDEF0 o segmento de flecha, especificando su
significado.
2.4 Flecha Segmento: Un segmento de lnea que se origina o
termina en un lado de la caja, una rama (tenedor o unirse a), o un
lmite (extremo no conectado).
2.5 Lmites Flecha: Una flecha con un extremo (fuente o uso) no
est conectado a ninguna caja en un diagrama. Contrasta con la
flecha interna.
2.6 Caja: Un rectngulo, que contiene un nombre y nmero, que se
utiliza para representar una funcin.
2.7 Cuadro de Nombre: El verbo o frase verbal colocado dentro de
una caja IDEF0 para describir el modelado funcin.
2.8 Nmero Box: El nmero (0 a 6) colocado en el interior de la
esquina inferior derecha de una caja IDEF0 para identificar de forma
exclusiva la caja en un diagrama.
2.9 Poder: Una unin (tenedor o unirse a) de dos o ms segmentos
de flecha.
La agrupacin 2.10 / Disociacin: es la combinacin de los
significados de flecha en un sentido material compuesto (agrupacin),
o la separacin de los significados de flecha (de separacin),
expresadas por la flecha unirse y tenedor sintaxis.
2,11 C-Nmero: Un nmero creacin cronolgico que puede
utilizarse para identificar un Diagrama y para rastrear su historia; se
puede utilizar como una expresin de Detalle de la referencia para
especificar una versin particular de un diagrama.
2.12 Llamada Flecha: Un tipo de mecanismo de flecha que permite
el intercambio de detalle entre las modelos (enlazndolos) o dentro
de un modelo.
2.13 Caja infantil: una caja en un diagrama hijo.
2.14 Diagrama de Nios: El diagrama que detalla una caja padre.
2.15 Contexto: El entorno inmediato en el que una funcin (o
conjunto de funciones en una diagrama) opera.
2.16 Diagrama de contexto: Un diagrama que presenta el contexto
de un modelo, cuyo nmero de nodo es An (n mayor que o igual a
cero). El uno-box A-0 diagrama es un diagrama de contexto requerida;
aquellos con nmeros de nodo A-1, A-2, ... son diagramas de contexto
opcionales.

2.17 Control de Flecha: La clase de flechas que expresan control


IDEF0, es decir, las condiciones requiere para producir una salida
correcta. Datos u objetos modelados como controles pueden ser
transformadas por la funcin, creando de salida. Flechas de control
estn asociadas con el lado superior de una caja de IDEF0.
2,18 descomposicin: La particin de una funcin de modelado en
sus funciones de los componentes.
2.19 Detalle Referencia de expresiones (DRE): Una referencia
(por ejemplo, nmero de nodo, C-nmero, pgina nmero) escrita
debajo de la esquina inferior derecha de una caja IDEF0 para mostrar
que es detallada y indicar qu diagrama detalles ella.
2.20 Diagrama: Una sola unidad de un modelo IDEF0 que presenta
los detalles de un cuadro.
Nmero de nodo 2.21 Diagrama: La parte del nodo de referencia
de un diagrama que corresponde a su El nmero de nodo caja padre.
2,22 para el diagrama Exposicin solamente (FEO): Una
descripcin grfica utilizada para exponer o resaltedatos especficos
acerca de un diagrama IDEF0. A diferencia de un diagrama grfico
IDEF0, un diagrama FEO necesita
No cumplir con las normas IDEF0.
2.23 Tenedor: La unin a la que un segmento de IDEF0 flecha
(pasando de fuente para utilizar las divisiones) en dos o ms
segmentos de flecha. Puede denotar la desagregacin de significado.
2.24 Funcin: Una actividad, proceso o transformacin (modelada
por una caja IDEF0) identificado por un verbo o verbo frase que
describe lo que debe llevarse a cabo.
2.25 Funcin Nombre: Igual que el cuadro de nombres.
2.26 Glosario: Un listado de definiciones de las palabras clave,
frases y acrnimos utilizados en conjuntamente con un nodo o
modelo IDEF0 como un todo.
2.27 Cdigo ICOM: El acrnimo de entrada, de control, de salida,
Mecanismo. Es un cdigo que los asociados las flechas de lmite de un
nio diagrama con las flechas de la caja padre; tambin se utiliza
para la referencia propsitos.
2.28 IDEF0 Modelo: Una descripcin grfica de un sistema o sujeto
que se desarrolla para una propsito especfico y desde un punto de
vista seleccionado. Un conjunto de uno o ms diagramas IDEF0 que
representar las funciones de un sistema o rea de tema con grficos,
texto y glosario.
2,29 Flecha de entrada: La clase de flechas que expresan IDEF0 de
entrada, es decir, los datos u objetos que son transformados por la
funcin en la salida. Una flecha de entrada est asociada con el lado
izquierdo de una
Caja IDEF0.
2.30 Interfaz: Un Lmite compartido A travs del Cual se transmiten
los Datos u Objetos; la conexin Entre dos o mas Componentes del
modelo con el fin de Pasar Datos u Objetos de uno una el otro.
2,31 Flecha interna: Una flecha de entrada, de salida de control o
de Conectado en Ambos Extremos (origen y Como utilizar) un cuadro
de la en diagrama de la . Contraste con Lmite Flecha.

2.32 Ingreso: La unin a la Que Un segmento de IDEF0 flecha (Que


Va desde la fuente al Como utilizar fusiones) con uno o ms de Otros
Segmentos de flecha para Formar sencilla segmento flecha. Puede
del denotar Agrupacin de flecha significados de segmento.
2.33 Mecanismo Flecha: La Clase de Flechas Que expresan IDEF0
mecanismo m, ES DECIR, Los Medios
Utilizada para Realizar una funcin f; . INCLUYE El caso especial de la
Llamada Flecha Mecanismo de Flechas hijo
Asociado con El lado de Fondo De Una caja IDEF0.
Nota 2.34 Modelo: Un comentario textual Que es parte de la
diagrama IDEF0, Que se utilizaci para grabar Hecho sin
Representado De Otra Manera.
2.35 Nodo: Una caja de la Cual se originan las cajas de los
Nios; Una caja de matriz ndice Nodo Sede, rbol de nodos, Nmero
de nodo, nodo de Referencia, El Nmero de nodo Diagrama.
2.36 ndice de nodo: Un Perfil, el menudo con una sangra, Que
MUESTRA los nodos en "Contorno" un modelo IDEF0 es orden. Lo
Mismo Que SIGNIFICADO y contenido rbol de nodos.
2.37 Nmero de nodo: Un cdigo asignado un Una caja para su
Especificar s posicin en la jerarqua del modelo;
Se Puede Como utilizar Como una Expresin de Detalle de la
Referencia.
2.38 nodo de Referencia: Un cdigo asignado un diagrama para
identificar y Especificar dos posicin en el jerarqua del
modelo; Compuesto por el nombre del modelo (abreviado) y el
Nmero de nodo del diagrama, con Extensiones Opcionales.
2.39 rbol de nodos: La Representacin grfica de las Relaciones
padre-hijo Entre el Los nodos de la modelo IDEF0, en la forma de Un
rbol grfico. Lo Mismo SIGNIFICADO Y Que El contenido Nodo ndice.
2,40 salidas Flecha: La clase de Flechas Que expresan IDEF0 de
salida, es factible de, los Datos u Objetos Producido por Una funcin
f. Flechas de salida estn asociados con el Lado Derecho De Una caja
de IDEF0.
Recuadro 2.41 Padres: POSITION Que se detalla Por un diagrama
hijo.
Diagrama 2,42 Padres: Un diagrama Que Contiene Una caja padre.
2.43 Propsito: Una breve Exposicin de La Razn de la existencia f
de la modelo.
2,44 Semntica: El SIGNIFICADO de los Componentes sintcticos De
Una lengua.
2,45 Onda irregular: Una Pequea Lnea dentada Que PUEDE
utilizarse para asociar Una Etiqueta con Una flecha en particular,
segmento o para asociar Una nota Modelo de la estafa Componente
de la diagrama.
2.46 Sintaxis: Componentes o Caractersticas del lenguaje
Estructural y Las reglas definen Que Relaciones Entre Ellos.
2.47 Texto: Un textual (sin grfico) Comentario Sobre IDEF0 general
de diagrama grfico.

2.48 Ttulo: Un verbo o frase verbal Que describir el


FUNCIONAMIENTO generales Presentado en Una IDEF0 diagrama; el
ttulo de Nio diagrama corresponde un su nombre Caja padre.
2.49 Flecha de tnel: Una flecha (con notacin especial) Que No
Sigue la Normalidad Requisito de Que Cada flecha En un diagrama
corresponder Dbe una de las Flechas de los Padres y Relacionada El
Nio diagramas.
2.50 Punto de vista: Una breve Exposicin de la perspectiva del
modelo.
3. Modelos IDEF0
Discute this section Los Elementos Bsicos de la tcnica de modelado
IDEF0, IDENTIFICA EL bsico Componentes de la sintaxis
(Componente grfico) y semntica (SIGNIFICADO), ESPECIFICA Las
reglas Que EL USO normal de la tcnica IDEF0, y describir los Tipos de
diagramas utilizados. Aunque el
Componentes de la sintaxis y la semntica estn Muy Relacionados
Entre s, Cada Uno de Ellos se Discute Separado por el pecado Tener
en Cuenta la Secuencia Real de la construccin.
3.1 Conceptos de Modelos
Un modelo es una representacin de un conjunto de componentes de
un sistema o materia. El modelo es desarrollado para la comprensin,
el anlisis, la mejora o la sustitucin del sistema. Los sistemas son
compuestos de interfaz e interdependientes partes que trabajan
juntas para realizar una funcin til.
Partes del sistema pueden ser cualquier combinacin de cosas,
incluyendo personas, informacin, software, procesos, equipos,
productos o materias primas. El modelo describe lo que hace un
sistema, lo que lo controla, lo que las cosas que trabaja, lo que
significa que se utiliza para llevar a cabo sus funciones, y lo que
produce.
IDEF0 es una tcnica de modelado basado en grficos y texto
combinados que se presentan en una organizada y sistemtica para
ganar la comprensin, apoyar el anlisis, la lgica para proporcionar
cambios potenciales, especifican los requisitos, o el diseo y la
integracin a nivel de los sistemas de apoyo ocupaciones. Un modelo
IDEF0 se compone de una serie jerrquica de diagramas que
gradualmente muestran aumento de los niveles de detalle que
describe las funciones y sus interfaces en el contexto de un sistema.
Hay tres tipos de diagramas: grfico, texto, y un glosario. Los
diagramas grficos definir funciones y relaciones funcionales a travs
de caja y la sintaxis y la semntica de flecha. El texto y los diagramas
del glosario se proporciona informacin adicional en apoyo de
diagramas grficos.
IDEF0 es una tcnica de ingeniera para la realizacin y gestin de
anlisis de las necesidades, beneficios anlisis, los requisitos de
definicin, anlisis funcional, diseo de sistemas, mantenimiento, y
lneas de base para la mejora continua. Modelos IDEF0 proporcionan
un "plano" de las funciones y sus interfaces que deben ser capturados
y se entienden con el fin de hacer la ingeniera de sistemas
decisiones que son lgicos, asequibles, integrables y alcanzables. El

modelo refleja IDEF0 Cmo funciona el sistema se interrelacionan y


actan simplemente como el modelo de un producto refleja cmo el
diferentes piezas de un producto encajan. Cuando se utiliza de una
manera sistemtica, proporciona una IDEF0 sistemas de enfoque de
ingeniera para:
Realizacin de Anlisis y Diseo de Sistemas en Todos Los Niveles,
para los Sistemas Compuestos por Personas, Mquinas, Materiales,
equipos e Informacin de Todas las Variedades - la totalidad Empresa,
el Sistema de las Naciones Unidas, o temtica rea no; La Produccin
de Referencia Documentacin concurrente con el Desarrollo para
servir v Como una de bases para la Integracin de Nuevos Sistemas O
La Mejora de los Sistemas existentes; La Comunicacin Entre los
Analistas, Diseadores, Usuarios Gestores Y; Permitiendo Que El
Consenso del equipo de Coalicin Que se consigue Mediante la
Comprensin Compartida; La Gestin de Proyectos Grandes y
Complejos Usando: medidas cualitativas del progreso; Proporcionar
Una Arquitectura de Referencia para el Anlisis de la Empresa,
Ingeniera de la Informacin y gestin de recursos.
Discusin: Adems de los Conceptos, La Filosofa y los papeles de los
Participantes en el modelado IDEF0 Proyectos Se presenta en los
anexos informativos of this document.
3.2 Sintaxis y semntica
3.2.1 Sintaxis
Los componentes y caractersticas de un lenguaje estructurales y las
reglas que definen las relaciones entre ellos se refieren como la
sintaxis del lenguaje. Los componentes de la sintaxis IDEF0 son cajas
y flechas, reglas y diagramas. Las cajas representan funciones,
definidas como actividades, procesos o transformaciones. Las flechas
representan los datos u objetos relacionados con las funciones. Las
reglas definen cmo los componentes se utilizan, y los diagramas de
proporcionar un formato para representar modelos tanto verbal y
grficamente. El formato tambin proporciona la base para la
configuracin del modelo administracin.
3.2.1.1 Cajas
Un cuadro ofrece una descripcin de lo que sucede en una funcin
designada. Un cuadro tpico se muestra en la figura 1. Cada caja
deber tener un nombre y nmero dentro de los lmites de la caja. El
nombre esperarn ser un verbo o verbo activo frase que describe la
funcin. Cada casilla del diagrama deber contener un nmero dentro
de la caja de la esquina inferior derecha. Nmeros de caja se utilizan
para identificar el sujeto la caja en el texto asociado.

3.2.1.2 Las flechas


Una flecha se compone de uno o ms segmentos de lnea, con una
punta de flecha de terminal en un extremo. Como se muestra en la
Figura 2, los segmentos de flecha puede ser recta o curva (con un 90?
arco conectando horizontal y partes verticales), y pueden tener
configuraciones de ramificacin (que se bifurcan o de unin).
Las flechas no representan flujo o secuencia como en el modelo de
flujo del proceso tradicional. Las flechas transmiten los datos u
objetos relacionados con las funciones a realizar. Las funciones de
recepcin de datos o los objetos se ven limitadas por los datos u
objetos puestos a su disposicin.

Figura 2. Flecha Sintaxis

segmento de flecha Recta


segmento de flecha curva;
esquinas son redondeados con 90 arcos de grado
flechas que se bifurcan
Unir las flechas

3.2.1.3 Reglas de sintaxis


Cajas
1. Las cajas debern ser de tamao suficiente para insertar el nombre
del buzn.

2. Las cajas debern ser de forma rectangular, con esquinas


cuadradas.
3. Las cajas debern estar dibujados con lneas continuas.
Las flechas
1. Las flechas que se doblan debern ser curvos, utilizando slo 90
arcos de grado.
2. Las flechas sern elaborados en los segmentos de lnea continua.
3 Las flechas sern elaborados vertical u horizontalmente, no en
diagonal.
4. Los extremos de flecha debern tocar el permetro exterior de la
caja de funciones y deber no cruce en la caja.
5. Las flechas debern adjuntar a los lados de la caja, no en las
esquinas.
3.2.2 Semntica
La semntica se refiere al significado de los componentes sintcticos
de una lengua y
la correcciones adjuntas de interpretacin.
Interpretacin aborda elementos como la caja y la notacin de flecha
y funcional Interfaces de relacin.
3.2.2.1 Caja y Flecha Semntica
Desde IDEF0 soporta el modelado de funcin, el nombre de la caja
deber ser una frase verbo o verbo, como "Realizar la inspeccin", es
descriptivo de la funcin que representa la caja. El ejemplo "Realizar
Inspeccin" funcin transforma las piezas inspeccionadas en partes
inspeccionadas. El paso definitivo ms all de la frase-nombramiento
de la caja es la incorporacin de las flechas (ajustando orientacin de
los lados de la caja) que complementan y completan la potencia
expresiva (como distingue del aspecto de representacin) de la caja
IDEF0.
Terminologa estndar se utiliza para asegurar una comunicacin
precisa. Significados de caja son cuyo nombre en forma descriptiva,
con verbos o frases verbales y son separados y agrupados en
descomposicin diagramacin. Significados de flecha se encuentran
agrupados y desagregados en la diagramacin y la flecha segmentos
estn etiquetados con nombres o frases nominales para expresar
significados. Etiquetas Flecha segmentos se prescriptivo, lo que limita
el significado de su segmento que se aplica exclusivamente a lo datos
particulares u objetos que el segmento de flecha representa
grficamente. Significados de flecha son ms expresado a travs de
un tenedor y la sintaxis de combinacin.
Cada lado de la caja de funcin tiene un significado estndar en
trminos de relaciones de la caja / de flecha. Los lado de la caja con la
que una interfaz de flecha refleja el papel de la flecha. Las flechas
que entran en el lado izquierda de la caja son entradas. Las entradas
se transforman o consumen por la funcin de producir salidas. Las
flechas que entran en la caja en la parte superior son los controles.
Controles especifican las condiciones requeridas para la funcin de
producir salidas correctas. Las flechas que salen de una caja en el

lado derecho son salidas. Los productos son los datos u objetos
producidos por la funcin.
Flechas conectadas al lado inferior de la caja representan
mecanismos. Flechas apuntando hacia arriba identifican algunos de
los medios que soportan la ejecucin de la funcin. Otros medios
pueden ser heredado de la caja padre. Flechas mecanismo que
apuntan hacia abajo son las flechas de llamadas. Llamada flechas
permiten el intercambio de detalle entre los modelos (que unen entre
s) o entre partes del mismo modelo. La caja llamada proporciona
detalles para el cuadro de llamadas (vase la Seccin 3.3.2.10).
Posiciones de flecha estndar se muestran en la Figura 3.
Apoyando la informacin relativa a la funcin y su propsito ser
dirigida en el texto asociado con el diagrama. Un diagrama puede o
no puede haber asociado texto. Cuando las siglas, abreviaturas,
palabras clave o frases, el trmino (s) son definidos por completo se
presentar en el glosario.

3.2.2.2 Las etiquetas y nombres


Las cajas representan funciones, que muestran lo que debe llevarse a
cabo. Un nombre de funcin ser un verbo activo o frase verbo, tales
como:
Partes proceso
Plan de recursos
Conducta opinin
Monitorear el desempeo
Sistema de diseo
Proporcionar mantenimiento
Desarrollar detalle de diseo
Fabrique componente
Inspeccionar partes
Las flechas identifican los datos u objetos necesarios o producidos por
la funcin. Cada flecha ser marcado con un sustantivo o un sintagma
nominal, tales como:
Presupuesto
Especificaciones
Informe de prueba
Requisitos de diseo
Directiva
Detalle sobre diseo

Requisitos
Montaje de mesa
Diseo ingeniero
Un ejemplo que representa la colocacin de las etiquetas de direccin
y los nombres de cuadros se muestra en la Figura 4.

3.2.2.3 Cajas y Flecha reglas semnticas


1. Una caja se nombra con un verbo activo o frase verbal.
2. Cada lado de un cuadro de la funcin tendr una relacin / caja de
flecha estndar:
a) Una flecha de entrada debern interconectarse con el lado
izquierdo de una caja.
b) las flechas de control debern interconectarse con el lado superior
de una caja.
c) flechas de salida debern interconectarse con el lado derecho de la
caja.
d) Mecanismo de flechas (excepto flechas de llamada) deber apuntar
hacia arriba y deber conectar a la parte inferior de la caja.
e) Mecanismo de llamada flechas debern apuntar hacia abajo,
deber conectarse a la parte inferior lado de la caja, y se etiquetarn
con la expresin de referencia para el cuadro que detalla el cuadro de
tema.
3. Los segmentos de flecha, a excepcin de las flechas de llamadas,
llevarn una etiqueta con un nombre o sustantivo frase a menos que
una nica etiqueta de flecha se aplica claramente a la flecha en su
conjunto.
4. Una "garabato" (
) se utiliza para vincular una flecha con su
etiqueta asociada, a menos que la flecha / relacin de etiqueta es
obvia.
5. Flecha etiquetas no debern consistir nicamente en cualquiera de
los siguientes trminos: funcin, de entrada, el control, la produccin,
el mecanismo, o una llamada.

3.3 Los diagramas IDEF0


3.3.1 Tipos de Diagramas
Modelos IDEF0 se componen de tres tipos de informacin: diagramas
grficos, texto y glosario. Estos tipos de diagramas son referencias
cruzadas entre s. El diagrama grfico es el componente principal de
un modelo IDEF0, que contiene cajas, flechas, interconexiones / caja
de direccin y relaciones asociadas. Las cajas representan cada
funcin principal de un sujeto. Estas funciones son desglosadas o
descompuesto en diagramas ms detallados, hasta que el tema se
describe en una nivel necesario para apoyar los objetivos de un
proyecto en particular. El diagrama de nivel superior en el modelo
proporciona la descripcin ms general o resumen de la materia
representada por el modelo. Este diagrama es seguido por una serie
de diagramas que proporcionan nio ms detalles sobre el tema.
Diagrama de Contexto de nivel superior
Cada modelo tendr un diagrama de contexto de nivel superior, en el
que el sujeto del modelo es representado por una nica caja con sus
flechas delimitadoras. Esto se llama el diagrama A-0 (Pronunciado un
cero menos). Las flechas en el diagrama de esta interfaz con
funciones fuera del rea sujeta a establecer el enfoque del modelo.
Desde un nico cuadro representa todo el tema, el nombre
descriptivo escrito en el cuadro es general. Lo mismo es cierto de las
flechas interfaz desde tambin representan el conjunto completo de
interfaces externas al sujeto. El diagrama A-0 tambin establece el
alcance o cobertura modelo y la orientacin. Un ejemplo A-0
diagrama se muestra en la figura 5.
El A-0 diagrama de contexto tambin presentar exposiciones breves,
especificando punto de vista del modelo y propsito, que ayudan a
guiar y limitar la creacin del modelo. El punto de vista determina lo
que puede ser "visto" en el contexto del modelo, y desde qu
perspectiva o "inclinada". Dependiente en la audiencia, las diferentes
declaraciones de puntos de vista pueden ser adoptados que hacen
hincapi en diferentes aspectos del tema. Cosas que son importantes
en un solo punto de vista ni siquiera pueden aparecer en una modelo
presenta desde otro punto de vista sobre el mismo tema.
La exposicin de motivos expresa la razn por la cual se crea el
modelo y, de hecho determina la estructura del modelo. Las
caractersticas ms importantes son lo primero en la jerarqua, como
el conjunto funcin de nivel superior se descompone en partes subfuncin que la componen, y las partes, a su vez, se descomponen
ms hasta que todos los detalles relevantes de todo el punto de vista
son adecuadamente expuestos. Cada sub-funcin se modela de forma
individual por un cuadro, con las cajas de padres detallados por
diagramas de los nios en el siguiente nivel inferior. Todos los
diagramas nios deben estar dentro del alcance de la toplevel
diagrama contextual.

Figura 5. Ejemplo de nivel superior Diagrama


3.3.1.2 Diagrama hijo
La funcin nica representada en el diagrama de contexto de nivel
superior puede ser descompuesta en sus principales sub-funciones
mediante la creacin de su diagrama de nio. A su vez, cada uno de
estos sub-funciones se puede descomponer, cada uno creando otro,
diagrama hijo de nivel inferior. En un diagrama dado, algunas de las
funciones, ninguna de las funciones o todas las funciones pueden
descomponerse. Cada nio diagrama contiene los cuadros de los
nios y las flechas que proporcionan detalles adicionales acerca de la
caja padre.
El nio diagrama que resulta de la descomposicin de una funcin
abarca el mismo alcance que la caja padre detalla. Por lo tanto, un
diagrama nio puede ser considerado como el "interior" de su caja
padre. Esta estructura se ilustra en la Figura 6.
3.3.1.3 Diagrama Padres
Un diagrama de los padres es uno que contiene una o ms casillas de
padres. Cada (no-marco) Diagrama ordinaria es tambin un diagrama
hijo, ya que por definicin se detalla una caja padre. As, un diagrama
puede ser a la vez un diagrama de matriz (que contiene las cajas de
los padres) y un diagrama hijo (detallando su propia caja padre). Del
mismo modo, una caja puede ser tanto una caja padre (detallado por
un diagrama hijo) y una caja nio (que aparece en un diagrama hijo).
La relacin jerrquica entre el primario es un cuadro de los padres y el
nio diagrama que detalla la misma.

Figure 6. Decomposition Structure


El hecho de que una caja de nio es detallada, y por lo tanto es
tambin un cuadro de los padres, se indica con el Expresin presencia
de un Detalle de la referencia (DRE). El tacto rectal es un cdigo corto
escrito por debajo de la esquina inferior derecha del cuadro se
detalla (padre) que seala a su nio diagrama.
El DRE adoptar una de las siguientes formas:
1. Un nmero de creacin cronolgico llama una "C-nmero" que
identificar de forma nica una versin particular de un diagrama
hijo.
2. Un nmero de pgina del diagrama de nio en el documento
publicado en la que el modelo aparece.
3. El nmero de nodo referencia al diagrama hijo. Si hay varias
versiones de un diagrama hijo, una versin particular no se puede
especificar.
4. Un nmero de modelo nota cuyo texto especifica las condiciones
para la seleccin de un en particular versin infantil.
La Figura 7 ilustra el uso de nmeros de nodo como DRE. En la figura,
la presencia de DRE bajo las casillas 1, 2 y 3 indica que se han
detallado en los diagramas secundarios especificados.

Figura 7. Detalle Referencia de expresiones de uso


3.3.1.4 Texto y Glosario
Un diagrama puede haber asociado texto estructurado, que se utiliza
para proporcionar un panorama general de El diagrama. Texto se
utiliza para resaltar las caractersticas, los flujos y conexiones interbox para aclarar la intencin de artculos y los patrones que se
consideran de importancia. El texto no se utiliza tan slo para
describir, de forma redundante, el significado de las cajas y flechas.
El glosario se utiliza para definir las siglas y palabras y frases clave
que se han utilizado en conjuntamente con el diagrama de grficos. El
glosario se define las palabras en el modelo que debe transmitir un
entendimiento comn con el fin de interpretar correctamente el
contenido del modelo.
3.3.1.5 Slo para la exposicin Diagramas
Por Exposicin solamente (FEO, pronunciada tarifa-oh), donde un
nivel adicional se utilizar diagramas Se requiere de conocimiento
adicional para entender adecuadamente las reas especficas de un
modelo.
Detallando complementaria debe limitarse a lo que se necesita para
alcanzar el objetivo establecido para un pblico conocedor. Un
diagrama FEO no necesita cumplir con las reglas de sintaxis IDEF0.
3.3.2 Caractersticas del diagrama
3.3.2.1 Las flechas como restricciones
Las flechas en un diagrama IDEF0 representan datos u objetos como
limitaciones. Slo a niveles bajos de detalle puede flechas
representan el flujo o secuencia, cuando el sujeto modelado es lo
suficientemente detallada para tratar los cambios especficos aplicado
a los elementos u objetos de datos especficos. Conexin de la salida
de un cuadro a la entrada, control, o mecanismo de otra caja muestra
que la funcin de modelado por este ltimo cuadro requiere, y por lo
tanto se ve limitado por la presencia de la salida correspondiente de
la antigua caja. Este tipo de restriccin se ilustra en la Figura 8. Las

flechas que conectan a una caja representan todos los datos y objetos
que son necesarios para la funcin a realizar por completo.

Figura 8. Significado de restriccin


3.3.2.2 Las activaciones de una caja
Una caja puede realizar diversas partes de su funcin en
circunstancias diferentes, usando diferentes combinaciones de su
entrada y controles y la produccin de diferentes salidas. Estas
diferentes actuaciones se llaman las diferentes activaciones de la
caja.
3.3.2.3 Operacin concurrente
Varias funciones en un modelo se pueden realizar al mismo tiempo, si
las restricciones necesarias han sido satisfechas. Como se ilustra en
la Figura 9, una salida de una caja puede proporcionar algunos o
todos los datos y objetos necesarios para las activaciones de uno o
ms cajas.
Cuando una salida de una caja ofrece algunas o todas las entradas,
controla o mecanismos necesarios por otra caja, una activacin
determinada de este ltimo cuadro puede depender de rendimiento
secuencial.
Sin embargo, diferentes activaciones de la misma caja (s), con
posiblemente diferentes requisitos, puede operar simultneamente.

Figura 9. Operacin concurrente


3.3.2.4 Las flechas como tuberas
Es til pensar en las flechas de alto nivel como tuberas o conductos.
Flechas de alto nivel tienen etiquetas generales, mientras que las
flechas en los diagramas de nivel inferior tienen etiquetas ms
especficas. Si una flecha se divide, formando dos o ms nuevos

segmentos de flecha, cada segmento flecha pueden tener una ms


especfica etiqueta, como se muestra en la Figura 10.

Un oleoducto se divide en B y C para proporcionar controles para X e


Y.
Figura 10. Tubera con la Flecha bifurcar
3.3.2.5 Las flechas de ramificacin
Una flecha puede ramificar (tenedor o unirse), lo que indica que el
mismo tipo de datos o puede ser objeto necesaria o producidos por
ms de una funcin. Las ramas pueden representar ya sea la misma
cosa o porciones de la misma cosa. Ya que las etiquetas especifican
qu flecha segmentos representan, etiquetas en la ramificacin
segmentos de flecha proporcionar un detalle del contenido de la
flecha al igual que el nivel inferior diagramas proporcionan una
definicin detallada de las cajas de los padres.
Todo o parte de los contenidos de una flecha puede seguir una rama.
Una flecha que se bifurcan puede denotar la "Desagregacin" de
significados que haban sido combinados bajo una etiqueta ms
general. La unin de dos segmentos de flecha, pueden significar
"agrupacin", es decir, la combinacin de significados independientes
en una ms categora general. Todos los contenidos se proporcionan a
travs de todas las ramas a menos que se marcada con una etiqueta
especial en cada segmento de la flecha. Estas convenciones se
ilustran en la figura 11.

Figura 11. Flecha Tenedor y unirse Estructuras


3.3.2.6 Conexiones de Inter-Box
A excepcin de la de un solo cuadro A-0 diagrama de contexto, un
diagrama grfico contiene un mnimo de tres y un mximo de seis
cajas. Las cajas son normalmente organizadas en diagonal desde la
esquina superior izquierda a la parte inferior derecha, es decir, en una
configuracin de "escalera".
Cualquier flecha de salida puede proporcionar algunas o todas de la
entrada, de control, o los datos mecanismo o los objetos a cualquier
otra caja. Una flecha de salida puede proporcionar datos u objetos a
varias cajas a travs del mecanismo de bifurcacin, como se muestra
en la Figura 12.

Figura 12. Conexiones entre cajas


Si una caja en un diagrama se detalla por un diagrama hijo, cada
flecha conectada a la caja padre deber aparece en el diagrama hijo,
a menos que la flecha es un tnel junto a su caja padre (ver
Seccin3.3.2.9).
En un diagrama, los datos o los objetos pueden ser representados por
una flecha interna, con ambos extremos (fuente y el uso) conectado a
cajas, o por una flecha lmite, con un solo extremo (fuente o uso)
conectado. Flechas internas y flechas de contorno se muestran en la
Figura 13. Flechas de contorno son se discute en detalle en las
secciones 3.3.2.7 y 3.3.2.8.

Figura 13. Lmites y flechas Interna


3.3.2.7 Las flechas de frontera
Flechas de contorno en una (no-marco) Diagrama grfico ordinaria
representan los insumos, los controles, salidas, o mecanismos de
cuadro de los padres del diagrama. La fuente o el uso de estos lmites
flechas se pueden encontrar slo examinando el diagrama de matriz.
Todas las flechas de contorno en un nio diagrama (a excepcin de
las flechas de tnel, Seccin 3.3.2.9) debern corresponder a las
flechas que conectan a su cuadro de matriz, como se muestra en la
Figura 14.

Figura 14. Lmites Flecha correspondencia


3.3.2.8 Codificacin de ICOM flechas de frontera
ICOM cdigos se refieren flechas contorno sobre un diagrama hijo de
flechas conectadas a la caja padre. Una notacin especfica,
denominada cdigos ICOM, especifica las conexiones con las
caractersticas determinadas. La letra I, C, O o M est escrito cerca
del extremo no conectado de cada flecha lmite en el diagrama hijo.
Esta codificacin identifica la flecha como una entrada, de control, de
salida o mecanismo en la caja padre. Esta letra es seguida por un
nmero que da la posicin relativa a la que se muestra la flecha
conectar a la caja de los padres, la numeracin de izquierda a
derecha o de arriba a abajo. Por ejemplo, "C3" escrito en una flecha
lmite en un diagrama de nio indica que esta flecha corresponde a la
tercera control de flecha (desde la izquierda) que entra en su caja
padre.
Esta codificacin se refiere cada diagrama nio a su propia caja padre
inmediato. Si las cajas en un nio diagrama se detallan en posteriores
diagramas nio, nuevos cdigos ICOM se asignan en cada nueva
diagrama hijo, relativa flechas contorno de ese diagrama de flechas
en su propio padre inmediato caja.
Utilizando el esquema de juego de cartas numeracin de codificacin
ICOM, flecha papeles (de entrada, de control, mecanismo) puede
variar entre los diagramas de padres e hijos. La figura 14 muestra el
caso comn donde los roles coinciden, por ejemplo, la entrada a la
caja de matriz coincide con la entrada en el nio diagrama. Como un
ejemplo de cambio de roles, una flecha de control de un cuadro de los
padres puede ser o bien una de entrada o una flecha de control para
cajas en su diagrama de nio. Del mismo modo, un control para una

caja de matriz puede ser una entrada para una o ms de sus cajas de
nio. La Figura 15 muestra ejemplos de cambio de la flecha roles.
Figura 15. Cdigos de ICOM y nuevas funciones para Flecha

NOTA: Las lneas de puntos muestran cmo los iconos en el diagrama


hijo se relacionan flechas de contorno o nio a las flechas de la caja
padre.
3.3.2.9 Las flechas tunelizados
Una flecha de tnel se utiliza para proporcionar informacin a un nivel
especfico de descomposicin que no es requerido para la
comprensin de algunos otros niveles. Una flecha puede encapsularse
en cualquier nivel deseado.
El uso de los parntesis notacin ilustra en la Figura 16, una flecha
tnel donde se conecta a una lado de la caja significa que los datos u
objetos expresados por la flecha no son necesarios para la
comprensin de nivel subsiguiente (s) de descomposicin, y por lo
tanto se no se mostrar en su hijo diagrama. Sin embargo, debido a
esta flecha se corresponde con uno en su diagrama de matriz, se le
da un cdigo de ICOM. Este cdigo puede ser utilizado en otra parte
en el modelo, por ejemplo, en una expresin de referencia en un
diagrama donde la flecha vuelve a aparecer, con el fin de identificar
la ubicacin del original tunneling. Una flecha de tnel en su extremo
conectado puede omitirse de uno o ms niveles de descomposicin y
luego vuelven a aparecer en otro nivel, en uno o ms lugares, en el
tnel extremo no conectado.

Figura 16. Las flechas en un tnel extremo conectado


Tunneling una flecha en el extremo no conectado significa que los
datos u objetos que no son necesarios en el siguiente nivel (padre) y
por lo tanto no se muestra la conexin a la caja padre. Esto es se
muestra en la Figura 17. Debido a esta flecha no corresponde a uno
en su diagrama de matriz, que hace no tiene un cdigo de ICOM. La
flecha puede tener una nota modelo adjunto que contiene el nodo
referencia y el cdigo del ICOM que se localiza el "otro extremo" del
tnel. ICOM codifica la flecha hojas de vida para cualquier nio
diagramas siguientes.
La figura 18 muestra un ejemplo de flechas de tnel en diagramas de
padres e hijos.

Figura 17. Las flechas en un tnel extremo no conectado

Figura 18. Ejemplo de flechas tunelizados


3.3.2.10 Las flechas de llamada
Una flecha de llamada es un caso especial del mecanismo de flecha.
Significa que el cuadro de la persona que llama no tiene su propio
diagrama hijo al detalle, sino ms bien se detalla en su totalidad por
otra caja (y sus descendientes) en el mismo u otro modelo. Cajas de
llamantes mltiples pueden llamar a la misma caja.
La flecha llamada se marca con la referencia de nodo del diagrama
que contiene la caja llamada, junto con el nmero de llamada caja. Un
cuadro de la persona que llama puede llamar slo una casilla en una
activacin dada. Sin embargo, dependiendo de las condiciones
especificadas en una nota modelo que se adjunta a una flecha
llamada, la persona que llama puede cuadro seleccionar una de
varias posibles llamadas cajas. En este caso, la etiqueta llamada
flecha incluir una lista de las referencias de nodo de todas las
posibles llamadas cajas.
Las flechas de la caja de llamada pueden no corresponder
exactamente con los de la caja de la persona que llama, ya sea en
nmero o en el significado. En estos casos, las notas modelo que se
adjunta a las flechas de llamadas se especificar el relaciones para
que la correcta interpretacin pueden ser administrados para los
datos y los objetos compartidos.
3.3.3 Reglas diagramas de sintaxis
1. Los diagramas de contexto tendrn nmeros de nodo A-n, donde n
es mayor o igual a cero.
2. El modelo debe contener un diagrama de contexto A-0, que
contiene slo una casilla.

3. El nmero de la caja de la caja nica en el contexto diagrama A-0


ser 0.
4. Un diagrama de contexto no deber tener al menos tres cajas y no
ms de seis cajas.
5. Cada caja en un diagrama sin contexto estar numerada en su
parte inferior derecha en el interior esquina, a fin (desde la parte
superior izquierda a la inferior derecha en el diagrama) de 1 a lo sumo
6. Cada caja que se ha detallado tendr la expresin detalle de
referencia (DRE, por ejemplo, nmero de nodo, C-nmero, o el
nmero de pgina) de su hijo diagrama escrito debajo de la esquina
inferior derecha de la caja.
7. Las flechas se dibujan como segmentos de lneas rectas
horizontales y verticales. Diagonal
No se utilizarn segmentos de lnea.
8. Cada caja deber tener un mnimo de una flecha de control y una
flecha de salida.
9. Una caja deber tener cero o ms flechas de entrada.
10. Una caja deber tener cero o ms no de llamadas flechas
mecanismo.
11. Una caja deber tener 0 o 1 flechas de llamadas.
12. evaluaciones de control se muestran como "arriba y por encima".

Evaluaciones de entrada se muestran como "abajo y por debajo".


Mecanismo evaluaciones se muestran como "abajo y por debajo".

13. El extremo no conectado de una flecha lmite tendr el cdigo de


ICOM adecuada especificando su conexin a la caja de los padres, o
deber ser tunelizado.
14. Flechas de contorno abiertas que representan los mismos datos u
objetos sern conectado a travs de un tenedor para mostrar todos
los lugares afectados, a menos que esto se traduce en una diagrama

ilegible. Mltiples fuentes que representan los mismos datos u objetos


se unen para formar una sola flecha lmite de salida.

15. Caja de nombres y etiquetas de direccin no estar formada


nicamente por las siguientes palabras: funcin, actividad, proceso,
de entrada, salida, control o mecanismo.
3.3.4 Diagrama de referencia de las expresiones
Expresiones de referencia uso de cdigos que se asignan a las
caractersticas del modelo, tales como diagramas, cuadros, flechas y
notas. Expresiones de referencia luego pueden ser utilizadas en
diversos contextos que se refieren precisamente con cualquier
aspecto del modelo.
La unidad bsica de referencia es el nmero de nodo, que se aplica al
lugar donde funcionales descomposicin es modelado por el detalle
de una caja padre en un diagrama hijo. Todos los dems cdigos de
referencia se basan en los nmeros de nodo.
3.3.4.1 Nmeros Box
Cada caja en un diagrama deber ir numerada en la esquina inferior
derecha interior de la caja. Esta se requiere sistema de numeracin
para identificar de forma exclusiva las cajas dentro de un diagrama, y
para generar nmeros de nodo. Tambin se usa para entradas
descriptivas de referencia cruzada en el texto y glosario a la cajas en
un diagrama.
El nmero de carpeta en el cuadro individual en el contexto diagrama
A-0 ser de 0 (cero). La caja nmeros para las cajas en todos los
dems diagramas grficos sern 1, 2, 3, a un mximo de 6, a
nicamente identificar a los tres y seis cajas en cada uno de tales
diagramas. Para las cajas dispuestas en diagonal sobre la diagrama
de la esquina superior izquierda a la esquina inferior derecha, los
nmeros de la caja se asignan en orden, comenzando en la parte
superior izquierda. Si tambin se utilizan cajas de fuera de la
diagonal, la secuencia de numeracin comienza con la sobrediagonales cajas y luego contina, desde la parte inferior derecha, en
sentido contrario a las agujas del reloj.
3.3.4.2 nmeros de nodo
Un nmero de nodo se basa en la posicin de una caja en la jerarqua
del modelo. Normalmente, un nodo nmero se forma aadiendo un
nmero de apartado el nmero de nodo del diagrama en el que se
aparece. Por ejemplo, el nmero de nodo del cuadro 2 en el diagrama
A25 es A252. (Nodo Todos IDEF0 los nmeros comienzan con una
letra mayscula, como "A".) Cuando un cuadro se detalla mediante un

diagrama de nio, el El nmero de nodo de la caja padre se asigna


como el nmero de nodo del diagrama; Por lo tanto, el cuadro de los
padres y su diagrama hijo tiene el mismo nmero de nodo.
Diagramas de contexto y el nio diagrama de nivel superior son
excepciones a lo anterior nodo de numeracin esquema. Cada modelo
IDEF0 tiene un diagrama de contexto de nivel superior, el diagrama A0. Este diagrama contiene un nico "top box", que es la matriz nica
de todo el tema y lleva el modelado caja nica del nmero 0 (cero) y
el nmero de nodo A0. Cada modelo IDEF0 tendr, adems, al menos
tres, pero no ms de seis, cajas de nio en el diagrama hijo A0 que los
detalles de la parte superior de los padres A0 caja, esas cajas que
llevan el nico nmeros de nodo A1, A2, A3, a lo sumo a A6. Por lo
tanto, la secuencia [A0, A1, ..., A2, ..., A3, ...] se inicia el nodo de
numeracin para cada modelo.
Por ejemplo, un modelo puede tener los siguientes nmeros de nodo:

Los nmeros de nodo tambin se pueden usar como expresiones


detalle de referencia para indicar el detalle de una caja padre de un
nio diagrama. Si una funcin se ha descompuesto, el nmero de
nodo del nio Diagrama que detall que se puede escribir debajo de
la esquina inferior derecha de la caja padre. En Figura 7, los
exmenes rectales digitales (en este caso, los nmeros de nodo) para
cajas 1, 2 y 3 indican que han sido detallada e identificar los
diagramas nio.
3.3.4.2.1 ndice de Nodo
El ndice de nodo es un nodo de presentacin de la informacin en un
formato de "contorno". Todos los nmeros de nodo, junto con
cualquiera de los ttulos de diagramas o nombres de cuadros, se
presentarn en una forma dentada que exhibe la estructura
jerrquica anidada del modelo. Esto coloca a los diagramas
relacionados juntos en el Para utilizar en una Tabla de Contenidos
ordinaria, como se ilustra en la Figura 19.
A21 Programa Maestro de Desarrollo
A22 Desarrollo de coordinar el programa de
A23 Estimar los Costos y Presupuestos Hacer
A24 Monitor de rendimiento: Programar y Presupuesto
Fabricacin de productos A0
Plan de A1 para la Fabricacin
Hacer A2 y administrar programas y presupuestos

Plan de Produccin A3
A11 Identificar los mtodos de fabricacin
A12 estimado de requerimientos, tiempo, costo de produccin
A13 desarrollar planes de produccin
A14 desarrollar apoyo Plan de Actividades
Figura 19. ndice tpico nodo
3.3.4.2.2 rbol de nodos
El modelo IDEF0 desarrollado con su descomposicin estructurada
proporciona la base para esbozar la descomposicin completa en la
moda rbol de nodos en un solo diagrama grande. El uso de un rbol
de nodos es Opcional. El contenido del rbol de nodos ser idntico a
la del ndice de nodo o cualquier adecuado parte de los intereses.
No hay un formato estndar para la visualizacin real de la
informacin del nodo, excepto que el jerarqua se muestra
grficamente como un rbol con raz en un nodo elegido (por ejemplo,
A0 para el conjunto modelo). La Figura 20 proporciona una ilustracin.

Figura 20. rbol tpico nodo


3.3.4.3 Referencias de nodo
Cada diagrama en un modelo dispone de una referencia de nodo, que
identifica de manera nica y su posicin en el jerarqua del modelo. El
nodo de referencia se compone del nombre del modelo abreviado
(vase la Seccin 3.4.5) y el nmero de nodo del diagrama (vase la
Seccin 3.3.4.2), separados por una barra (/). Por ejemplo, un modelo
llamado Operaciones de garanta de calidad puede abreviarse como
control de calidad, y una referencia de nodo a continuacin, podra
ser QA / A312. Las referencias a un diagrama en el mismo modelo
pueden omitir el nombre del modelo abreviatura, utilizando
nicamente el nmero de nodo de diagrama.
Una referencia de nodo tambin puede tener un sufijo, por ejemplo, F
(para FEO), T (para el texto), o G (para el glosario), y una nmero de

pgina. Por ejemplo, un nodo de referencia para un FEO podra ser QA


/ A321F1 (ver Seccin 3.4.4).
3.3.4.4 Notas de modelos
Notas modelo son opcionales. Ellos se indican mediante un nmero
entero "n" dentro de una pequea caja cuadrada (n) Para un
diagrama dado, los nmeros de notas formar una secuencia
consecutiva, comenzando en 1. Vertical tuberas que rodean el
nmero de nota (| n |), se pueden utilizar como una notacin
alternativa.
Notas modelo proporcionan informacin que es relevante para (y una
parte integral de) el mensaje de un diagrama, pero que no encaja
convenientemente en la sintaxis de caja y flecha. Si el texto de la
nota es aplicarse a varios lugares o varias caractersticas del
diagrama, el nmero de nota en caja (sin texto) puede ser copiado y
puede estar unido por un garabato IDEF0 a cada punto de aplicacin,
pero slo en el diagrama nica en la que aparece el texto de la nota
modelo.
3.3.4.5 Referencia de la notacin
Una notacin estndar se utiliza en el texto escrito y toma nota para
referirse a los diagramas y las partes especficas de diagramas. Las
referencias se basan en los nmeros de correo, nmeros de nodo,
cdigos de ICOM, y nota nmeros. La siguiente tabla proporciona
ejemplos de notaciones de referencia.

3.4 Modelos
3.4.1 Descripcin del modelo IDEF0

Una de las caractersticas ms importantes de IDEF0 como un


concepto de modelado es que gradualmente presenta niveles cada
vez mayores de detalle a travs de la estructura del diagrama que
comprende modelo. De esta manera, la comunicacin se mejora al
proporcionar al lector una bien delimitada- tema con una cantidad
manejable de detalle para aprender de cada diagrama.
Un modelo IDEF0 se inicia mediante la presentacin de todo el tema
como una sola unidad - una caja con externalarrow condiciones de
contorno que lo conectan con las funciones y recursos externos al
sujeto. Los caja nica se llama el "top box" del modelo. (Este cuadro
de arriba tiene nmero de nodo A0.) Dado que el top box nica de un
modelo IDEF0 representa al sujeto como un todo, el nombre
descriptivo en el cuadro es general. Lo mismo es cierto de las flechas
externas del modelo, ya que representan la juego completo de las
condiciones de contorno externo del sujeto en su conjunto, incluido el
acceso a soporte del mecanismo que proporciona medios adicionales
de rendimiento.
Diagramas Contexto
El diagrama en la que aparece el cuadro de la parte superior A0
representa el contexto del modelo y se llama una diagrama
contextual. El contexto mnimo para un modelo es el diagrama de
contexto especial con el nodo nmero A-0. El A-0 diagrama de
contexto slo tiene el cuadro de A0 superior denominada sola, con su
etiqueta flechas externos, y tambin las definiciones textuales del
punto de vista y el propsito del modelo. (La A-0 diagrama tiene
ningn cdigo de ICOM o tnel de flecha en los extremos no
conectados.)
A veces, sin embargo, con el fin de proporcionar una exposicin ms
completa de la ambiental contexto del modelo, un A-1 diagrama de
contexto opcional (que tiene la apariencia de una ordinaria, no
contexto, tambin se presenta el diagrama). En el diagrama de
contexto A-1, el cuadro de A0 toma el lugar de una de las cajas de
tres a seis numeradas (las otras cajas manteniendo su nmero de
caja esperado), por lo que el efecto es el de proporcionar un diagrama
de matriz completa (con tres a seis cajas) para la parte superior del
modelo
- La A1 a A6 nodos an cuando son hijos de la primera generacin. En
el caso en que un A-1 se utiliza diagrama de contexto, un diagrama
de contexto A-0 todava se presenta. Este diagrama A-0 todava tiene
slo el cuadro de arriba A0 sola llamada, con sus flechas marcadas
externos y tambin las definiciones textuales de Esta perspectiva y
propsito del modelo.
Diagramas de contexto son diagramas que tienen nmeros de nodo
de la forma "A-n" (con un signo menos incluido), donde n es mayor
que o igual a cero. Ordinario, diagramas de contexto no carecen del
signo negativo en sus nmeros de nodo. El nmero de la caja de la
caja superior del modelo (que representa el totalidad del objeto
modelado) siempre es 0. Box nmero 0 deber figurar en la necesaria
A-0 diagrama de contexto del modelo, y figurarn tambin en la A-1
diagrama de contexto opcional (si lo hay) donde toma el lugar de una

de las cajas (1 a un mximo de 6) de dicha matriz (en todo el modelo)


A-1 diagrama. De este modo A0 es siempre el (compartido) nmero
de nodo de la caja padre y el nio diagrama de todo el modelo y
siempre es detallado por cajas con nmeros de nodo A1, A2, A3, a lo
sumo a A6.
Con una sola caja, A-0 es un diagrama de contexto adecuado, pero no
es una (correcta) Diagrama de los padres. Apropiado diagramas
tienen de tres a seis cajas. El contexto de los padres es la que
proporciona los nombres o contexto para un diagrama en el lugar de
un diagrama de matriz adecuado. El contexto de los padres de la A0
diagrama se requiere la A-0, si no hay un A-1 diagrama de contexto.
Si hay un contexto A-1 diagrama, A-1 es la matriz adecuada del
diagrama de A0. El contexto de los padres del contexto A-0
Diagrama siempre es "TOP".
3.4.3 Diagramas de contexto de alto nivel
Diagramas de contexto de alto nivel tienen nmeros de nodo de la
forma A-n, para n mayor que uno. As A-1 es un diagrama de
contexto, es un padre adecuado (de A0), pero no es de alto nivel. Para
un determinado modelo presentacin, el diagrama de contexto de
ms alto nivel (n grande) tiene contexto parental "NINGUNA", a
menos el diagrama de contexto de ms alto nivel es A-0.
Cada diagrama de contexto de alto nivel, A-n, sintcticamente es un
diagrama de detalle ordinario, excepto que uno de sus tres a seis
cajas tiene su nmero de buzn sustituye por "signo menos n-1", de
modo que, para A-1, que cuadro es el cuadro de A0 parte superior del
modelo, y el modelo en su conjunto (que en s cuadro de A0, el padre
de los nios) parece tener matriz A-1, A-2 por sus abuelos, etc.
Al proporcionar una descripcin ms completa del contexto ambiental
del modelo (no obstante, destinado a ser definitiva en todos los
aspectos, pero slo "tpico"), el modelado de contexto (que se
caracteriza por numeracin de nodo negativo) ofrece especificaciones
ms restrictivas-sobre las condiciones de contorno del diagrama A0
del modelo.
Modelado contexto procede igual que detalle el modelado ordinaria,
siendo la nica diferencia el numeracin negativo (y el no definitivo,
pero la interpretacin normativo) que conserva A0 como el "origen"
de la basada en el nmero-nodo del sistema de coordenadas para
todas las referencias de los modelos.
Todo el modelado de nodo nmero negativo se limita a establecer
ms y ms detalles acerca de la fuente y usos de las condiciones de
contorno externos. Ese detalle no puede ser emparejado con precisin
por cualquier entorno especfico en particular, completamente. Estos
diagramas de contexto describen el contexto "tpico".
La Figura 21 proporciona una ilustracin en forma de nodo de rbol
para mostrar contexto de alto nivel de lo rico que podra Aparecer.

Figura 21. Nodo contexto negativo con nmeros


3.4.4 FEOs, texto y Glosario
El esquema de numeracin de nodos proporciona la base para
coordinar trminos feos, texto y glosario.
Durante el desarrollo, es importante que cada nuevo elemento de
informacin se asocie con el nodo que lo trajo en consideracin.
Para cada forma (Feos, el texto y el glosario), la notacin extensin
nodo de numeracin consiste en una sola letra adherido al nmero de
nodo asociado. Por ejemplo, los nmeros de nodo para FEOS
contendr una "F" para FEO (por ejemplo, A312F).
Algunos usuarios IDEF0 rcord glosario con definiciones sobre las
formas de diagramas IDEF0, aunque el uso de este No se requiere el
formulario de glosarios. En este caso, una pgina glosario definir las
palabras clave, frases y acrnimos utilizados con un nodo en
particular IDEF0, asociada. Los nmeros de nodo para tales glosarios
pginas incluirn una "G" para el glosario (por ejemplo, A312G).
Del mismo modo, algunos usuarios IDEF0 registran sus observaciones
sobre los IDEF0 formas de diagrama, aunque el No se requiere el uso
de esta forma de texto. En este caso, una pgina de texto
proporcionar a los comentarios de texto para un nodo IDEF0
particular asociado. Los nmeros de nodo para este tipo de pginas
de texto incluirn una "T" para el texto (por ejemplo, A312T).
Si hay ms de uno, glosario o texto de la pgina FEO asociado con un
nodo IDEF0 dado, el las pginas deben ser designados con un nmero
adicional para identificar de forma nica cada uno (por ejemplo,
A312F1, A312F2, ... A312G1, A312G2, ..., A312T1, A312T2, ...).
3.4.5 Nombre del modelo
Cada modelo tiene un nombre nico y descriptivo que lo distingue de
otros modelos con los que se puede estar asociada. Este nombre del
modelo se abrevia normalmente (nica) para su uso en el nodo
referencias. Por ejemplo, un modelo llamado operaciones de
fabricacin se puede abreviar MFG.

Ver la Seccin 3.3.4.3 para una discusin de las referencias de nodo.


3.4.6 Reglas de Presentacin
1. Cuando hay un texto, deber llevarse en el diagrama de grfico
asociado.
2. En los modelos no publicacin, el glosario asociado a un grfico
especfico
Diagrama acompaar el diagrama y definir slo las palabras clave,
frases y acrnimos utilizados con el nodo en particular.
3. En modelos de publicacin, un glosario definir las palabras clave,
frases y siglas en orden alfabtico para todo el modelo.
4. Cuando se proporciona una tabla de contenidos para un modelo,
que se presenta como un nodo ndice de rbol o nodo, y contendr los
nmeros de nodo, ttulos y nombres de cuadros de diagrama.
ANEXO A - CONCEPTOS IDEF0
Antecedentes A.1
El deseo de la Fuerza Area de EE.UU. para reducir los costes y los
plazos de entrega, ayudando a la industria aeroespacial la industria
en sus esfuerzos de modernizacin se evidencia en sus muchas "Tech
Mod" (Tecnologa programas de modernizacin). Un objetivo similar,
pero utilizando un objetivo de toda la industria en lugar de empresas
individuales, se estableci bajo el ICAM (Integrated Computer Aided )
Programa de fabricacin. En ICAM, el objetivo era desarrollar
"subsistemas genricos", que podra ser utilizado por un gran nmero
de empresas para proporcionar una mejora significativa de la
industria en su todo. Estos "subsistemas" proporcionan soporte para
funciones comunes tales como la gestin de informacin, tienda de
programacin de suelo y manejo de materiales.
Este ambicioso objetivo necesita un vehculo de comunicacin "de
referencia" comn en torno a la cual planificar, desarrollar e
implementar los subsistemas en las empresas del sector aeroespacial
individuales. La lnea de base fue llamada la "Arquitectura de
fabricacin", ya que era para proporcionar un nivel industrial
"Arquitectura" que muestra cmo funciona la industria hoy en da y
en torno al cual subsistemas genricos podra ser planeado,
desarrollado e implementado.
Para desarrollar la arquitectura, se necesitaba una "lengua" en el que
expresar y actual documento operaciones de la industria
aeroespacial. Al comienzo de la ICAM, la Fuerza Area ha emitido una
solicitud de Propuesta para construir la arquitectura. Una tcnica de
modelado de la actividad se especifica como el lenguaje expresivo
(donde se define una actividad como una clula de fabricacin o
unidad operativa).
Para tener xito, el lenguaje tuvo que cumplir los siguientes criterios:
Dado que la arquitectura era para representar fabricacin, que tena
que ser capaz de expresar operaciones de fabricacin en una forma
natural y directa.
Puesto que el tema era tan vasto y complejo, que tena que ser
conciso y proporcionar un medio directo para localizar datos de
inters con facilidad y rapidez.

Ya que era para ser utilizado por una amplia audiencia, que tena
que ser capaz de comunicarse con una amplia variedad de personal
de la industria aeroespacial, as como a la Fuerza Area ICAM
Personal de la oficina del programa.
Ya que era para servir como lnea de base para la planificacin del
subsistema de genricos, el desarrollo y la aplicacin, tena que
permitir suficiente rigor y precisin para asegurar
Los resultados ordenados y correctos.
Desde el inicio del estudio fue que se desarrolla a travs del
esfuerzo cooperativo de un gran segmento de la industria
aeroespacial, tena que incluir una metodologa (y reglas
procedimientos) para su uso que permita muchos grupos diversos
para desarrollar piezas de arquitectura y que permitira extendida
opinin, la crtica y la aprobacin.
Desde el inicio del estudio fue para representar a toda la industria
aeroespacial en lugar de cualquier una empresa o segmento de la
industria, la tcnica tenan que incluir un medio de separar
"organizacin" de "funcin"; es decir, un acuerdo comn no poda
lograrse si las diferencias de organizacin de las empresas
individuales eran separa y slo el hilo funcional comn fue capturado.
El SADT (Structured Anlisis y Diseo Technique) desarrollado
originalmente en 1972 por Douglas T. Ross, de SofTech, fue
seleccionado como el "El Mtodo Arquitectura" para su uso en el aire
Fuerza Computer Aided Manufacturing Proyecto (AFCAM). La tcnica
de modelado actividad era ms desarrollados y utilizados en el
seguimiento de Programa ICAM Parte I. La principal subconjunto de
esta tcnica utilizada por la Oficina del Programa ICAM Parte II fue
posteriormente re-nombrado y documentado como "IDEF0".
A.2 Conceptos IDEF0
Los originales IDEF0 metodologa incorpora los conceptos bsicos que
se refieren a cada una de las necesidades listados arriba. Estos
conceptos bsicos IDEF0 son:
1. Representacin actividad de modelado grfico. Los grficos
de "cajas y flechas" de un IDEF0 el diagrama muestra el proceso de
fabricacin en la caja, y las interfaces a / desde el operacin que las
flechas de entrada / salida de la caja. Con el fin de ser capaz de
expresar la vida real las operaciones de fabricacin, las cajas pueden
interpretarse como que operan con otras cajas, con las flechas que
proporcionan la interfaz de "limitaciones" en cuanto a las operaciones
de cundo y cmo se activan y controlada.
2. La concisin. La documentacin de una arquitectura de
fabricacin debe ser concisa de permitir que abarque la materia. El
lineal, caracterstico detallado de ordinario texto en el idioma es
claramente insuficiente. La forma de dos dimensiones proporcionada
por una lenguaje modelo similar tiene la concisin deseado sin perder
la capacidad de expresar relaciones, tales como interfaces,
retroalimentacin y caminos de error.
3. Comunicacin. Hay varios conceptos IDEF0 que estn diseados
para mejorar comunicaciones:
Los diagramas basados en muy simples cajas y flechas grficos.

Texto Ingls al cuadro (funcin) y especificar flecha significados


(datos u objetos).
Exposicin gradual de detalle, que ofrece una jerarqua con
importantes funciones en la parte superior y los sucesivos niveles de
sub-funciones revelando as delimitada-detalle ruptura.
Un ndice de nodo para la localizacin de los detalles dentro de la
estructura jerrquica de los diagramas.
Limitacin de detalle en cada diagrama sucesiva a no ms de seis
subfunciones para facilitar la comprensin del lector.
Diagramas compatibles con el texto y el glosario para aumentar la
precisin de la representacin grfica.
4. rigor y precisin. Las reglas de IDEF0 cumplir suficiente rigor y
precisin para satisfacer arquitectura ICAM necesita sin restringir
excesivamente el analista. Normas IDEF0 incluyen:
Control de la exposicin en cada detalle (box rule 3-6) nivel.
Contexto Delimitado (no hay omisiones o adicional detalle fuera de
alcance).
Las reglas de sintaxis para grficos (cajas y flechas).
Singularidad de los nombres y las etiquetas en un diagrama.
Diagrama de conectividad (Detalle de la referencia Expresiones
[DRE]).
Conectividad de datos / cdigos de objetos (ICOM y flechas un
tnel).
Entrada frente a la separacin de control (regla para determinar el
papel de los datos u objetos).
Control mnimo de la funcin (todas las funciones requieren por lo
menos un control).
Flecha rama de restriccin (las etiquetas de los segmentos de
flecha) (o unirse a tenedor).
Requisitos de la etiqueta Flecha (reglas de etiquetado mnimo).
Propsito y punto de vista (todos los modelos tendrn una
declaracin de propsito y punto de vista).
5. Metodologa. Paso a paso se proporcionan procedimientos para el
modelado, examen y entrevista
Tareas.
6. Organizacin contra la funcin. La separacin de la organizacin de
la funcin se incluye en
El propsito del modelo y llevado a cabo por la seleccin de funciones
y etiquetas de flecha durante el desarrollo del modelo. Revisin
continua durante el desarrollo del modelo asegura que puntos de
vista de organizacin se evitan.
A.3 La discusin de los conceptos individuales IDEF0
En las sub-secciones restantes descripciones de algunos de los
conceptos bsicos son elaborados para aclarar ellos y muestran su
utilidad.
A.3.1 actividad de modelado de grficos
La metodologa IDEF0 se puede usar para modelar una amplia
variedad de automatizados y no automatizados "sistemas" o reas

temticas, incluyendo cualquier combinacin de hardware, software,


mquinas, procesos o personas. Para los nuevos sistemas IDEF0 se
pueden utilizar en primer lugar definir los requisitos y especificar las
funciones y, a continuacin para disear una implementacin que
cumple con los requisitos y realiza las funciones. Para los sistemas
existentes, IDEF0 se pueden utilizar para analizar las funciones de las
sistema lleva a cabo y para registrar los mecanismos (medios) por el
cual estos se realizan.
El resultado de aplicar IDEF0 es un modelo. Un modelo consta
de diagramas, texto y un glosario, una referencia cruzada entre s. Los
diagramas son los principales componentes de un modelo. Todas las
funciones y las interfaces se representan como cajas (funciones) y
flechas (datos o interfaces de objetos) en diagramas.
La posicin en la que la flecha se une a una caja transmite el papel
especfico de la interfaz. Los controles entran en la parte superior de
la caja. Las entradas, los datos u objetos de decisiones del
funcionamiento, entrar en la caja de la izquierda. Las salidas de la
operacin abandonan el lado derecho de la caja.
Mecanismo de flechas que proporcionan medios de soporte para
realizar la funcin join (apuntan a) la parte inferior de la caja. Flechas
de llamadas, un tipo de mecanismo de flecha que permite el
intercambio de detalle entre los modelos o entre porciones del mismo
modelo, se conectan a la parte inferior de la caja y apuntar hacia
abajo. Estas posiciones de flecha se ilustran en la Figura A1.

Figura A1. Caja de funcin y datos / Objetos flechas


Estos significados de cajas y flechas se utilizan para relacionar varias
subfunciones en un diagrama que comprende una funcin ms
general. Este diagrama es un "diagrama de restriccin", que muestra
la especfica interfaces que limitan cada sub-funcin, as como las
fuentes y destinos de la interfaz limitaciones (Figura A2).

Figura A2. Diagramas de restriccin


En la Figura A2, funcin B est limitada por una entrada y dos
controles, y produce una sola de salida, lo que limita la funcin C.
Aqu, el trmino "restricciones" significa que una funcin utiliza los
datos u objetos que se muestran de entrar en el caja, y por lo tanto,
est limitado de operar por la interfaz; la funcin no puede actuar
hasta el contenido de la flecha interfaz se proporcionan, y la forma en
que la funcin opera depende de los detalles (valor, nmero, etc.) de
los contenidos de la flecha de la interfaz.
A.3.2 Comunicacin por la exposicin gradual de Detalle
Una de las caractersticas ms importantes de IDEF0 es que
gradualmente introduce una mayor y una mayores niveles de detalle
a travs de la estructura diagrama que comprenden el modelo. De
esta manera, la comunicacin se ve reforzada por proporcionar al
lector con un tema bien delimitado, con una cantidad manejable de
nueva informacin para aprender de cada diagrama.
La estructura de un modelo IDEF0 se muestra en la Figura A3. Aqu,
una serie de cuatro diagramas es se muestra con la relacin de cada
diagrama a los otros.
Un modelo IDEF0 comienza mediante la representacin de todo el
sistema como una sola unidad - una caja con la flecha interfaces a
funciones fuera del sistema. Desde la caja nica representa el sistema
o sujeto rea como un todo, el nombre descriptivo escrito en el
cuadro es general. Lo mismo es cierto de la flechas de interfaz, ya
que tambin representan el conjunto completo de interfaces externos
al sistema como entero. El diagrama con la caja nica se llama el
"diagrama de contexto", y definir en el texto el punto de vista y el
propsito del modelo.

Figura A3. Estructura Modelo IDEF0


El cuadro que representa el sistema como un nico mdulo es
entonces detallada sobre otro diagrama con cajas conectadas por
flechas de interfaz. Estas cajas representan los principales subfunciones de la sola funcin madre. Esta descomposicin revela un
conjunto completo de funciones secundarias, cada una representada
por una caja cuyos lmites estn definidos por las flechas de la
interfaz. Cada uno de estos sub-funciones puede haber descompuesto
de forma similar para exponer an ms detalle. En IDEF0, se utiliza la
siguiente terminologa:
Funciones se "descomponen"; las cajas que representan funciones
son "detallada".
Un cuadro, si se detalla, siempre se detalla en un diagrama nio en
no menos de tres cajas, pero sin ms de seis cajas. El lmite superior
de seis obliga al uso de una jerarqua para describir complejo
asignaturas. El lmite inferior de tres asegura que el detalle suficiente
se introduce para hacer la descomposicin (detalle) de inters.
Cada diagrama en un modelo se muestra en la relacin precisa a
otros por medio de diagramas interconexin de flechas. Cuando una
funcin se descompone en sub-funciones, las interfaces entre las
subfunciones se muestran como flechas. El nombre de cada cuadro
de subfuncin ms su las interfaces marcadas definen un contexto
acotado para ese sub-funcin.

En todos los casos, cada sub-funcin se limita a contener slo


aquellos elementos que se encuentran dentro de la alcance de su
funcin madre. Subfunciones son discretos y no se superponen.
Adems, el coleccin de sub-funciones no puede omitir cualquier
elemento. Por lo tanto, como ya se ha indicado, la caja padre y sus
interfaces proporcionan un contexto para su nio diagrama. A
excepcin de las flechas de tnel, nada pueden ser aadidos o
eliminados de este lmite preciso.
A.3.3 El trabajo en equipo disciplinado
La metodologa IDEF0 incluye procedimientos para el desarrollo y la
crtica de los modelos por un gran grupo de personas, as como la
integracin de subsistemas de apoyo en una arquitectura IDEF0.
Procedimientos de apoyo adicionales, como las normas y
procedimientos bibliotecario, y el ciclo de revisin (vase Anexo C)
procedimientos tambin se incluyen en la metodologa IDEF0. (Cabe
sealar que algunos de estas normas y procedimientos, como el Ciclo
de kit o procedimientos Ciclo de crtica lector-autor, se utilizan
tambin con otras tcnicas IDEF).
La creacin de un modelo IDEF0 es el ms bsico de estos
procedimientos de trabajo en equipo "disciplinado".
La creacin de un modelo es un proceso dinmico, que por lo general
requiere la participacin de ms de una persona. A lo largo de un
proyecto, los autores crean diagramas iniciales que se distribuyen a
los miembros del proyecto para su revisin y comentarios. La
disciplina requiere que cada persona espera hacen comentarios
acerca de un diagrama debern hacerlas por escrito y presentarlos al
autor de la diagrama. El autor responde, tambin por escrito. Este
ciclo contina hasta que los diagramas, y finalmente, todo el modelo,
se acepta oficialmente.
IDEF incluye procedimientos para mantener registros escritos de
todas las decisiones y enfoques alternativos medida que se
desarrollan durante el proyecto. Las copias de los diagramas creados
por un autor son criticadas por lectores con conocimientos que
documentan sugerencias directamente sobre las copias. Autores
responden a cada comentario por escrito en la misma copia. Las
sugerencias son aceptadas o rechazadas por escrito junto con el
razonamiento utilizado. A medida que se realizan cambios y
correcciones, versiones no actualizadas de diagramas se conservan
en los archivos del proyecto.
Los diagramas se cambian para reflejar las correcciones y
comentarios. Ms detalle se aade a la modelo mediante la creacin
de ms diagramas que tambin son revisados y cambiados. El modelo
final representa un acuerdo sobre una representacin del sistema o
rea temtica desde un punto de vista determinado y para un
propsito dado. Esta representacin puede ser leda fcilmente por
otras personas fuera del inicial proyecto, que se utiliza para la
presentacin de la definicin del sistema de breves resmenes en pie,
o bien en paseos virtuales, y para la organizacin de nuevos
proyectos para trabajar en los cambios del sistema.

ANEXO B - la creacin e interpretacin IDEF0


ESQUEMAS
B.1 diagramas IDEF0 lectura
Un modelo se compone de una coleccin de diagramas y materiales
asociados dispuestos en una jerrquica manera. Se proveer un
ndice de nodo (o tabla de contenidos). La colocacin de los
diagramas de las orden jerrquico proporciona una visin general del
modelo y permite el acceso a cualquier parte.
La lectura se realiza de arriba hacia abajo, teniendo en cuenta cada
diagrama como un contexto delimitado por la caja padre.
Despus se leen los diagramas de nivel superior, diagramas de primer
nivel se leen, entonces diagramas de segundo nivel se leen, etc. Si se
necesitan detalles especficos acerca de un modelo, el ndice de nodo
se utiliza para descender a travs de los niveles en el diagrama
requerido.
Cuando se public, un modelo est ligado en formato de "pgina de
par" y el orden "ndice de nodo". "Pgina de par" formato significa
que cada diagrama y todo el texto asociado a l aparecen en un par
de frente pginas. (Figura B1).

Figura B1. Pgina de par Formato


"ndice de nodo" orden significa que se presentan todos los diagramas
nio relacionado con una casilla en un diagrama antes de que los
hijos de la siguiente caja. Esto coloca a los diagramas relacionados
juntos en el mismo orden utilizado en una mesa comn de
contenidos. (Figura B2).
Plan de A0 para la Fabricacin
A1 suponen una estructura y forma de Mfg.
Requisitos
A2 Estimar, costo, tiempo para producir
A21 Recursos que necesita Estimacin
A22 estimar los costos de comprar o hacer
A23 estimacin de temporizacin de inicio y Produccin

A3 desarrollar planes de produccin


A4 Desarrollar Plan de Actividades de Apoyo
Figura B2. ndice de nodo que muestra el diagrama de pedido
B.1.1 Acercarse a un modelo
Los modelos proporcionan una visin general de todo el sistema o
rea temtica, as como detalles de un particular, tema. Para leer un
modelo para su informacin general, utilizar el ndice para encontrar
todos los diagramas de alto nivel. (Figura B3.)
Fabricacin de productos A0
Plan de A1 para la Fabricacin
A11 Supongamos una estructura y mtodo de Mfg.
A12 estimado de requerimientos, tiempo, costo de produccin
A13 desarrollar planes de produccin
A14 desarrollar apoyo Plan de Actividades
A2 Realizar y Administrar Horarios y Presupuestos
A21 Programa Maestro de Desarrollo
A22 Desarrollo de coordinar el programa de
A23 estimar los costos y hacer el presupuesto
A24 Monitor de rendimiento de Programacin y Presupuesto
Plan de Produccin A3
Figura B3. ndice de nodo Mostrando general Diagramas
Para leer un modelo para el detalle, utilizar el ndice para encontrar
todos los diagramas que detallan el tema de inters.
(Figura B4).
Fabricacin de productos A0
Plan de A1 para la Fabricacin
A11 Supongamos una estructura y mtodo de Mfg.
A12 estimado de requerimientos, tiempo, costo de produccin
A13 desarrollar planes de produccin
A14 desarrollar apoyo Plan de Actividades
A2 Realizar y Administrar Horarios y Presupuestos
A21 Programa Maestro de Desarrollo
A22 Desarrollo de coordinar el programa de
A23 estimar los costos y hacer el presupuesto
A24 Monitor de rendimiento de Programacin y Presupuesto
Plan de Produccin A3
Figura B4. ndice de nodo que muestra el diagrama detallado
especfico
Ms detalles en un modelo pueden ser rastreado por referencia a la
expresin detalle de referencia (DRE) justo por debajo del nmero de
la caja. Esto indica el nmero de nodo, C-nmero o el nmero de
pgina del diagrama hijo que detalla la caja. En el siguiente ejemplo,
los detalles de la caja 3 en el diagrama A24 puede se encuentra en un
diagrama con el nmero de nodo A243. Si no aparece la DRE, el
cuadro an no ha sido detallado.

Los detalles pueden ser compartidos dentro de un modelo o entre


diferentes modelos. En ambos casos, una flecha de llamada
(Apuntando hacia abajo) indica donde l aparece detallando
compartidos a travs de una expresin de referencia que puede
incluir un nico, abreviada modelo melena. En el siguiente ejemplo, la
casilla 4 es detallado por diagrama A4 en el modelo MQ. En este
ejemplo, la expresin de referencia es un nodo de diagrama
referencia.

B.1.2 Diagrama de lectura Pasos


La informacin precisa acerca de un sistema se encuentra en los
propios diagramas. La siguiente lectura
Se recomienda secuencia:
1. Analiza las casillas del diagrama para obtener una impresin de lo
que se est describiendo.
2. Vuelva a consultar el diagrama de matriz y tenga en cuenta las
conexiones de flecha a la matriz caja. Trate de identificar un "ms
importante" de entrada, control y salida.
3. Considerar las flechas del diagrama actual. Trate de determinar si
hay un principal ruta que une la entrada "ms importante" o el control
y el "ms importante" salida.
4. mentalmente caminar a travs del diagrama, desde la parte
superior izquierda a la inferior derecha, con el principal camino como
gua. Tenga en cuenta cmo otras flechas interactan con cada caja.
Determinar si hay caminos secundarios. Compruebe la historia que se
cuenta en el diagrama de teniendo en cuenta cmo se manejan las
situaciones familiares.
5. Compruebe si existe un diagrama FEO relacionada.
6. Por ltimo, lea el texto y glosario, si se proporciona.
Esta secuencia se asegura de que las caractersticas principales de
cada diagrama reciben atencin. El texto se llamar la atencin a
cualquier cosa que el autor desea destacar. El glosario se definir la
interpretacin del autor de la terminologa utilizada.
Cada diagrama tiene un tema central, que va desde el lmite ms
importante flecha entrante a los ms importantes lmites flecha de
salida. Este camino principal a travs de las cajas y flechas describe
la funcin principal del diagrama. (Figura B5.) Otras partes del
diagrama representan condiciones de calificacin o alternativos que
son secundarios a la ruta principal.

Figura B5. Ejemplo de trayectoria principal


El funcionamiento del sistema puede ser mentalmente lo previsto por
seguir el camino principal. Tipos especficos de entradas de datos, el
manejo de errores y posibles salidas alternativas prestan detalle a la
historia. Esta walk-through mejora la comprensin de los diagramas.
B.1.3 Semntica de las cajas y flechas
La idea fundamental que debe guiar la interpretacin de cualquier
diagrama o un conjunto de diagramas es: Slo aquello que est
expresamente especificado est necesariamente implicado. Esto se
deriva de la propia naturaleza de diagramas de restriccin.
Restricciones no especificadas no deben ser asumidas; restricciones
necesarias deben ser explcitas. El corolario es que: Cualquier detalle
adicional no explcitamente prohibido es implcitamente permitido.

Figura B6. Ejemplo de restriccin


Un supuesto se puede hacer usando la figura B6 que la temperatura
se mide "con bastante frecuencia" y las tolerancias se cambian
"cuando sea apropiado" y la temperatura se controla en contra de la

tolerancias "con bastante frecuencia" que se va a producir la seal de


peligro "muy pronto". Ninguno de esas comprensiones intuitivas
entraran en conflicto con la posterior detallando que mostr que:
a. la temperatura se mide por muestreo peridico, o segundo. Solo se
pidieron tolerancias actuales cuando la temperatura aumenta por
alguna cantidad fija, o do. Una serie de valores de temperatura
producidos por el cuadro 1 se almacena en la casilla 2, que
examinaron el patrn de cambio para determinar si el patrn estaba
dentro de la tolerancias, etc.
Las notaciones grficas de un diagrama son, por s mismos, resumen.
Sin embargo, ellos hacen importantes distinciones fundamentales. Su
naturaleza resumen no debe interferir con la intencin una gama de
posibles interpretaciones que estn permitidos.
Restricciones Omitir cmo y cundo
Cualquiera de las dos representaciones:

Dice que: a2 actividad depende de "d" que es creado o modificado


por la actividad a1.
Cada representacin define una relacin de restriccin entre las dos
cajas. Todo lo que es indique explcitamente por la flecha intermedio,
ya sea para la representacin se expresa como sigue: algunos la
activacin de la casilla 2 requiere algo llamado "d" que se produce
por alguna de activacin de la casilla 1.
Con frecuencia, los diagramas implican fuertemente que dos o ms
cajas pueden necesitar el contenido de una flecha.
El significado de las cajas y flechas que se muestran en la Figura B7
es que algo producido por la caja 1 es necesario en la casilla 2 y por
el cuadro 3. Puede ser que una activacin de la "fuente" de la flecha
(cuadro 1) debe preceder a cada activacin de su "destino" (casilla 2
o caja 3). Puede ser que una activacin de la fuente es suficiente para
cada activacin de cualquier destino. Sin informacin adicional, las
cajas y flechas permiten por s solos, ya sea interpretacin.

Figura B7. Dos cajas utilizando el contenido de la misma


flecha

B.1.3.2 Las mltiples entradas y salidas, controles


La interpretacin de base de la caja se muestra a continuacin (Figura
B8) es: Con el fin de producir cualquier subconjunto de las salidas
[O1, O2, O3], cualquier subconjunto de las entradas [I1, I2, I3, C1, C2,
C3, C4, M1, M2, M3] puede ser requerido. En ausencia de detallar ms
que no se puede asumir que:
a. cualquier salida puede producirse sin todas las entradas presentan,
o segundo. Cualquier salida requiere que todas las entradas para su
produccin.

Figura B8. Ilustracin de codificacin ICOM


El parcial que detalla del cuadro anterior (mostrado en la Figura B9,
como podra parecer en un FEO diagrama) indica que I3, C2, C3 y C4
no son necesarios para la produccin de O1. Figura B9 ilustra los
puntos que:
a. alguna forma de detallar ms especificar la relacin exacta de
los insumos y controles a las salidas;
b. Hasta que se proporciona el detalle, la limitacin de los
supuestos acerca de las relaciones "dentro" cada caja no debe
hacerse;
c. lectura de un diagrama debera concentrarse en las flechas, que
son explcitas, en vez que en nombres de cuadros, que slo
estn implcitos.

Figura B9. FEO que representa detalle de mltiples ICOM


B.2 Gua del autor para la creacin de diagramas IDEF0
Al crear cualquier diagrama IDEF0, los requisitos que debe cumplir
son las siguientes:
a. su propsito y punto de vista coincidir con el propsito declarado
y el punto de vista del modelo general;
b. sus flechas de contorno correspondern a las flechas que conectan
a su caja padre;
c. su contenido deber ser exactamente todo en su caja padre.
B.2.1 Pasos bsicos de Autora
La disciplina paso a paso de autora hace posible la creacin de
diagramas que forman til y modelos coherentes. La disciplina para
seguir es:
a. Bound la materia con mayor precisin que el nombre de la caja de
funciones sugiere. Esto se hace con una lista de datos y objetos ni
actuar de procesado por el funcin.
b. Estudiar el conjunto acotado de la materia y formar posibles subfunciones de la funcin total.
c. Buscar patrones naturales de conexin de dichas subfunciones.
d. Divisin y racimo subfunciones para hacer cajas adecuadas.
e. Dibuje una versin final del diagrama con una cuidadosa atencin a
la disposicin y la claridad.
B.2.1.1 Seleccin de un contexto, Punto de vista y Propsito
Antes de comenzar cualquier modelo, es importante para determinar
la orientacin del modelo. Esto incluye el contexto, punto de vista y el
propsito. Estos conceptos guan y limitan la creacin de un modelo.
Si bien pueden ser refinados a medida que avanza de autor, deben
ser consistentes a lo largo de un modelo si su orientacin es
permanecer claro y sin distorsiones.
El contexto establece el objeto de la modelo como parte de un todo
mayor. Se crea un lmite con el medio ambiente mediante la
descripcin de las interfaces externas. El diagrama de contexto
establece el contexto para el modelo.
El punto de vista determina lo que puede ser "visto" en el contexto, y
de lo "inclinacin" o perspectiva. Dependiendo del propsito,
diferentes puntos de vista pueden ser adoptados que hacen hincapis

diferentes aspectos del tema. Slo hay un punto de vista segn el


modelo.
El propsito establece la intencin del modelo o el objetivo de la
comunicacin que sirve.
Propsito encarna la razn por la cual se crea el modelo
(especificacin funcional, aplicacin diseo, las operaciones del
cliente, etc.).
El punto de partida para todos los anlisis es obligado el contexto.
Decidir lo que la atencin se centra antes de ser creadla caja ms
alta. Cuidado con los flotantes fuera de este dominio de partida
seleccionado cuidadosamente. Cada paso deber cotejarse con el
propsito de partida. Cosas que no encajan pueden observarse para
ms tarde modelado de los puntos de vista relevantes. La claridad se
deriva de los rigores de detallar. Saber hasta qu punto ir, cundo
parar, cundo cambiar de marcha y cmo encajan las piezas siempre
depender de la finalidad para la que se crea un modelo.
B.2.1.2 Creacin del diagrama de contexto
Para iniciar un modelo, crear el diagrama A-0. Dibuje una sola caja
que contiene el nombre de la funcin que abarca todo el mbito de
aplicacin del sistema que se describe. Uso de insumos, control y
flechas de salida entran y salen de la caja para representar los datos
y el objeto interfaces del sistema a su medio ambiente. Este
diagrama de un solo cuadro delimita el contexto de todo el modelo y
constituye la base para nuevos esfuerzos de descomposicin.
Establecer el propsito y punto de vista sobre A-0 diagrama
contextual.
Algunos autores encuentran que es ms fcil dibujar el A0 y luego
dibujar la caja y de interfaz individuales flechas se muestra en el nivel
A-0. Puede ser necesario cambiar de diagramas de esfuerzos de ida y
vuelta entre A-0 y A0 varias veces para obtener un buen inicio de la
descomposicin.
Si el diagrama A-0 ha comenzado en un nivel demasiado bajo de
detalle, hacer que el cuadro A-0 la base de una nueva nivel de
diagrama de A0. Subir un nivel a un nuevo A-0 y volver a visitar el
Mirador y Propsito declaraciones. Repita este proceso hasta que se
lleg a un A-0, que tiene un margen suficiente para cubrir la totalidad
aspectos del sistema. (A veces, un nivel tan alto ampliar en lugar de
aclarar el elegido punto de vista. Si es as, crea un cuadro de
mltiples diagrama de contexto A-1 y mantener el diagrama de A0 a
la intencin original.)
B.2.1.3 La creacin de la mayora de Top-Diagrama
Todas las funciones del sistema se encuentran dentro de la caja sola
muestra en el diagrama A-0. Los lmites del diagrama el contexto del
sistema. El diagrama A0 descompone la funcin nica en el diagrama
A-0 en sus tres a seis principales sub-funciones.
El verdadero "top" del modelo es el diagrama A0. Su estructura
muestra claramente lo que el diagrama A-0 intentado decir. Los
trminos y la estructura de A0 tambin obligados todos los niveles
posteriores, ya que es una descripcin completa del tema elegido. Los

niveles ms bajos delinean las funciones A0 (cajas). Si El propsito del


modelo es que debe lograrse, esta cadena de detalle se debe seguir
cuidadosamente cada paso. Comenzando en la parte superior es el
reto de la creacin. Obliga al autor para mantener un nivel de
abstraccin, a mantener una profundidad uniforme de modelo y de
relegar los detalles a un nivel inferior.
B.2.1.4 Creacin Nio diagramas
Para formar la estructura de los diagramas, detalle cada caja en el
diagrama A0 en sus tres los seis problemas principales partes. Formar
un nuevo diagrama para cada caja, que cubre el mismo tema que su
caja padre pero en mas detalle.
Al detalle cada caja de 3 a 6 cajas nio, obtener los datos adicionales
necesarios. Crear un primer borrador Diagrama enumerando primero
todos los datos y objetos relacionados con la funcin que se
descompone. Cudate que la lista abarca todo el tema de la caja
padre de modo que ninguna parte se pierde en el descomposicin. A
continuacin, dibuje cajas de qu candidato asociado nombres de
sub-funcin con datos y objetos de la lista correspondiente, y dibujar
flechas entre las cajas.
Para derivar el diagrama ms clara posible, modificar o volver a
dibujar el diagrama varias veces hasta satisfecho. Split (romper una
caja en dos o ms partes) y el grupo (combinar dos o ms partes en
un solo cuadro) hasta que est satisfecho. Split y clster hasta que
usted expresa la funcin de los padres en tres para seis cajas.
Generar ms porciones de diagramas de niveles detallada para
explorar los puntos que deben aclararse.
Crear varios (3 o 4) diagramas como un conjunto, en lugar de un
diagrama a la vez.
B.2.1.5 La creacin de material de apoyo
Con el tiempo, cada diagrama ser acompaado por una pgina de
texto narrativo, glosario y, tal vez, FEOs. El texto asociado con el
diagrama A-0 debe completar la orientacin del modelo y es escrita
cuando se crea el diagrama A-0. El texto complementa el contexto
(expresada en A-0 s mismo) mediante la expansin en el punto de
vista indicado y propsito del modelo.
Texto para cualquier otro diagrama (incluyendo A0) es bastante
diferente. Cuenta una historia breve, concisa. Eso no duplique lo que
el diagrama ya dice por una mera descripcin de cada funcin en el
cuadro palabras, sino ms bien teje a travs de sus patrones. En
todos los niveles, este captura el punto de vista de un modo que
contribuya a propsito. Un diagrama grfico puede o no puede tener
un texto asociado diagrama.
El glosario explica las definiciones el autor da a las funciones y datos /
objetos en un diagrama.
Estas definiciones son importantes debido a que la terminologa
utilizada en el modelo puede tener un significado completamente
diferente en una empresa desde el significado en otra empresa.
Terminologa menudo difiere entre las unidades o disciplinas dentro
de la misma empresa.

Feos son diagramas que ponen de relieve un aspecto particularmente


interesante o sutil de un diagrama. Ellos no medie entre la caja y la
flecha sintaxis IDEF y pueden contener estructuras parciales de flecha
y notas para enfatizar su punto.
B.2.1.6 Seleccin de una caja de Detalle
Dado un diagrama de matriz completa, "concretar" los niveles ms
altos antes de comprometerse a un exceso de detalles.
Es decir, dado A0, hacen hincapi en el trabajo en A1, A2, A3.
Descomposicin de A1 a A11, A111, debe ser hecho ms tarde. Esto
evita el potencial de la reanudacin se debe hacer cambios a los
diagramas de nivel superior.
Mantener una profundidad uniforme no es una regla estricta. La
cantidad de profundidad en cualquier momento depende de si mayor
profundidad capturara significa mejor que un diagrama. No poner de
hacer un nivel ms bajo diagrama, por ejemplo, A111, pero boceto
mientras que las ideas son frescas. Lo importante es tratar a todos los
tales incursiones como bocetos hasta la tarde nivel "horizontal" se
confirma. Estar listo para volver a trabajar la parte inferior el material
de nivel si entra en conflicto con el nivel superior, por ejemplo, A1,
A2, A3.
Dos guas son tiles para decidir qu caja al detalle:
1. Comience con la "parte dura" - la parte que es menos
familiarizados o es menos clara.
2. Seleccione la casilla de cuyos detalles dar a la mayora de la
informacin acerca de otras cajas.
Los temas ms simples pueden descomponerse ms fcilmente
despus, con menos riesgo de error o descuido, y pueden ser
manipulados fcilmente para adaptarse a la descomposicin de los
problemas ms complejos.
B.2.1.7 Autor Actividades
Fase de la investigacin B.2.1.7.1
Leer Antecedentes: El autor recoge informacin sobre la materia
mediante la lectura de la fuente informacin.
Entrevista: El autor personalmente entrevistas un experto en la
materia.
Piense: digerir la informacin obtenida a partir de la lectura y
entrevistas antes de diagramas real comienza.
Recoger Box: Decidir qu caja es la adecuada al detalle basa en la
informacin obtenida.
Fase de estructuracin B.2.1.7.2
Draw: Esto abarca el proceso creativo real de generar un diagrama.
No se limita slo para dibujar cajas y flechas. Tambin incluye la lista
de elementos de datos aleatorios, haciendo bocetos, etc., que
preceden a las cajas de dibujo y flechas.
Re-draw: Esto cubre la etapa de diagramacin digestivo y
corresponde a la edicin y reelaboracin del texto verbal. La actividad
que aqu se ocupa no de la creacin, pero con grfica la edicin y la
reordenacin para mayor claridad.

Fix Maestro: Esto se aplica a la modificacin de planos maestros para


incorporar mejoras. Eso es principalmente una operacin mecnica, la
consolidacin de los resultados de re-dibujos separados, a menudo en
respuesta a los comentarios de los lectores.
B.2.1.7.3 Presentacin Fase
Escribir y editar texto: `texto que acompaa a cualquier diagrama
deben ser precisos. Edicin a menudo se aliviar detalle y la
redundancia innecesaria.
Ensamble: montar cualquier material, diagramas, rboles de nodos,
glosarios, texto, etc., correspondiente a la tema. Incluir una portada
completado.
Fase de Interaccin B.2.1.7.4
Reaccionar: Esto se refiere al autor reaccionar a los comentarios. Es
una combinacin de lectura y anotar las reacciones a los comentarios
en respuesta a los lectores.
Discusin: Esto representa el tiempo pasado cuando un autor y el
lector realmente se renen y hablan de autor reacciones a los
comentarios.
Las reuniones de grupo: Este es el tiempo empleado en reuniones de
grupos de la revisin del progreso o de intercambio de ideas prximos
pasos. Las actas de las reuniones de grupos identificarn el tema en
discusin.
B.2.2 Dibujo de un diagrama IDEF0
Creacin de diagramas es la actividad ms creativa y subjetiva del
proceso de modelado. Est abierto a amplias variaciones entre los
autores individuales. No hay un conjunto de medidas va a funcionar
igual de bien para todos autores. Los pasos que aqu se presentan son
una secuencia probada y estn diseados para ayudar a un nuevo
autor en la elaboracin de diagramas IDEF0.
a. Crear una lista estructurada todava relevante, pero no de datos.
elementos de la lista en el contexto de la caja padre que primero
vienen a la mente. Los elementos de grupo, si es posible, para
mostrar similitudes.
b. Nombre funciones que actan sobre los datos que se indican y
sacar las cajas alrededor de los nombres.
c. Dibuje flechas correspondientes. A medida que se dibuja cada caja,
deje la flecha "talones" para hacer el cuadro ms significativa. Hacer
conexiones completas como se hace evidente lo que el diagrama est
diciendo.
d. Proyecto de un diseo que presenta el cuadro ms claro y la flecha
arreglo. Haz junto flechas si la estructura es demasiado detallada.
Dejar slo los elementos esenciales, y modificar diagrama segn sea
necesario.
e. Crear texto, glosario y diagramas FEO, si es necesario, para poner
de relieve aspectos queson importantes. Proponer cambios, si es
necesario, en el diagrama de los padres.
B.2.2.1 Generacin Cajas de funcin

Cajas de funcin se generan utilizando los principales sub-funciones


de la matriz. Como subfuncin nombres estn escritos, dibujar cajas a
su alrededor para formar el inicio de un diagrama real. En este punto
el nmero de cajas es inmaterial. Pueden ser modificados por la
agrupacin y divisin de ajustarse a la regla de tres a seis caja.
La agrupacin de grupo de voluntad de dos o ms cajas para formar
una sola caja. Su objetivo es agrupar relacionados funciones en una
nica funcin, ms general. Elimina detalle prematuro que oscurece
la mensaje que se desea transmitir a este nivel.
La divisin se romper una sola caja en dos o ms partes. Es la
inversa de la agrupacin. Su objetivo es para proporcionar ms
detalles para presentar la suficiente comprensin del sujeto que se
descompone.
Revisar el resultado conjunto de cajas de funcin. Busque un buen
equilibrio entre los factores elegidos.
A ver si los nombres se pueden hacer ms especfica. Utilice los
trminos y abreviaturas slo cuando especiales necesaria para
promover la comunicacin con el pblico objetivo y slo en el
diagrama detallado los niveles. No los use en el ms alto (A-0 y A0)
en sangre. definir cuidadosamente los trminos especiales en el
glosario.
En todos los casos, hacer que la caja funcin de nombres verbos o
frases verbales. Siempre que la frase puede ser interpreta como un
verbo o un sustantivo, utilizan la notacin "(v)" para significar el uso
pretendido verbo.
Cajas
1. En la mayora de los casos, disear cajas en diagonal desde la
parte superior izquierda a la inferior derecha. Mientras que cualquier
disposicin que deja en claro la intencin del autor es aceptable,
vertical u horizontal formatos tienden a multitud flechas y
obstaculizan el buen estilo de anlisis estructurado.
2. Las cajas colocadas en la parte superior izquierda cajas "dominar"
colocan inferior y hacia la derecha a travs de las flechas de control
que los vinculan. Este estilo estndar hace que sea ms fcil para a
los lectores a entender su significado.
3. Nmero cada caja en su esquina inferior derecha en el interior.
Asignar los nmeros de caja en una Diagrama de izquierda a derecha
y de arriba a abajo. Esto ayudar a definir el nodo nmero para cada
cuadro. Las principales cifras del nmero de nodo completa de la caja
son el mismo que el nmero de nodo de este diagrama. El ltimo
dgito del nmero de nodo es este numero de caja. Si la casilla en la
Figura B10 aparece en el diagrama A4, entonces la completa
El nmero de nodo para este cuadro sera A42.

Figura B10. Nmero de caja y el nmero de nodo

4. En las copias de trabajo o de tiro, escribir el nmero de nodo o Cnmero inferior al ms bajo esquina derecha de cualquier caja que se
detalla. El C-DRE nmero indica la especfica versin del diagrama
que se pretende.
5. No diagrama puede contener ms de seis cajas.
B.2.2.2 Creacin Las flechas de interfaz
Flechas de interfaz de croquis de conexin a cada caja individual.
Conectar extremos de flechas para mostrar que da salida de
alimentacin que las entradas y controles.
Recordemos que los datos de entrada / objetos se transforman por la
funcin para producir la salida. Si una flecha contiene tanto de
entrada como de control de datos / objetos, lo muestran como un
control. Si no se sabe si una flecha es un control o una entrada, lo
convierten en un control. Si no est claro si es o no un particular de
datos o objeto de flecha se necesita en absoluto, dejarlo fuera (con tal
de que no es el nico control).
Flechas de salida muestran los resultados de posibles activaciones de
la funcin. La sintaxis para la salida flechas no indican qu patrones
de flechas de salida pueden producirse en qu circunstancias.
Si la secuencia es de particular inters, dibujar un FEO que ilustra el
patrn. no te preocupes por secuencia. Slo asegrese de que todos
los casos importantes son permitidos por el diagrama.
Grupos de lotes de flechas relacionados siempre que sea posible. El
error ms comn cuando se crea flechas es hacer que la estructura
de flecha o la flecha etiquetas demasiado detallada. El nivel de
detalle de flechas debe coincidir con el nivel de detalle de las cajas.
En niveles altos, ambos nombres de cuadros y la flecha etiquetas
sern general.
Como comprobacin final, comparar todas las flechas de la lista de
datos para asegurar que aparece cada elemento de datos correcto.
Elementos que no aparecen o bien no son apropiadas para este nivel
de detalle o se pasaron por alto al crear las flechas.
Piense control y restriccin, no fluye.
Una regla bsica para el diseo de la estructura de la flecha es
"limitar, no se secuencia." Es decir, que el estructura muestran
relaciones diagrama que deben ser verdaderas no importa qu
secuencia se sigue.
A pesar de que algo debe pasar de una etapa a otra para llegar a
algn resultado final deseado, tratar de expresar las limitaciones que
deben ser satisfechas o las propiedades invariantes que deben ser
verdaderas en lugar que algunos una secuencia especfica de etapas
que darn ese resultado.
La razn es que todas las cajas pueden ser activas simultneamente.
Por lo tanto, la secuencia no tiene ningn significado.
Siempre es ms potente para limitar que a secuencia. Siempre que
sea posible, debe diagramas se cree que decir lo correcto,
independientemente de qu medidas se toman por primera vez.

Claramente, esto es mejor de restringir slo a una de las posibles


secuencias.
A menudo, es ms fcil en un primer momento a pensar en acciones
sub-funcin en una secuencia particular para salir del atasco y
conseguir algo en el papel. Esto puede ser una buena manera de
ponerse en marcha, pero siempre reelaborar la primera intentar en
una estructura de restriccin.
Etiqueta cuidadosamente.
La subordinacin de los detalles innecesarios destaca las
significativas. No saturar sus diagramas con demasiada informacin y
demasiadas flechas. No gaste demasiado tiempo en un solo nivel.
Todo lo que no es necesario expresar a la vez para evitar ser
incompleta y mal entendido. Los puntos de la disciplina entera es
conseguir todo lo dicho, con el tiempo.
Adems, si hay demasiado en un diagrama, se vuelve rgido. Si se
permite que esto suceda, el diagrama se debilita. La fuerza viene de
la estructura. Esto se puede lograr dejando detalles a las
subfunciones. No iterar entre diagramas de alto nivel y sub-funciones
que llenan los detalles.
Dejar de lado las flechas cuestionables.
A menudo es difcil determinar si se debe mostrar una flecha o no. La
forma ms fcil de manejar la flecha pregunta, es "En caso de duda,
dejarlo fuera." Si la flecha no es realmente esencial para los
principales espina dorsal, si hay preguntas sobre el mismo, es
probablemente incorrecta incluirlo.
Omisin incorrecta de una flecha cuestionable ahora no causar un
dao permanente. La necesidad de la flecha ser ms claro al
considerar subfunciones y la disciplina ICOM obligar a laflecha hacia
atrs hasta este nivel. En ese momento, no habr ninguna duda al
respecto.
B.2.2.3 Nivel de Esfuerzo
El objetivo inicial en la generacin de un diagrama debe ser un
diagrama que representa una clara definida mensaje y no viola
ninguna regla de sintaxis. Cuando se termina el diagrama, las
directrices crticas de la lectura y la revisin por parte de otros se
pueden utilizar para mejorar el primer intento. La mayora de los
diagramas puede ser modificada para hacer una segunda versin que
se encuentra en algn sentido mejor que la primera. La primera
voluntad rara vez ser lo mejor.
A medida que se desarrollan los niveles de habilidad, primeros
diagramas mejoran y los autores se sienten ms cmodos usando
IDEF0.
Reelaboracin de diagramas siempre ser una parte necesaria del
proceso. La idea clave es usar un ciclo de revisin para avanzar en el
papel. En una serie de avances ordenada, todas las importantes
aspectos sern manejados adecuadamente.
IDEF0 es una metodologa de formacin de pensamiento, no slo un
ejercicio diagrama de decisiones. Poner los pensamientos en el papel

y dejar que la notacin y la disciplina en el trabajo es un paso hacia


una solucin satisfactoria.
Confiar en la capacidad de hacer buenas preguntas, y no en las
expectativas de proporcionar "perfecta" respuestas.
B.2.3 Re-Dibujo de un diagrama IDEF0
B.2.3.1 Modificacin de las cajas
Al crear primero un diagrama, 3-6 cajas de funciones de
aproximadamente el mismo nivel de detalle son derivado. La
agrupacin y divisin proporcionarn un lmite que se entiende ms
fcilmente o que proporcionar una interaccin ms sencilla entre las
cajas de funcin.
Muy a menudo, la agrupacin y divisin de trabajo en conjunto. Las
cajas se dividen y las piezas resultantes agrupados en nuevas cajas
que transportan ms de cerca el mensaje deseado. El mismo tema
cuestin est cubierto, pero las piezas se agrupan de una manera
ms comprensible.
Dividir y reformular.
Es importante que todas las cajas de un diagrama tengan un sabor
consistente. Los cambios en otros lugares no deben hacer una subfuncin existente parecer fuera de lugar. Dividir y reformular para
restaurar el equilibrio.
A veces, un cuadro no fluye con las otras cajas del diagrama actual.
Con frecuencia, el problema es que otros aspectos han sufrido
cambios y aclaraciones. Lo que antes era una buena idea, ahora tiene
la inclinacin equivocada o sabor.
Se divide el cuadro infractor mediante su divisin en dos o ms
piezas, una de las cuales contiene todava la esencia de la idea
original, pero de manera ms pertinente y concisa. Hacer esperar
para cambiar la redaccin de la caja (o cajas). Con la separacin, las
nuevas ideas se vuelven ms claras y ms de malla estrechamente
relacionados con las cajas.
Agruparse y reemplazar.
Una abstraccin slido es tanto ms clara y ms potente que el
detalle prematuro.
Cluster relacionados cajas y sustituir abarcando por una caja sencilla.
Con frecuencia, un buen nivel de abstraccin puede ser incluso mejor
por la agrupacin de varias cajas en una Ms Ver en general y el
aplazamiento de los detalles para el siguiente nivel inferior. Trazar
una lnea alrededor del grupo y reemplazarlas todas con una sola
caja, nombre adecuado. El nivel extra no es una complejidad aadido.
Es una representacin mejor, porque la estructura se ha mostrado
ms claramente.
Este fenmeno surge a menudo en combinacin con la divisin y es
uno de los ms poderosos mtodos de funciones que explican.
B.2.3.2 Agrupacin flechas
Ambas flechas y cajas deben estar a un nivel correspondiente de la
abstraccin en un diagrama.
Hay dos formas bsicas para lograrlo:

1. flechas paquete con el mismo origen y destino en una sola ms


general etiquetar, y hacer una flecha.
2. Cambiar el nombre de algunas cajas (utilizando Split y Cluster)
para distribuir mejor las subfunciones y re-etiqueta resultante flechas.
Rara vez es cierta que un exceso de flechas indica un error. Puede ser
que ambos estn exactos y precisos. Pero siempre es cierto que un
exceso de flechas es malo si el mensaje es oscurecido. La capacidad
de los lectores para entender lo que se dice debe guiar el nmero de
flechas utilizadas.
B.2.3.3 proponer modificaciones al Contexto
El conocimiento detallado de manifiesto mediante la creacin de un
nuevo diagrama puede descubrir errores u omisiones en el diagrama
de los padres. la modificacin de los padres es un evento natural y
esperado. Al crear el flecha estructura, la regla es que "si hay alguna
duda sobre si una flecha es necesaria por una funcin caja, que se lo
saltan - detalla ms adelante se demostrar si la flecha es realmente
necesario ".
Este es el punto en el que estas cuestiones se resuelven por una
razn especfica en lugar de a travs de la ex especulacin.
Cambios diagrama de padres pueden presentar diversos grados de
dificultad. Si el cambio puede ser acomodados por una revisin de
slo el padre inmediato, esto es ms simple que una revisin que
implica diagramas ms remotas tambin. Al proponer un cambio, creo
que a travs cuidadosamente y evaluar su complejidad. Sustituyendo
cambios simples para los ms grandes pueden perjudicar la calidad
de la descomposicin. Cuando se ha completado la correccin, revise
todas las conexiones para asegurar la frontera que los cdigos ICOM
estn correctamente muestran. Informar a otros autores que trabajan
en el diagrama de los cambios.
Siempre tenga en cuenta el diagrama de los padres para el cuadro
que se detalla. Se ayuda en la creacin proceso. Si el diagrama
detallado no se ajusta al contexto, ya sea el trabajo actual o el
contexto es incorrecto. Cambiar el contexto o cambiar el trabajo
actual. Ellos deben coincidir.
B.2.3.4 Sintaxis para ICOM Conexin Diagramas
Un aspecto importante de la comprensin de los diagramas es la
capacidad de encontrar y entender los hechos que son necesario. Los
nmeros de nodo muestran la estructura de la descomposicin de
funcin (cuadro detallando). Las flechas de red proporcionan
conexiones de interfaz.
Cdigos ICOM estn escritos en todas las flechas que tiene un
extremo sin conectar en el diagrama. Estas flechas de contorno
conectan la red de la flecha a travs de diagramas. Cada flecha lmite
est etiquetado con un cdigo de ICOM para especificar la conexin
de la flecha a la caja principal.
B.2.4 diseo grfico
Coloque las cajas en diagonal de acuerdo con la estructura de
restriccin, de la parte superior izquierda para bajar derecho.
Evaluaciones de control suben y se fueron, y las flechas de entrada de

realimentacin (que van de memoria modelo) abajo ya la izquierda.


En este punto, el nmero de las cajas de izquierda a derecha.
Lo mejor es empezar con este diseo slo las flechas de restriccin de
mayor uso, aadiendo menos usado caminos posteriores. Este
subconjunto de las flechas permitir la posicin de la caja que se
determine. Atraer a todos flechas zona mostrada en el diagrama de
matriz y luego se suman las flechas restantes.
B.2.4.1 Restricciones en el diagrama
1. cajas funcin siempre tendrn flechas de control, a pesar de que no
es necesario tener siempre insumos.
2. Cuando una flecha de entrada sirve tanto a las funciones de control
y de entrada, se muestran como control. Cuando en duda, que sea el
control. Una flecha que aparece en una caja padre como el control
puede aparecer en el siguiente nivel como control o entrada, o
ambos, dependiendo de su relacin con la sub-funciones en ese nivel.
3. En general, no parta una flecha en tanto un control y una entrada a
la misma caja. Esta detalle se muestra mejor en un diagrama de nivel
inferior en el que el destino de cada rama y aparecer la razn de la
separacin. Cuando hay que hacer para que el padre ms
significativo, etiquetas para elegir las dos ramas que transmitir su
decisin importante.

4. La actividad Iterado (almacenamiento de memoria o


retroalimentacin) puede mostrarse como:

5. Trate de evitar redundancias, tales como:

En estos casos, los nombres de cuadros triviales se limitan a repetir el


mensaje transmitido por la colocacin de la flechas. Un poco de

reflexin adicional producir normalmente nombres de cuadros ms


informativos.
B.2.4.2 Flecha Colocacin
1. flechas Draw a lo largo de lneas horizontales y verticales, no en
diagonal o como curvas (excepto en esquinas).
2. Coloque esquinas flechas, cruces y etiquetas a una distancia
razonable de las cajas.
3. No utilice las palabras clave, es decir, "funcin" de "datos", "de
entrada", "Salida", "control" "o "Mecanismo" en los nombres o
etiquetas, a menos que sea absolutamente necesario.
4. Si una flecha es largo, etiquetarlo dos veces.

5. Place ICOM codes at the unconnected ends of arrows.

6. Conectar flechas contorno abiertas para mostrar todos los


lugares afectados. Los lectores pueden perderse conexiones de
otra manera.

7. flechas espacio paralelo adecuado. Ellos son difciles de seguir


visualmente si son largos y cerrar juntos.

8. Coloque las puntas de flecha adicionales a lo largo de las flechas


cuando sea necesario por motivos de claridad.
B.2.4.3 Flecha Disposicin

1. flechas paquete con el mismo origen y el mismo destino a menos


que la flecha es de tal importancia que lo que es parte de un
gasoducto disminuira la claridad.

Ms bien que
2. Utilice el menor nmero posible de flechas situados en un costado
de una caja. Si hay demasiados manojos de algunos, etiqueta con una
etiqueta abstracta adecuado y ramas se abren en abanico a sus
destinos.

Ms bien que
3. evaluaciones de control se muestran como "arriba y por encima."

evaluaciones de entrada se muestran como "abajo y por debajo."

retroalimentacin mecanismo se muestra como "abajo y por debajo."

4. Si una flecha horquillas y se alimenta en varias cajas, dibujarlo en


la misma posicin relativa ICONO en cada caja, si es posible.

5. Disear flechas a fin de minimizar los cruces.

6. Minimizar curvas y esquinas, manteniendo los segmentos


marcados claro:

7. Utilizar el potencial expresivo de las flechas de ramificacin


cuando y si es apropiado.

8. Para evitar el desorden cuando se muestra una flecha que se


aplica de forma idntica a, o se obtiene idntica de cada caja en
un diagrama, utilice el "para todos" convencin:

9. Todas las flechas deben tener esquinas curvadas en


combinaciones, horquillas y curvas.

B.2.5 Escribir texto


B.2.5.1 texto y Glosario
El texto que puede acompaar a cada diagrama presenta una
breve descripcin integracin del diagrama, citando las relaciones
importantes, patrones o interacciones sutiles entre las cajas y
flechas.
Preferiblemente, el texto es menos de una pgina de longitud. En
l se destacan las caractersticas que se siente de autor son de
especial inters o importancia por caminar al lector a travs de las
ideas principales del diagrama. Eso no duplica cada detalle se
muestra en el diagrama de s mismo.
Escribe el texto slo despus de un diagrama ha recibido un nivel
bastante alto de revisin y aprobacin.
Esperando para escribir el texto de las fuerzas del propio diagrama
de comunicar adecuadamente la intencin mensaje. Texto basado
en diagramas cuidadosamente dibujados sern tan estructurada y
tan organizado como el propio diagrama.
Utilice un glosario con definiciones para resumir los significados
especiales que puedan surgir de trminos clave, palabras, frases y
acrnimos utilizados en el diagrama. Una palabra o frase pueden
tener diferentes connotaciones para diferentes lectores del
diagrama.

Trate de conseguir un buen texto sin la adicin de un FEO. Feos


debe ser utilizado para ilustrar aspectos sutiles que aclarar la
intencin de un diagrama pero que llenara el diagrama que fueron
incluidos. Si un FEO es necesario, el texto que lo acompaa debe
hacer referencia al diagrama relacionado.
Notas y referencias B.2.5.2
Hay dos tipos de notas, notas y notas modelo de lector. notas de
modelos se discuten en la seccin normativa.
En agudo contraste con las notas modelo, que son parte del
diagrama en el que aparecen, lector notas explcitamente estn en
el diagrama, no es parte del diagrama. Por lo tanto no pueden
alterar el significado de la sintaxis o la semntica del diagrama. Al
igual que con las notas modelo, si el texto de una nota lector es
aplicar a varios lugares o varias caractersticas del diagrama
(incluyendo otras notas o modelo-readernotes) la-nota-nmero con
un crculo (sin texto) puede ser copiado y puede estar unido por
una
IDEF0 garabato (
)a cada punto de aplicacin, pero slo en el
diagrama sencillo en el que la aparece el texto de lector de notas.
Por definicin, las notas del lector son estrictamente informativas,
no normativas. Pueden ser de cualquier cosa en absoluto, con
respecto al diagrama o modelo. En la prctica, notas lector puede
ser sobre el modelado materia o sobre su presentacin modelado,
incluyendo la eleccin de las palabras, el diseo, la precisin,
etctera notas lector se denotan por un nmero "n" dentro de un
crculo pequeo: n. Para cualquier diagrama especfico (Y por tanto
el nmero de nodo), los nmeros, "n", formar una secuencia
consecutiva, empezando por "1".
Todos los lectores (incluyendo el autor, al comentar sobre algo)
compartirn la misma secuencia lector de notas de un diagrama.
Nmeros lector de nota para un nodo no debern ser reutilizados o
reasignado. As, su secuencia de la creacin en el contexto de su
nmero de nodo es un permanente registro de lector / autor en
cuanto a la discusin de ese nodo.
Una notacin estndar se utiliza en el texto escrito y toma nota
para referirse a los diagramas y las partes especficas de
diagramas. Las referencias se basan en los nmeros de la caja,
cdigos de ICOM, nmeros de nodo, y nota nmeros.
Por ejemplo,
O2 significa La flecha lmite con cdigo ICOM O2
2I1 significa Box 2 Entrada 1
2O2 a 3C1 significa la flecha desde 2O2 a 3C1
n significa Modelo Nota n
| n | significa Modelo Nota n (notacin alternativa)
(N) significa Reader Nota n (notacin alternativa)
n significa Reader Nota n
significa QA / A21.3C2 En el modelo de "control de calidad" en el
diagrama A21, vase el recuadro 3 Control 2

A42. 3 significa El diagrama de A42 en este modelo, ver nota 3


lector
A42. 3 medios en el diagrama A42 en este modelo, ver nota 3
modelo
Significa A42.3 El diagrama de A42 en este modelo, vase el
recuadro 3

Estos artculos pueden ser utilizados individualmente si se refieren


al diagrama actual (por ejemplo, en las notas o modelo texto). De
lo contrario, debern ir precedidos por el nmero de nodo, y si es
necesario, por el nombre del modelo. UN punto "." se utiliza para
referirse a "ver" una cosa determinada en el esquema
especificado. Por ejemplo:
significa MFG / A21.3C2 En el modelo "MFG", en el diagrama A21,
vase el recuadro 3
Control 2.
Cada referencia slo necesita tantos campos que sean necesarios
para estar completamente inequvoca.
La forma ms completa es la siguiente:
ACCT / (A21 = BT56) .1O2 a 4C3
Lo que significa que en el modelo "ACCT" A21 diagrama, C-BT56
nmero, "ver" la flecha de la caja 1 La salida 2 a la casilla 4 de
control 3.
Insertar referencias ordenados y completos en la redaccin del
texto, glosario y pginas FEO, por ejemplo, "La influencia (2O3 de
1c2 y 3c2) de este costo en el precio ms alto (O2) es motivo de
preocupacin." Esta traza la tercera salida del cuadro 2, a travs
de las casillas 1 y 3, hasta el lmite flecha O2, como la sentencia es
ledo. Cuando haya terminado con el texto ir a travs y agregar
referencias numricas de caja para empatar el texto para el
diagrama exactamente.
La mayora de las veces un nmero simple caja ( "Box 3") o una
referencia a un par de flechas son suficientes ( "Box 3, O1 y C2").
Cuando un lector necesita "ver" el otro diagrama, utilizar el "." De
el idioma de referencia.

Del mismo modo que el ICOM codificacin de forma natural se


extiende el esquema de referencia de nodo de base de nmeros, el
modelnote y el lector-nota notaciones les permiten ser
referenciado.
Por ejemplo,
A21.3C2 | 2 | (5) Responder
Continua el ejemplo anterior ( "El diagrama A21, vase el recuadro
3 Control 2") para el caso en el que el lector hace referencia a la
respuesta del diagrama de autor al lector-nota # 5 (tal vez aadida
por el segundo lector del diagrama), que ha comentado modelo de
la nota del autor # 2, en relacin con el control de pregunta! En
este ejemplo, "respuesta" muestra el uso de breves expresiones
del lenguaje natural en el idioma de referencia.
Este ejemplo tambin ilustra el uso de abreviaturas | n | para n
(modelo-notas) y (n) para n (lector de billetes) para fines de
referencia textual. Estas abreviaturas permitir la preparacin ms
fcil de las referencias a las notas utilizando procesadores de texto
estndar. Las referencias a notas de texto y IDEF0 correspondencia
escrita, son ejemplos de referencias textuales.
Recogida de datos para B.3 IDEF Modelado
B.3.1 Introduccin
Al analizar o el diseo de cualquier sistema, puede ser necesario
para obtener o verificar hechos acerca del sistema o materia en
cuestin. Hay muchas fuentes de informacin sobre los hechos.
Se podra hacer lo siguiente:
Leer documentos existentes, utilizando cada tabla de contenido y
el ndice para localizar necesario informacin.
Observe el sistema en funcionamiento, si ya existe.
Encuesta de un gran grupo de personas, a travs de
cuestionarios u otros medios.
Habla con uno o ms expertos que poseen el conocimiento
deseado.
Utilice lo que ya es conocido por el autor.
adivinar o inventar una descripcin hipottica, y pedir a los
lectores para ayudar a acercarla a la realidad.
De todos estos mtodos, el ms importante es la interaccin cara
a cara con un experto. Rara vez toda la informacin existente
escribirse. nociones preconcebidas que se reflejan en los
cuestionarios son menudo defectuosa.
Una parte clave de la entrevista es registrar la informacin
obtenida. Esto se puede hacer ya sea como notas informales,
como la actividad y datos / objetos listas, como una matriz formal
de funciones, o como diagrama bocetos.
B.3.2 La Entrevista proceso
El propsito de una entrevista es obtener informacin a partir de
un individuo que posee una experiencia considerada importante
para el esfuerzo analtico. Existen cuatro tipos de entrevistas que
podran llevarse a cabo durante el curso de la realizacin del
anlisis fase de un proyecto IDEF.

(A) Determinacin de los hechos para la comprensin de las


operaciones actuales. Este tipo de entrevista se utiliza para
establecer el contenido de un modelo de operaciones actuales o
para ayudar a comprender la entorno existente.
(B) Identificacin del problema para ayudar en el establecimiento
de las necesidades futuras. Esta tipo de entrevista se utiliza para
validar el modelo de operaciones actuales y proporcionar las bases
de un modelo de operaciones futuras.
(C) Solucin de discusin con respecto a las capacidades del
sistema en el futuro. Este tipo de entrevista se utiliza para
establecer el contenido de un modelo de operaciones futuras.
(D) IDEF Autor / Lector Talk Sesin. Este tipo de entrevista se utiliza
para resolver problemas que han surgido durante la construccin
de un modelo IDEF.
La razn para la identificacin de tipos de entrevistas es que
durante el curso de la realizacin de una real entrevista,
ingredientes de cada tipo aparecen. El demandado puede decir
acerca de los hechos del entrevistador un sistema dado en
trminos de problemas. Adems, el demandado podra identificar
los problemas en trminos de soluciones a los problemas. Al
clasificar constantemente observaciones de los encuestados, el
entrevistador se puede apreciar mejor el punto de vista del
experto.
B.3.3 El kit Entrevista
Un kit de entrevista "estndar" se puede utilizar para la grabacin
de la entrevista. Se puede almacenar en una entrevistar archivo y
que puede ser distribuido a los individuos de proyectos apropiados.
Esta distribucin podra incluir a otros miembros del equipo de
anlisis o incluso el demandado entrevista para correcciones,
adiciones y supresiones. El kit contendra entrevista:
1. Cartula (kit de la cubierta)
2. Entrevista y Registro de Seguimiento
(A) Nombre del entrevistador (IDEF nombre del autor)
(B) Fecha de la entrevista (IDEF Diagrama Fecha)
(C) Entrevista Duracin (Hora de inicio, Hora de finalizacin)
(D) Nombre del demandado
(E) Ttulo demandado y responsabilidad organizativa
(F) demandado Nmero de Telfono y Extensin
(G) Fuentes adicionales de informacin que se indica
(1) Documentos-Ttulo y Ubicacin
(2) Otros entrevistados-nombre, ttulo, Responsabilidad orgnica,
Direccin, nmero de telfono
(H) Elementos esenciales de la Informacin-A Resumen de los
puntos claveen la entrevista
(I) Seguimiento de las preguntas y / o reas de preocupacin, o
bien no cubiertos durante el entrevistar o pospuesto
(J) Los nuevos trminos para Proyecto Glosario
3. La actividad y datos / objetos de la lista

4. Entrevista Agenda (desarrollado en la preparacin para la


entrevista).
5. Toma nota de la entrevista y el plano esquemtico
ANEXO C - PROCEDIMIENTOS Y FORMAS ciclo de revisin
C.1 IDEF Trabajo en equipo Disciplina
El desarrollo de cualquier modelo IDEF es un proceso dinmico que
requiere la participacin de ms de una persona. A lo largo de un
proyecto, el proyecto de porciones de un modelo es creado por
autores y distribuido a otros (miembros del proyecto, los expertos
en la materia, gestin, etc.) para revisar y comentar. Estos
proyectos de porciones de un modelo son llamados kits y pueden
contener diagramas, texto, glosario o cualquier otra informacin
que el autor siente es pertinente para el desarrollo del modelo.
Se requiere una capacitacin breve y modesta experiencia de leer
y entender los modelos IDEF0 correctamente.
Tal entendimiento bien informado es esencial para que la garanta
de calidad de equipo suministrado de IDEF el modelado se quiere
realizar. Todo el mundo adecuadamente avanzado en las
habilidades de lectura correcta se denomina "lector".
La disciplina IDEF el trabajo en equipo identifica a todas las
personas interesadas en la revisin de un modelo como los
colaboradores. Los colaboradores que estn asignados a hacer una
crtica escrita de un kit se denominan comentaristas. Opinan que
reciben un kit para informacin solamente, no se espera que haga
por escrito comentarios y son llamados lectores. El autor y el
comentarista comparten la responsabilidad de la calidad del
modelo. A travs de su aceptacin del resultado acordado, las
otras personas comparten la rendicin de cuentas de la utilidad de
los resultados.
La disciplina requiere que cada persona espera para hacer
comentarios acerca de un kit harn por escrito el uso de notas
lector y presentarlos al autor del kit. Escribiendo en el copia del
lector, el autor responde a cada nota por escrito (una marca de
verificacin sencilla, por acuerdo; de lo contrario, una nota de
respuesta). Este ciclo contina, que abarca todos los kits
pertenecientes a un particular, modelo, hasta que el modelo est
completo y recomendado para su publicacin.
A intervalos regulares durante la evolucin de un modelo, la copia
maestra de la versin ms reciente es colocado en la biblioteca, y
una copia se difunde en forma de un kit, que se enva a los
lectores a ayudarles a mantener la informacin actual sobre el
modelo. A medida que los comentarios sobre cada kit son
revisados por el autor, que hace que los cambios en la copia
maestra del modelo para incorporar correcciones y cambios. Otro
kit que incluye los ltimos cambios se distribuye luego a la lista de
los lectores. Ms detalles se aaden la creacin de ms diagramas,
texto y glosario. Ms los comentarios se hacen; se incluyen ms
cambios. El efecto final de este proceso para organizado el trabajo
en equipo es la mxima garanta de que los modelos IDEF finales

son vlidos, as expresado, y que una se ha alcanzado consenso


por el conjunto de los lectores que se han incluido en el ciclo de
revisin.
C.2 El IDEF Ciclo Kit
En la creacin de un documento, los materiales escritos o
recolectados por un autor se distribuyen, en forma deun kit
estndar, a los comentaristas, crticos y otros lectores. Los
comentaristas revisan el material y escribir los comentarios al
respecto. Los comentaristas devuelven el kit para el autor que
reacciona a comentarios y pueden utilizar los comentarios de
revisar o ampliar el material. El kit se devuelve a la comentarista
con las reacciones de autor. Los lectores pueden volver
comentarios al autor como bien, pero esto no es necesario. Esto se
conoce como un ciclo Kit (Figura C1).

Figura C1. Ciclo kit


Los pasos del ciclo de Kit son los siguientes:
El autor rene el material a ser revisado en un kit estndar. Una
hoja de cubierta es terminada. Ejemplares de la carpeta se
distribuyen a cada uno de los lectores, y al autor.
El original se presente como referencia.
Dentro del tiempo de respuesta especificado, el comentarista lee
y escribe el kit comentarios directamente en la copia en forma de
notas de lectores, en rojo si es posible. Se devuelve el kit al autor.
El autor responde por escrito directamente en el ejemplar de
cada comentarista, en azul si es posible.
El autor puede estar de acuerdo con el comentario de registro de
entrada, marcndolo, sealando que en su trabajo copiar y su
incorporacin en la prxima versin del modelo. En caso de
desacuerdo, el autor escribe una nota de respuesta adjunta a la
nota del lector (sin nuevo nmero de nota).
Si hay o no hay acuerdo, el kit se devuelve al lector, completando
una

Ciclo / Autor lector. (Vase C.4.1.2 relativas a la numeracin lector


de billetes.)
El lector lee las respuestas del autor y, si est satisfecho,
presenta el kit. (kits comentadas Siempre son retenidos por el
lector.) Si un comentarista asignado no est de acuerdo con el las
respuestas de los autores, una reunin se arregla con el autor para
resolver las diferencias. Si estono se puede hacer, una lista de
cuestiones se toma a la autoridad competente para su resolucin.
El autor no est obligado a resolver las diferencias con cada lector,
pero son comentaristas privados de sus derechos si sus
preocupaciones no se resuelven.
Este ciclo contina hasta que se crea un documento que
representa la cuidadosa consideracin de todos los miembros del
proyecto. Adems, una historia completa del proceso se ha
mantenido.
Los resultados de este Ciclo kit son un documento al que el autor y
comentaristas han contribuido, y, si es necesario, una lista de
cuestiones que requieren una accin de gestin.
A lo largo del ciclo, un bibliotecario proyecto se encarga de la
copia, distribucin, archivo y transmisin de los kits entre autores,
comentaristas, crticos y lectores.
Roles del personal C.2.1
Los roles y funciones de las personas que intervienen son:
Autores (analistas)
Las personas que preparan cualquier modelo IDEF.
Los comentaristas (Expertos u otros autores)
Las personas con conocimientos del sujeto que est siendo
modelado a partir de los cuales los autores pueden tener la
informacin obtenida a travs de entrevistas, y tienen la formacin
suficiente en un IDEF tcnica para ofrecer comentarios
estructurados por escrito. Las personas asignadas para hacer un
escrito crtica de un kit.
Los expertos Lectores (o cualquier persona que quiera ser el
lector en la lista)
Las personas con conocimientos del sujeto que est siendo
modelado a partir de los cuales los autores pueden tener obtenido
informacin a travs de entrevistas y documentos de revisin de la
informacin pero no se espera para hacer comentarios por escrito.
Bibliotecario
Una persona asignada la responsabilidad de mantener un archivo
de documentos, hacer copias, la distribucin de los kits y el
mantenimiento de registros.
Todas las personas que juegan estos papeles deben ser entrenados
y experimentados IDEF0 lectores, para que puedan realizar las
funciones asignadas de forma fiable.
Un "papel" no tiene nada que ver con el ttulo del trabajo de
alguien, y la misma persona se le puede pedir a realizar varias
funciones. Por lo tanto, la participacin de cada individuo es, de
hecho, nica y depende de el kit involucrado.
C.2.1.1 Autor

De expertos de autor entrevistas, anlisis de la informacin, la


organiza en diagramas y crea modelos. Un autor puede o no puede
ser la fuente del contenido tcnico de un documento. Un autor
puede servir slo como un analista de la informacin adquirida, la
identificacin, clasificacin y la organizacin de la presentacin de
los conocimientos obtenidos de los expertos y la aplicacin de
habilidades de modelado en expresando su comprensin en
trminos IDEF0.
C.2.1.2 comentarista
Comentaristas asignados leen material producido por un autor y
verificar su precisin tcnica.
Ellos son responsables de encontrar errores y sugerir mejoras. El
papel de un comentarista es la clave para producir resultados de
alta calidad. Pero cada lector debe observar si el autor tiene
seguido la tcnica IDEF consistentemente; si el punto de vista y el
propsito se han adherido a; y si existen errores u omisiones que
deben ser puestos en conocimiento del autor. Si una lector es un
autor entrenado, lo que sugiere cambios en la descomposicin
jerrquica, las variaciones en contenido del cuadro de actividad y
otras observaciones para mejorar el poder de la comunicacin y la
utilidad de el modelo ser bien recibida por la mayora de los
autores.
Directrices para autores y lectores y comentaristas
En esta seccin, las pautas generales para los lectores y los
autores se discuten los lectores pueden tener ms intereses
especiales como comentaristas y crticos que no estn cubiertos
aqu.
Directrices Reader C.2.2.1
No hay un patrn conjunto de preguntas y reglas puede ser
adecuada para hacer comentarios, ya que la materia tema, estilo y
la tcnica vara tan ampliamente. Sin embargo, las directrices
existen para mejorar la calidad. Los mayores criterios de calidad
son: El documento comunicar bien a su pblico objetivo? Lo hace
lograr su propsito? Es objetivamente correcta y precisa, dado el
contexto acotado? En general directrices para comentar son:
Tome notas breves, exhaustiva y especfica. Siempre que el autor
entiende que sutilezas se dejan caer por la concisin, esto hace
que la comunicacin sea ms fcil y menos desorden.
Uso de la notacin n (notas del lector) para identificar los
comentarios. Para escribir un -nota n, comprobar el siguiente
nmero de la lista de lectores NOTAS, nmero de la nota, la vuelta
al nmero y conecte la nota a la parte apropiada con un garabato
. (Ver
Seccin forma de diagrama de Standard C.4.)
hacer crticas constructivas. Trate de sugerir soluciones o sealar
las fuentes de problemas, est claro.
Tmese el tiempo para recoger comentarios generales. Estos
pueden ser colocados en la cubierta o en una hoja separada. (Pero
no recoger los puntos especficos en esta hoja cuando pertenecen

en las pginas individuales.) Temas de autor / reuniones pueden


ser comentarista resumido. Hacer mencin especfica del orden del
da.
La longitud de tiempo dedicado critiquing depende de una
variedad de cosas: familiaridad con lo que se descrito, el nmero
de veces que algo ha sido revisado, la experiencia del lector y
autor, etc. Un kit volvi a un autor sin ms comentarios que firma
y una del lector marca de verificacin significa que el lector est
en total acuerdo con el autor. El lector debe darse cuenta que
existe una responsabilidad compartida con el autor de la calidad
de la obra.
C.2.2.2 Autor / comentarista Intercambios
Cuando un lector devuelve un kit, el autor responde poniendo una
"A" o "X" por cada -nota n (lector,Nota). "A" significa que el autor
est de acuerdo con el comentarista e incorporar el comentario
en la prxima versin del kit. "X" significa que los autores no est
de acuerdo. El autor debe indicar por qu en escrito en el que
aparece el comentario. Despus de que el autor ha respondido a
todos los comentarios, el kit es vuelto para el lector de retener.
Directrices de reuniones C.2.2.3
Hasta comentarios y reacciones son en papel, los lectores y los
autores no se animan a conversando.
Cuando se requiere una reunin, el procedimiento es el siguiente:
1. Cada reunin debe ser limitado en longitud.
2. Cada sesin debe comenzar con una agenda especfica de
temas que se refieren a uno o ms de los comentarios y las
respuestas de autor, y la sesin debe atenerse a ellas temas.
3. Cada sesin debe terminar cuando los participantes estn de
acuerdo en que el nivel de la productividad ha cado y los
esfuerzos individuales sera ms gratificante.
4. Cada sesin debe terminar con una lista acordada de los puntos
de accin que puede incluir la programacin de las sesiones de
seguimiento con los programas especificados.
5. En cada sesin, un "escriba" se designar a tener minutos y
tomar nota de las acciones, decisiones y temas.
6. diferencias no resueltas serios deben ser manejados
profesionalmente, mediante la documentacin ambos lados de la
imagen.
El resultado de la reunin debera ser una resolucin por escrito de
los temas o una lista de cuestiones que deben resuelta por la
decisin de gestin apropiada. La resolucin puede tomar la forma
de mayor estudio realizado por cualquier de los participantes.
C.3 IDEF Kits
Un kit es un documento tcnico. Puede contener resmenes
diagramas, texto, glosarios, decisin, informacin de fondo o algn
embalado para su revisin y comentarios.
Una hoja de cubierta apropiada distingue el material en forma de
kit. La hoja de cubierta tiene campos para autor, fecha, proyecto,
nmero de documento, ttulo, el estado y las notas.
Hay dos tipos de IDEF Kits:

Standard Kit Para ser distribuido para hacer comentarios. Se


considera un "documento de trabajo" para ayudar a la autor en el
perfeccionamiento de su modelo total.
Kit de actualizacin contiene la ltima versin de un modelo. Se
envi a ttulo informativo y est diseado para ayudar a mantener
la informacin actual sobre el modelo total, mientras partes del
modelo estn siendo procesados a travs del ciclo de Kit. El kit de
actualizacin puede incluir slo las pginas modificadas desde la
actualizacin anterior.
Los kits estndar contienen porciones de un modelo y se someten
con frecuencia a medida que avanza el trabajo.
Los kits estndar son enviadas a travs del Ciclo IDEF Kit para la
revisin y el tipo se denominan en el resto de este anexo.
Kits de actualizacin se presentar a intervalos regulares. Estos
kits contienen la ltima versin del modelo.
No se espera que los destinatarios de los kits de actualizacin para
hacer comentarios sobre ellos aunque pueden optar por hacerlo.
Kits de actualizacin se mantienen por los destinatarios de sus
archivos.
C.3.1 Completar una hoja de portada Kit
Una hoja de cubierta apropiada distingue el material en forma de
kit. La hoja de cubierta tiene campos para autor, fecha, proyecto,
nmero de documento, ttulo, el estado y las notas. Preparar una
hoja de portada para cada kit presentado, rellenando los siguientes
campos en la hoja de portada (Ver Figura C2).
Informacin de Trabajo
- Autor o un equipo que genera el modelo
- Nombre del proyecto y de la tarea nmero
- Fecha de presentacin original a la biblioteca
- Las fechas de todas las revisiones publicadas
- Estado de la modelo, ya sea de trabajo, proyecto, se
recomendar su aceptacin o publicacin como modelo final
Informacin Crtica
- Presentacin y copia la informacin
- Lista de los colaboradores del kit
- Fecha programada para diversas fases del ciclo kit
Informacin de contenido
- Tabla de contenidos para el kit
- Estado de cada seccin kit
- Comentarios o instrucciones especiales a bibliotecario
Informacin de identificacin
- Nombre del modelo (en el campo de nodo)
- Ttulo del modelo
- C-Nmero

Figura C2. Hoja de formulario de portada

Figura C3. IDEF CONTENIDO DEL KIT FORMA


C.3.2 Cmo preparar un kit estndar
Para evitar descuidos, revisar el kit como si fuera la nica
informacin disponible. la captura de cualquier errores
tipogrficos. Aadir puntos de aclaracin que vienen a la mente
como breves notas sobre el kit s mismo. Las definiciones del
glosario de los trminos que aparecen en el juego siempre deben
ser agregadas como soporte material.

Reunir materiales tiles y anexar estos para beneficio del lector.


Nunca utilice este suplemento material a transmitir informacin,
que debe ser adecuadamente transmitido por el propio diagrama.
Siempre que sea posible, utilizar los medios de comunicacin ms
naturales-diagramas para mostrar detalles que son importantes
para el lector en la comprensin de los conceptos. Combinar todo
el material con una Cartula de completado y Kit Contenido hoja
(Figura C3) y someter a la Biblioteca.
C.4 forma de diagrama de Standard
La forma de diagrama IDEF (Figura C4) tiene estructura y las
restricciones mnimas. La sbana slo es compatible con las
funciones importantes para la disciplina de anlisis estructurado.
Son:
Establecimiento de contexto;
Referencias cruzadas entre hojas de papel;
Notas sobre el contenido de cada hoja.
La forma de diagrama es un tamao estndar nico para facilitar
la presentacin y copia. El formulario se divide en tres secciones
principales:
Informacin de trabajo (parte superior)
Mensaje El campo (en el centro)
Los campos de identificacin (parte inferior)
La forma de diagrama se debe utilizar para todo lo escrito.

Figura C4. Forma de diagrama de Standard


El formulario est diseado de modo que la informacin de Trabajo
campos en la parte superior del formulario se puede cortar cuando

se termina un "aprobado para su publicacin" versin final. La


identificacin de campos en el parte inferior estn diseados para
mostrar, una bajo la otra, cuando las formas (con las tapas intactas
para virar) se extienden verticalmente y hilvanada con el pulgar,
en orden de arriba hacia abajo, en un tablero de corcho o de pared.
el expuesta Las tiras de identificacin de campo actan como un
ndice pulgar dispuesto en el ndice de nodo (contorno) orden. Si el
Dos caras pgina de par es seguido formato de publicacin, con
fondos de la pgina del texto y del contexto hacia la unin,
entonces su informacin se hace visible cuando el antepasado
montado en la pared formas estn levantados en alto, para ver el
campo de mensaje de cada diagrama.
Informacin de Trabajo C.4.1
C.4.1.1 El "Autor / Fecha / Proyecto" Campo
Esto le dice que cre originalmente el diagrama, la fecha en que se
haya extrado el primero y el ttulo del proyecto en virtud del cual
se cre. El campo "fecha" puede contener fechas adicionales,
escritas por debajo de la fecha original. Estas fechas representan
las revisiones a la hoja original. Si es una hoja de re-lanzado sin
ningn cambio, entonces no se aade ninguna fecha de revisin.
C.4.1.2 El "Reader Notas" Campo
Esto proporciona una retencin directa de las notas escritas lector
en la hoja de diagrama. Como se hace un comentario en una
pgina, el nmero de nota correspondiente est tachado. Este
proceso asegura que cada lector nota en un diagrama se le asigna
un nmero de nota nica, y que los nmeros de nota en cada
diagrama son consecutivos.
C.4.1.3 El "Estado" Campo
Las clasificaciones del estado indican etapas de aprobacin. Son:
TRABAJO El diagrama es un cambio importante, se reinicia la
secuencia de aprobacin.
Los nuevos diagramas son, por supuesto, la copia de trabajo, pero
tambin es habitual que diagramas para seguir trabajando por
varias revisiones antes avanzando. Un nuevo autor para ver un
diagrama general restablece el estado de De trabajo, tambin.
Redactar el diagrama es un cambio menor en el diagrama anterior,
y tiene alcanzado algn modo reconocido de nivel de aceptacin
por parte de un conjunto de lectores.
Proyecto de diagramas son los que proponen por un responsable
de la tarea (que puede ser el autor). Proyecto de diagramas
pueden someterse a revisiones adicionales, si estn incluidos en
un kit actual junto con otros diagramas, o estn trado de nuevo
en consideracin desde el archivo de algn lector, incluso a pesar
de que no estn en el juego actual. Proyecto de estado permanece
hasta que el diagrama es aceptada por una reunin de revisin de
la tcnica comit o coalicin.
RECOMENDADO Tanto este diagrama y su texto de apoyo han sido
revisados y aprobados por una reunin del comit tcnico o
coalicin, y este diagrama no se espera que cambie.

PUBLICACIN Esta pgina puede ser enviada al igual que para la


impresin final y publicacin.
C.4.1.4 El "lector / Fecha" Campo
Esta zona es donde un lector deber iniciales y la fecha de cada
formulario.
C.4.1.5 el "contexto" Campo
Un bosquejo de slo el diseo de la caja del diagrama de los
padres, con la caja padre resaltado. Los El nmero de nodo de
diagrama de matriz est escrito en la parte inferior izquierda del
contexto de campo (Figura C5). Los nmero de la caja de la caja de
los padres puede ser escrito en el cuadro resaltado, a pesar de que
tambin es la ltimo dgito de entrada de campo de nodos del
diagrama hijo.

Figura C5. Ilustracin del campo de contexto


Los siguientes casos especiales surgen: 1) El campo Contexto de la
forma requerida diagrama A-0 contexto es "TOP", escrita en el
centro del campo. 2) El campo Contexto de la A-1 de alto nivel
opcional diagrama de contexto es A-2, bosquejado, si hay un
diagrama de contexto de nivel superior, y de manera similar para
A-n, para n = 2 o mayor. 3) El campo Contexto para el nivel ms
alto del diagrama de contexto, A-n, para mayor n (= 1 o mayor) es
"None". Vase la figura 21 para un ejemplo ilustrativo.
C.4.1.6 El " utilizado en" Campo
Esta es una lista de diagramas, que no sea el contexto de los
padres, que utiliza o hacer referencia a este diagrama de forma
pgina de alguna manera.
El uso ms comn es una lista de una o ms referencias a los
ganglios sub-modelos para el que este suministros caja de los
padres del nio diagrama de apoyo para las llamadas en detalles
de este nio. Si es necesario (la caso n = 1 siendo asumidas por
convencin), el node_reference_expression (que comienza con una
"Nombre_del_modelo /" seguido de un nmero de nodo) termina
con "Mn", n mayor que o igual a 2, de remisin completa en una
referencia ICOM-cdigo a un mecanismo especfico de flecha caja
superior del compartimento de modelos compatibles. Por ejemplo
"TLS / A34M2" escrita en el campo de Al Usado diagrama hijo "MN /
A211" afirma que el apoyo mecanismo de caja padre "A21 / MN"
suministros, a travs el segundo mecanismo de flecha de su caja
superior, a la sub-modelo "TLS / A34".

Con ese apoyo a un sub-modelo de mando a distancia


suministrado por esta Utilizado En el campo, a continuacin,
cualquier nio en la caja este diagrama nio (o ms en general,
incluso la caja principal que suministra el soporte, o cualquier cajas
descendencia) pueden ser llamados a suministrar detalles de
alguna caja descendencia alcanzable del cuadro apoyado (tratado
como el cuadro de la parte superior de un sub-modelo) cuya
referencia aparece en el nodo Usado En el campo. Un cuadro de
descendencia alcanzable es una caja que se puede llegar en un
soporte de mecanismo de ramificacin flecha cuya fuente es ICOMcdigo conectado al soporte mecanismo.
Si la parte superior del diagrama se corta, para su publicacin, a
continuacin, el contenido de la utiliza en campo deben ser
copiado en el campo del mensaje como una -nota
(modelo de la
nota).
C.4.2 El campo "Mensaje"
El campo de mensaje contiene el mensaje principal a transportar.
El campo se utiliza normalmente para diagramas con un lenguaje
grfico IDEF. Sin embargo, el campo se puede utilizar para
cualquier uso: glosario, listas de control, notas, bocetos, etc. Los
miembros del proyecto debe utilizar ningn otro papel que no
formas de diagrama, de modo que el sistema de archivo basado en
referencias de nmeros pueden proporcionar un proyecto completo
grabar. Esto puede facilitarse con el apoyo de herramientas IDEF
que incluye correo electrnico y Boletn de embarque, con
-Settings "preferencia" para cada participante automtica Cnumeracin y.
C.4.3 El campo "nodo"
Este campo contiene el nodo de referencia completa para la hoja
(incluyendo nombre_del_modelo, barra, Nmero de nodo, y "F"
(para FEO), "T" (para el texto) o "G" (para el glosario) -con el
nmero de pgina
"1" o "2", etc. adjunta al final para indicar pginas de
desbordamiento, si es necesario), de modo que la hoja es con una
ubicacin exclusiva para cualquier y todos los propsitos de
referencia.
C.4.4 El campo "Ttulo"
El campo de ttulo contiene el nombre del material que se presenta
en la forma de diagrama. Si el mensaje de campo contiene un
diagrama, a continuacin, el contenido del campo Ttulo deben
coincidir precisamente el nombreescrita en el cuadro principal.
C.4.5 El campo "Nmero"
C.4.5.1 El "Nmero" Campo (Large Area)
El rea grande contiene el nmero C. El nmero C se compone de
dos o tres letras de la iniciales del autor (elegido para ser nico
entre los participantes en el proyecto), seguido de un nmero
secuencial asignado por el autor. Este nmero C se coloca en la
esquina inferior izquierda de la campo Nmero y es el principal
medio de referencia a una hoja de s mismo, porque la hoja como

una forma de diagrama en uso slo puede ser creada una vez.
Cada forma de diagrama utilizado por un autor recibe una nica Cnmero, que habitualmente debe ser la primera marca hecha en el
formulario.
Si el proyecto elige para realizar un seguimiento de historial de
versiones, entonces el C-nmero de la forma de diagrama de los
cuales esta hoja es una versin alterada deber escribirse entre
parntesis (espacio opcional) despus del autor entrada-serie C en
el campo nmero C. Por ejemplo "AB34 (CD123)" indica que esta
hoja ( "AB34") est destinada a ser un reemplazo para el ya
existente "CD123".
Cuando se publica un modelo, el nmero-C puede ser reemplazado
por una pgina secuencial estndar nmero (por ejemplo, "pg.
17").
C.4.5.2 El Campo "Nmero" ( "Nmero de pgina Kit"
Pequeo rea rectangular)
Un nmero de pgina kit est escrito por el bibliotecario en la
parte derecha del campo Nmero dentro de la pequeo rectngulo.
Este est compuesto por el nmero seguido de la letra que
identifica la hoja dentro del documento.
C.5 Conservacin de archivos
Cada participante asignado oficialmente en un proyecto
mantendr los archivos del lector / autor de la documentos
recibidos. El bibliotecario debe mantener el maestro y oficial de
referencia de los archivos del proyecto, el archivo de cada kit
presentado durante el curso del proyecto.
Las variaciones en el proceso de presentacin se pueden producir
en base a las preferencias individuales, pero el siguiente archivos,
mantenidos de manera ordenada alfabticamente nmero de
referencia, como la organizacin primaria presentacin de la
estructura, son los mnimos:
Los archivos Standard Kit
Mantenido por autores, comentaristas y quizs otros lectores.
Presentar kit de la cubierta
Hojas de forma cronolgica, como un registro maestro, pero el
extracto y el archivo de la mayora de los C-pginas Los modelos
apropiados, con el fin de nodos de referencia. En caso de duda,
deje la hoja de archivado Kit, tal vez aadiendo Notas del lector
referencias cruzadas en el diagrama presentado ya, formas en
lugares distintos de archivos electrnicos seleccionados, tambin.
(Cada hoja es la propiedad de la Lector y lector-Nota de
numeracin se reinicia frescos para cada hoja C-numerada, por lo
los archivadores aadido lector personal de Notes no puede hacer
ningn dao.)
Actualizacin de archivos actual del modelo:
Mantenida por los autores, comentaristas y lectores de
actualizacin de los kits que son recibidos. Pueden ser sacrificadas
en favor del Proyecto versiones maestras, como el proyecto
progresa.
Los archivos de trabajo:

Mantenido por autores y cualquier lector que inicia cualquier


intercambio ad hoc, entre los participantes que no tiene autor
oficial asignada. La hoja de portada Kit por ejemplo un lectorcomenz tema debe ser sugerente nombre, de modo que una
alfabtico de presentacin de contenido del kit puede ser paralelo
al oficial de Archivos de trabajo modelos, etc.
Archivos del proyecto:
Mantenido por el bibliotecario a las normas establecidas por la
administracin de proyectos.
Procedimiento C.6 El IDEF modelo paso a travs Adems del ciclo
de Kit, un procedimiento de paso a travs se ha desarrollado como
una gua para la presentacin de informacin del modelo a un
grupo de "revisores" (tal vez slo dbilmente con experiencia en la
comprensin de los modelos IDEF0 por su cuenta). No sustituye
por el Ciclo lector / Autor proceso de revisin que es fundamental
para el aseguramiento de la calidad del modelado IDEF0 (explicado
en C.2), pero puede ser racionalizado para uso peridico del
proyecto a nivel tcnico para proporcionar una oportunidad para
todos participantes para compartir o desarrollar interpretaciones
comunes que pueden no aparecer en el uno-a-uno intercambios
realizados con kits.
1. Presentar el modelo que se analiz mediante el uso de su ndice
de nodo. Este es el modelo de Tabla de contenido. Proporciona una
visin general de lo que est por venir.
2. Presente seleccionado los trminos del glosario. Alentar a cada
revisor para reemplazar personal significados de las palabras con
las que el equipo de presentadores ha elegido. Los significados no
deben ser cuestionado en este punto. Un cambio en el significado
ahora requerira muchos cambios en los diagramas.
3. Presentar cada diagrama para su revisin.
El proceso de caminar a travs de un diagrama es, paso a paso
proceso ordenado donde las preguntas pueden ser pidi que
puedan identificar posibles puntos dbiles en el diagrama o su
texto. Seis pasos de un proceso estructurado
walk-through sigue a continuacin.
Diagrama correcciones pueden ser propuestas en cualquier paso.
Estas correcciones se pueden observar para la ejecucin en una
fecha posterior o adoptado inmediatamente.
Paso 1: Analizar el diagrama.
Este paso permite al lector obtener impresiones generales sobre el
contenido del diagrama.
Por lo general, el lector habr revisado el diagrama de matriz que
representa el diagrama actual como uno de sus cajas. El lector
est examinando cmo el autor descompone esa funcin.
Criterios para la admisin:
1. La descomposicin es til para su propsito y se completa en el
contexto de su caja padre. Todas las funciones de nivel inferior
claramente pueden clasificarse en cada uno de sus cajas.
2. El diagrama refleja, en opinin del revisor, un punto de vista
relevante basa en

El propsito del modelo.


3. En la opinin del revisor, no existe suficiente informacin nueva
proporcionada a extender la comprensin de la caja padre. No hay
tanto detalle que la
Diagrama parece complejo y difcil de leer.
A menos que un problema es bastante obvio, la crtica se puede
retrasar hasta el Paso 3 a continuacin. Sin embargo, primero
impresiones no deben perderse. Ellos podran ser puestos en una
plataforma de pizarra o rotafolio hasta resuelto.
Paso 2: Mira el padre.
Una vez que el lector comprenda la descomposicin del diagrama
actual, el diagrama de los padres debe ser revisado para asegurar
la compatibilidad.
Criterios para la admisin:
1. La descomposicin cubre todos los puntos del revisor anticipa al
leer el diagrama de los padres.
2. Ahora que la descomposicin de esta parte del diagrama de los
padres se revela, la detalles que el revisor previsto para este
cuadro todava debe parecer correcta. Si no, observar el detalle
que falta.
Podra ser importante en este paso para volver al diagrama de
matriz brevemente y aadir nuevos n Notas (notas del lector) o
embellecer las existentes, basados en la idea de agregado
obtenida de este vistazo a la descomposicin.
Paso 3: Conexin de la caja padre y el diagrama de detalle.
Este paso pone a prueba las conexiones de la interfaz de la flecha
padres a hijos.
Criterios para la admisin:
1. No hay flechas de interfaz que faltan o extra.
2. flechas de contorno estn etiquetados con cdigos de ICOM
adecuados.
3. Nio etiquetas de direccin son los mismos o una elaboracin de
su matriz de la flecha correspondiente.
Etiquetas transmiten los contenidos de flecha correctos y
completos.
4. El examen de las flechas que conectan revelan no hay
problemas en el diagrama de los padres.
(Una interfaz aadida puede crear una mala comprensin del
mensaje transmitido por el padre.)
Un recorrido hacia la derecha de los cuatro bordes de la caja
padre, comprobando cada flecha, proporcionar una forma
metdica para comprobar la adecuacin de ICOM flechas cdigos
de lmites a las flechas de los padres.
Paso 4: Examine el patrn flecha interna.
El patrn de cajas y flechas constituye la expresin primaria del
modelo que se est creando.
Cada caja ser examinada con el fin nmero de nodo y cada flecha
sigui con el fin de ICOM cada caja. Cuando este proceso se haya
completado, los revisores deben ser conducidos a travs del
diagrama de explorar las consecuencias de las situaciones con las

que estn familiarizados los colaboradores y para probar la


capacidad del diagrama para simular las relaciones conocidas de
existir.
Criterios para la admisin:
1. El diagrama no se ve estorbado. El nmero de cruces y curvas
de flecha es minimizado.
2. Las cajas deben estar equilibrados con respecto a los detalles.
Debe haber un igual cantidad de detalles dentro de cada cuadro.
Sin embargo, los compromisos en este criterio son aceptables por
el bien de la claridad.
3. El diagrama debe ser consistente con la experiencia y el
conocimiento del revisor de la materia. Condiciones de
retroalimentacin y de error se deben mostrar como el revisor
espera.
4. El nivel de detalle de las flechas debe coincidir con el nivel de
detalle de las cajas.
El acoplamiento de las flechas en las flechas ms generales debe
ser considerado.
Paso 5: Lea la documentacin de apoyo.
Este paso se examinan los puntos que el autor destaca en el texto,
glosario y feos.
Criterios para la admisin:
1. El texto confirma la interpretacin obtenido de examinar el
diagrama de s mismo.
2. Normal: caminos, retroalimentacin, gestin de errores y otras
caractersticas sugeridas por el texto se encuentran en el
diagrama o que se encuentran en un FEO (para la exposicin
solamente) diagrama.
3. Caractersticas diagrama significativos descubiertos durante los
pasos 1-4 se encuentran en el texto, glosario o FEO.
4. Las referencias al diagrama son suficientemente detalladas para
conectar texto, glosario o FEO para partes especficas de un
diagrama.
Paso 6: Ajuste el estado del diagrama.
Ajuste el estado del diagrama (como se define anteriormente) a:
Trabajando
Borrador
Recomendado
Publicacin
ANEXO D - Definiciones informativos
Esta seccin contiene las definiciones que se refieren a los anexos
informativos de esta documento. Consulte la seccin 2 para las
definiciones de las secciones de carcter normativo. Un trmino, si
est definido, es definido ya sea en la Seccin 2 o en el Anexo D,
pero no en ambos.
D.1 Nivel de aprobacin: una de las siguientes cuatro palabras
asignadas a un modelo IDEF para indicar su grado relativo de
revisin y aprobacin:
Prctico (nivel ms bajo)

Proyecto (Al lado de nivel ms bajo)


Recomendado (Al lado de alto nivel)
Publicacin (nivel ms alto)
D.2 Autor: La persona que prepara y es responsable de cualquier
modelo especfico o IDEF diagrama.
D.3 La agrupacin: Las cajas son de divisin y agrupados en la
diagramacin. La agrupacin es la agrupacin de dos o ms cajas
para formar una sola caja. Su objetivo es combinar mltiples
funciones en un nico ms funcin general.
D.4 Comentario: Un lector con formacin suficiente en una tcnica
especfica para ofrecer IDEF comentarios usando el sistema de
numeracin lector de billetes y (a menudo) que se refiere a los
defectos en la aplicacin de la tcnica en s.
Un lector asignado la responsabilidad que comparte con el autor
de la calidad de un kit de IDEF, modelo, diagrama u otro resultado
IDEF.
D.5 Proyecto: Ver nivel de aprobacin.
D.6 Experto: Una persona familiarizada con una parte del sistema
del mundo real (o sujeto) que se est modelando.
Puede servir como una fuente de informacin o como un usuario
de una parte del modelo.
D.7 IDEF Papel: Una posicin en un proyecto IDEF. Ver autor,
experto, comentarista, lector y bibliotecario.
D.8 Kit: Un paquete estandarizado de diagramas que contienen
porciones de o completa al da modelos para ser revisados. Ver
Ciclo kit.
D.9 kit de la cubierta de chapa: Una forma especial que se utiliza
para controlar el enrutamiento de un kit a travs de un ciclo de kit.
D.10 Ciclo Kit: Un procedimiento Ciclo lector / Autor formal que
utiliza kits para la obtencin de pares o de expertos durante el
desarrollo del modelo.
D.11 Bibliotecario: La persona responsable de enrutamiento y
seguimiento de los kits y mantener ordenada archivos de proyecto
y archivos.
D.12 Proyecto de Campo: El campo en la forma de diagrama IDEF
que registra el nombre de la organizada tarea para la que se
prepara un modelo IDEF.
D.13 publicacin: Ver nivel de aprobacin.
D.14 Lector: Una persona con la capacitacin (limitada) en una
tcnica IDEF, con precisin suficiente para interpretar la sintaxis y
los significados bsicos y para leer y escribir notas de lectores, que
ve todo o parte de una modelo.
D.15 lector de Ciclo / Autor: procedimiento mediante notas del
lector para la obtencin de pares o de expertos opinin durante el
desarrollo del modelo.
D.16 Reader Nota: Un comentario de texto por un lector sobre un
diagrama IDEF0. Reader son notas no publicada como parte del
diagrama, sino ms bien se utilizan para la comunicacin durante
una
Ciclo / Autor lector.

D.17 Recomendacin: Ver nivel de aprobacin.


D.18 Usuario: un revisor comparte la responsabilidad por la utilidad
de un kit de IDEF, modelo, diagrama u otro resultado IDEF. Algunos
crticos carecen de la formacin de lectores, sino que participan en
los recorridos guiados.
D.19 Dividir: Cajas se dividen y se agrupan en la diagramacin.
Cuando una caja padre se detalla en una diagrama hijo, la caja
padre se divide en piezas, algunas de las cuales pueden entonces
ser agrupadas, para formar los 3 a 6 cajas en el diagrama hijo.
D.20 Papel: Igual que el IDEF papel.
D.21 de trabajo: Ver nivel de aprobacin.

You might also like