254
Engineering Systems Integration
project manager’s requests to streamline the development process. A part of
streamlining was to commit early to a design that met the requirements.
Typically, a design matures concurrently with the results from engineering
models and detailed analyses that expose additional requirements. As
there are relatively few tools that help shorten this transition time from
concept to a robustly considered scheme (Abeln 1990 as referenced in
Giachetti et al. 1997), a decision must be made with some uncertainty to
avoid time spent in rework. The technique offered by the mathematicians
is to apply fuzzy logic (a form of set theory introduced in the 1960s by Dr.
Lotfi Zadeh (Zadeh 1965)). The mathematicians plan to model the design
variables and specifications as a means of characterizing the differences
between the two designs. More specifically, the designs are based on different assumptions that are shown by differences in the objects and interactions. Without a way to determine the implications of these assumptions,
there is little on which to base a choice. Unlike the work presented by
Zimmerman and Sebastian (Zimmerman and Sebastian 1994 as referenced
in Giachetti et al. 1997) to represent imprecision, the project’s mathematicians believe that fuzzy logic can assist in the analyses of assumptions. By
representing assumptions as parts of one set (i.e., one design) versus
another set (i.e., the other design), and allowing for assumptions to have
partial membership in both sets, the designs can be instantiated in terms of
their dependencies on assumptions. Making a wrong choice (if in fact there
is a wrong choice) dooms the project to not deliver. Making a right choice
merely moves the possibility of making additional wrong (or right) decisions in time. Presumably, if wrong decisions are made later in the project,
the impact will be less than making a wrong decision earlier. The systems
engineer rightly recognizes there is no room for material error—a catastrophically wrong decision at the beginning of the project is a problem.
Defining the problem can be depicted as summarizing the situation, elaborating on a particular aspect of the situation, and explaining the situation
with relevant details. The forms of stating the problem (summarized, elaborated, and explicated) are detailed as follows:
• Summarized: The difference between making a decision without
analysis and knowing that the design best suited to meet the schedule
needs to be chosen, and you have no viable plan to succeed indicates
you have a problem.
• Elaborated: The difference between making a decision without analysis (and without carefully soliciting and considering all the opinions expressed by the project team) and knowing that the design
best suited to meet the schedule needs to be chosen (because difficult
times lie ahead for the entire project team should a catastrophically
wrong decision be made too early in development), and you have no
viable plan to succeed (should there be inordinate delays in the
work) indicates that you have a problem.
Engineering Systems Integration
project manager’s requests to streamline the development process. A part of
streamlining was to commit early to a design that met the requirements.
Typically, a design matures concurrently with the results from engineering
models and detailed analyses that expose additional requirements. As
there are relatively few tools that help shorten this transition time from
concept to a robustly considered scheme (Abeln 1990 as referenced in
Giachetti et al. 1997), a decision must be made with some uncertainty to
avoid time spent in rework. The technique offered by the mathematicians
is to apply fuzzy logic (a form of set theory introduced in the 1960s by Dr.
Lotfi Zadeh (Zadeh 1965)). The mathematicians plan to model the design
variables and specifications as a means of characterizing the differences
between the two designs. More specifically, the designs are based on different assumptions that are shown by differences in the objects and interactions. Without a way to determine the implications of these assumptions,
there is little on which to base a choice. Unlike the work presented by
Zimmerman and Sebastian (Zimmerman and Sebastian 1994 as referenced
in Giachetti et al. 1997) to represent imprecision, the project’s mathematicians believe that fuzzy logic can assist in the analyses of assumptions. By
representing assumptions as parts of one set (i.e., one design) versus
another set (i.e., the other design), and allowing for assumptions to have
partial membership in both sets, the designs can be instantiated in terms of
their dependencies on assumptions. Making a wrong choice (if in fact there
is a wrong choice) dooms the project to not deliver. Making a right choice
merely moves the possibility of making additional wrong (or right) decisions in time. Presumably, if wrong decisions are made later in the project,
the impact will be less than making a wrong decision earlier. The systems
engineer rightly recognizes there is no room for material error—a catastrophically wrong decision at the beginning of the project is a problem.
Defining the problem can be depicted as summarizing the situation, elaborating on a particular aspect of the situation, and explaining the situation
with relevant details. The forms of stating the problem (summarized, elaborated, and explicated) are detailed as follows:
• Summarized: The difference between making a decision without
analysis and knowing that the design best suited to meet the schedule
needs to be chosen, and you have no viable plan to succeed indicates
you have a problem.
• Elaborated: The difference between making a decision without analysis (and without carefully soliciting and considering all the opinions expressed by the project team) and knowing that the design
best suited to meet the schedule needs to be chosen (because difficult
times lie ahead for the entire project team should a catastrophically
wrong decision be made too early in development), and you have no
viable plan to succeed (should there be inordinate delays in the
work) indicates that you have a problem.