You are on page 1of 4
The Application of an Automated Software Tool for Modeling Test Processes Jefltey A. Rajhel, Support Systems Assoc., Inc. ABSTRACT ‘To obtain «consensus model of «complex system utlzing a verse group of people requlres « standard automated modeling tol Without tis ype of modeling too, various ‘models mast be interpreted wo be Incorporated ints a single Inodel, Mbsnterpretation ofthe diferent views is ineita ‘atsng model tobe incorrect. Use ofan automated tol {3 IDEFO wil eliminate integration problems because of its ‘tayo expen the pnt ofthe model in a standard graphle oy. INTRODUCTION In the past, limited results have been achieved in the ‘modcing oflarge systems. Unlike small systems where one ‘or two experts model the system and write a short cohesive ‘explanation ofeach section, large system modeling may use ‘many experts, For each sage ofthe process, a model is crested, resulting in a disjointed group of models ‘Automated tools were not uilzed to Tink the different rpodelstogetber to create a clear system model that could be ‘easily understod by technical end management personne. ‘A recent study, the Service Baseline ATS Processes and Opportunites for Automation Improvements, was ‘conducted by the DD's ATS Tr-Service Advisory Group (ATAG), To create the required large system model, the group clected to se Inegrated Definition Zero (IDEFO). The Integrated Definition Zero (IDEFO) is e standard tutomated graphical tool that portrays a system view at various levels of complexity through a hierarchical parent child relationship. The discussion of the IDEFO too, its attributes and its use by ATAG is the focus ofthe paper PROBLEM Over the past few decades the design and manufacturing fields have been significantly improved by the use of software tools (Comper Aided Design (CAD), Computer ‘Aided Manufacturing (CAM), Unfortunately, the ‘pplication of CADICAM tools limited to their respective fields. These design and manufacturing tools gather infermation which would be very useful to oer engineering { Activity [> Output Mechanism Figure 1 BASIC IDEFO DIAGRAM Information constraints are of four types, input, contro, output and mechmisms (ICOM), shown in Figure 1 surounding an activity box. Inputs are represenied by incoming arrows that shows the information or material ‘needed to perform a particular activity (eg, Raw Materials, Compencts). Controls describe the condition that overs sn activity end are shown coring in from the top of box (ee. procedures regulations). Outputs are represented as ‘outgoing arows from the right and show the information created when an activity is performed. (eg. reports, ‘produ. A mechanism is a person or device which carries ‘ut te activity and enters the activity box from the bottom (2, tools, people). An additional convention used by IDEFO is the tunnel. A tunnel is depicted graphically asa set of parentheses enclosing either the til or head of an serow. A tunnel enclosing the tail of an arow indicates the frst ccurrence indicating the arrow does not eppear inthe ‘parent diggrams. Ite tunnel exists atthe heed, then the ‘row does not appear inthe child diagrams. An activities shown as box is anything that can be named as en action (€eg develop, const ete), Box Numbers ere associated swith what level a particular activity occurs at within a model 308 Figue 2 ‘TOP LEVEL IDEFO DIAGRAM for TESTING Figures? md 3 ae two examples of IDEFO pages frm the ATAGS top level est architecture activity model, Figure 2 is the parent diagram of Figure 3. Note the more detailed view ofthe activities in Figure 3. This op down modeling ‘method, om general more specific, continues throughout the entire model until the model represents the system in ‘exough detail forthe needs ofthe project. The figures also display the expansion of the inputs, controls, outputs and ‘mechanisms asthe detail becomes refined. Figure 3 shows ‘anew cotol of "Component Design Information” entering ‘be Al ecivty box indicating the control did not come from the level above or parent diagram, Within Figure 3 some of ‘the ouput of activites feed back to other activities and are dashed lines. This convention may be used to indicate ‘ying but inthis cae the dashed line indicates problems. such as missing information ‘The ATAG grup extended the detail of design, production ‘and support areas to encompass test processes. The ‘operation process maintains a single level in the model ‘which eliminates the use of builin-test but the information ‘gathered from operation of the product is transfered tothe ‘support product sctvity trough operational maintenance data errow. ‘The design process elaborates on the ‘equiements ofthe pric and he supportabilty and trade off studies, In addition, the test and evaluation of the esigned product was expanded to significant detail. The production section ofthe model illustrates the creation and ‘enhancement of echnical documentuion, and the prodvetion ‘td procetion testing of product. The production testing (f prouct includes the focus on the various types of tests performed on a product and its components. The Inaintenanee of the product and the equipment used to support the product ae incorporated into the support section ‘of the model. Detailed exposition of test program set