close

Вход

Забыли?

вход по аккаунту

?

1063293X17735359

код для вставкиСкачать
Standard Article
Managing engineering change
requirements during the product
development process
Concurrent Engineering: Research
and Applications
1–16
Ó The Author(s) 2017
Reprints and permissions:
sagepub.co.uk/journalsPermissions.nav
DOI: 10.1177/1063293X17735359
journals.sagepub.com/home/cer
Inayat Ullah1, Dunbing Tang1, Qi Wang1, Leilei Yin1
and Ishfaq Hussain2
Abstract
Product redesign is not a straightforward task, specifically for complex commodities. Engineering change requirements
can be evoked in any phase of the product development process, thus making engineering change management a challenging task. The motive of this study is to explore the best possible way of managing engineering change requirements taking execution sequence of change requirements into consideration. In this article, a new approach supporting
engineering change requirements implementation sequence, by considering the risk associated with engineering changes,
is presented. The risk of the redesign is hard to foresee since the engineering change effects are being dispersed from
the instigating component to other associated components. In this article, the term of rework-risk is used for the
amount of rework needed to be done to redesign the products’ components. The practicality of suggested method is
analyzed using the redesign of an optical mouse as a case study. Managing engineering change requirements in a group
with proper sequence can ensue with a 15% decrease in the redesign duration as compared with the prompt implementation of engineering change requirements. Conversely, it can also cause 36.23% increase in the redesign duration, if not
handled in an appropriate sequence. The results from a single, simple case, indicates that running engineering change
requirement batches can be beneficial.
Keywords
engineering change requirement, product development process, rework-risk, redesign duration, design change urgency
Introduction
In today’s competitive environment, managing engineering change requirements (ECRs) efficiently cannot
be devalued. Time to market is a critical issue in the
manufacturing industry. In design and production
firms, there is a growing awareness that skilfully managing ECRs is the key to success (Inness, 1994). It is,
therefore, essential to explore the best possible way of
managing ECRs to reduce the product redesign time.
In this article, two different techniques, that is, individual and batch processing, are presented to manage
ECRs.
Product design and development is primarily driven
by needs and stakeholder requirements (Hull et al.,
2005). In the literature, requirements are defined as
statements, identifying system, or product constraints
necessary for satisfying stakeholder needs (INCOSE,
2010; Palmer et al., 2010). ECRs can be taken in two
different perspectives: changes triggered by innovation
and problem-oriented changes (Lindermann and
Reichwald, 1998). First, ECRs are considered as a
source of innovation and notably influential driving
factors of product design improvement (Eckert et al.,
2004). Second, ECRs cause reworks: the extraneous
effort of redesigning an activity or a process that was
erroneously realized the first time (Love, 2002). The
outcome of both changes leads to a value-added product. ECRs can be initiated at any stage during the
product development (PD) process, thus making the
1
College of Mechanical and Electrical Engineering, Nanjing University of
Aeronautics and Astronautics, Nanjing, China
2
College of Electronic and Information Engineering, Nanjing University of
Aeronautics and Astronautics, Nanjing, China
Corresponding author:
Dunbing Tang, College of Mechanical and Electrical Engineering, Nanjing
University of Aeronautics and Astronautics, Nanjing 210016, China.
Email: d.tang@nuaa.edu.cn
2
management of engineering changes (ECs) a challenging task (Vianello and Ahmed-Kristensen, 2012).
In early decades, ECs were predominantly seen as a
problem and people were reluctant to implement the
engineering change management (ECM) system (Acar
et al., 1998). From the last few decades, industrialists
construed it as an opportunity and source of innovation (Balogun and Jenkins, 2003; Eckert et al., 2004).
Every organization experiences ECs, therefore, its management practices need to evolve. ECs can benefit the
organization in many aspects such as cost reduction,
on-time delivery, and quality enhancement if they are
managed appropriately and implemented efficiently. It
can also elevate the firm’s reputation in the market.
ECRs should be categorized in a most refined manner,
depending on the class and the significance of the
change and should be managed with distinct techniques
to minimize the lead time (Balcerak and Dale, 1992).
Wright (1997) differentiated the research in the field of
ECM into two broad classes. First, tools to investigate
ECM issues, and second, techniques to minimize the
impact of changes in various aspects.
According to the classification made by Wright
(1997), this research work falls into the second category
with an aim to minimize the impact of ECs. Two different techniques, individual and batch processing, are
presented, and the comparison is made to decide the
best possible option. In the literature, discussion about
the execution sequence of ECRs in batch processing
has not been found. Therefore, this article focuses on
the influence of execution sequence in batch processing
to provide a technique for the better management of
ECRs during PD process. Change propagation model
based on the component design structure matrix
(DSM) is applied to explore different change propagation paths (CPPs) in the product’s structure. The technique is based on time computing models, where
iterations of earlier design activities are also considered.
Redesign change propagation evolution is carried out
by considering two types of mapping, that is, ‘‘And’’
and ‘‘Or.’’ Finally, to demonstrate the usefulness of the
proposed technique, an optical mouse is examined as a
case study. In the rest of this article, section
‘‘Background’’ presents a brief overview of the previous
related work, while detailed clarification of the suggested method is presented in section ‘‘Model framework and rework-risk assessment.’’ The evaluation of
the proposed algorithms is explained in section
‘‘Algorithms for managing single and multiple ECRs,’’
and the case study is discussed in section ‘‘Case description.’’ Finally, the conclusion and some directions for
future research are presented in section ‘‘Concluding
remarks and future work.’’
Concurrent Engineering: Research and Applications 00(0)
Background
ECRs play a critical role in the PD process. Besides,
identifying, maintaining, and satisfying a system’s
requirement are essential to the project’s success (Pahl
and Beitz, 1998; Ullman, 2003; Ulrich and Eppinger,
1995). Due to requirement issues, PD failure and unnecessary increase in the cost, time, and quality problems
have been observed by Worinkeng and Summers
(2014), which are illustrious contributing factors of
competitive advantage in the market. ECRs are identified as the second leading source that challenges the
project’s success (The Standish Group, 1995).
One of the major problems in managing ECRs is the
lack of planning when changing them (Hull et al.,
2005). ECs may have severe implications on the design
time, cost, and quality of a product if not managed
effectively (Hamraz et al., 2013). The literature related
to ECM is comparatively limited to the other topics
such as the product life cycle management (Jarratt
et al., 2011). ECRs are one of the dominant determinants that encourage disruptions and cost overrun of
projects, which subsequently cause claims, conflicts,
and consumer’s disappointment. The clients usually
instigate most of the ECRs as new requirements or by
the firm as improved specifications. ECRs can also be
stirred during an artifact’s use due to faults’ rectification, parts’ substitution, or alterations for upgrading
near the end of product life (Nadia et al., 2006).
Inefficient management of ECRs can cripple the productivity of a firm.
In PD process, the components that are considered
to be completed might have a chance to change (Huang
and Mak, 1999). Due to an inadequate ECM system,
sometimes the defective product is launched to the market, thus affecting the customers. Moreover, it can also
impair firms’ reputation in the market and can incur
substantial recovery cost. A study conducted by
Wasmer et al. (2011) showed that 20%–40% of the
lead time could be reduced by properly managing ECs.
In a new PD process, the occurrences of design changes
can affect productivity up to 24% and lead time up to
44% (Li and Moon, 2012). Process modeling and a
simulation-based approach were used to manage the
ECRs in a new PD process (Nadia et al., 2006). It is
revealed from the literature that cumulative effect of
ECR propagation at any scale can have detrimental
consequences on the project (Giffin et al., 2009;
Morkos and Summers, 2010; Shankar et al., 2012).
Limited research has been performed to effectively
model and manage ECRs fluctuations and changes
(Harker et al., 1992; Lam and Shankararaman, 1999;
Sugden and Strens, 1996). Most of the research work,
done so far in the field of ECRs management, is of
Ullah et al.
qualitative nature and emphasizing particular case
studies in a specific firm (Reidelbach, 1991; Watts,
1984). Therefore, it is essential to manage ECRs to
ensure that the effects are not detrimental (Nuseibeh
and Easterbrook, 2000). A designer may save time and
money if the overall effects of ECRs could be assessed
before its implementation (Ollinger and Stahovich,
2001).
3
EC implementation (DiPrima, 1982; Maull et al.,
1992):
EC
An EC is a fact and should be considered as a routine
job. EC is defined by numerous researchers (Huang
and Mak, 1999; Terwiesch and Loch, 1999; Wright,
1997) in a different perspective. The complete definition
is given by Jarratt et al. (2004) by considering the
scope, size, time, and type of change. Numerous
researchers (Eckert et al., 2004; Nadia et al., 2006;
Terwiesch and Loch, 1999) categorized ECs based on
the artifact such as coming from the products (emergent changes) and originated from outside of the product (initiated changes). ECs can trigger at any point
during PD process (Huang et al., 2003; Lee et al., 2006;
Terwiesch and Loch, 1999), which are considered as
the means by which the product evolves (Masmoudi
et al., 2017).
EC need is raised from different sources as a result
of numerous reasons such as technology evolution,
product functionality improvement, innovation, current legislative requirements, safety concerns, and customer requirements (Eckert et al., 2003; Huang and
Mak, 1998; Keller et al., 2009; Mohringer, 2006; Pikosz
and Malmqvist, 1998; Wright, 1997). According to
Mohringer (2006), ECs can be originated at the firm’s
level due to three main origins or sources, that is, suppliers, customers, and internal departments. Earl et al.
(2005) studied ECs in terms of changing descriptions.
Kidd and Thompson (2000) in their study summarized
the economic significances of ECs, which are made during the design process. ECs were classified into minor,
general, and major changes by Yu et al. (2013). In a
study conducted by Balcerak and Dale (1992), the
authors concluded that categorization of changes
should be established by two determinants: first, the
urgency of change and second, the impact of change on
the product.
EC urgency. ECs can arise in different circumstances to
address the need. It depends on the requirement that
how quick response is required to implement the
desired change. ECs are classified into three distinct
categories, that is, immediate, mandatory, and convenience changes, which indicate a degree of urgency for
Immediate changes must be executed on a priority
basis to resolve the issues. Safety- and defect-related
concerns fall into this category. Safety-related
affairs have no concern with economic boundaries
(Inness, 1994).
Mandatory changes should be implemented as soon
as possible, but there is some time flexibility. New
legislation or certification requirement, repair and
maintenance, and product quality-related issues fall
into this category.
Convenience changes can be carried out at the manufacturer’s ease. Changes related to the product’s
esthetics, the customer’s request regarding improvement in range, the performance of the product, and
new technology are regarded as convenient
changes.
EC impact. EC request plays an important role during
the PD process (Pahl and Beitz, 1998; Ullman, 2003).
To evaluate the possible impact of ECs is the most crucial task in change propagation process. Clarkson et al.
(2004) define impact as ‘‘the average proportion of the
design effort that will require being redone if the
change propagates.’’ Three determinants have influenced the impact of a change on a product: product
structure, product intricacy and the degree of innovation within the product (Jarratt et al., 2011).
Numerous methods have been proposed to simulate
and analyze the change propagation in an artifact, to
allocate resources, cost, and time according to the
impact of the change (Cohen et al., 2000; Hamraz
et al., 2012; Li and Zhao, 2014; Tang et al., 2016). The
connectivity between product’s components via rework
probability and impact allows the flow of information
between components. The values of both rework probability and impact may be achieved from the history of
previous design changes and/or interviewing the expert
designers (Clarkson et al., 2004). The risk defined by
Van Bossuyt et al. (2013) as ‘‘the possibility of happening of an event multiplied by the intensity of its consequences’’ is adopted in this article. In this research
work, two types of rework-risks, namely, initial and
propagated rework-risk are considered. Initial reworkrisk depends on the severity of ECR and is divided into
three different categories as detailed in Table 1.
Whereas, propagated rework-risk depends on the connectivity and iterations between the design components. The summation of both risks is termed as
accumulated risk, which varies from 0 to 1. Besides, in
the suggested model 1 indicates maximum risk and 0
refers to no risk.
4
Concurrent Engineering: Research and Applications 00(0)
Table 1. Initial rework-risk categorization.
S. no.
Risk classification
Risk range
1
2
Low initial rework-risk (LIR)
Medium initial
rework-risk (MIR)
High initial rework-risk (HIR)
0 \ LIR 0.35
0.35 \ MIR 0.7
3
0.7 \ HIR 1
Research motivation and assumption
The authors of the extant studies in this field have not
focused on the execution sequence of ECRs in a batch
processing. Therefore, the objective of this article is to
address this gap in the pertinent literature by answering
the following research questions:
What is the best feasible way to execute ECRs?
What is the impact of the ECRs execution sequence
on the PD process?
Following three assumptions are made in the suggested techniques:
ECRs will fall into the category of convenience and
mandatory changes.
When the accumulated risks become greater than
‘‘1,’’ it should be replaced by ‘‘1.’’
Each ECR is specifically related to each
component.
Model framework and rework-risk
assessment
Change propagation network for single and multiple
ECRs
In this article, two distinct models, namely, single and
multiple ECRs, are presented. The suggested models
evaluate the progress of PD process over time, to investigate the optimal way of managing ECRs. These models require information about different design
components that integrate the PD process, that is,
rework probability and impact, logical dependencies,
component design duration, and instigating components. The components’ rework probability and impact
are presented in the form of DSM, which is a square
matrix. A DSM provides an easy way to recognize the
structure of event linkages as illustrated in Figure 1(a).
A marking ‘‘ 3 ’’ in the off-diagonal cell represents the
information flow between the corresponding design
components. The off-diagonal cell in the ith row
(Component B) and the jth column (Component D)
denotes the relationship that is defined as the ith row
component ‘‘B’’ affects the jth column component ‘‘D.’’
Which implies that the jth column component ‘‘D’’
receives information from the ith row component ‘‘B.’’
In a complex product design, the components are
interconnected in a closed fashion; therefore, logical
relationships ‘‘And’’ and ‘‘Or’’ exist between them. The
logic relationship ‘‘And’’ represents that various downstream components are affected by an upstream
component simultaneously. Conversely, the logic relationship ‘‘Or’’ accounts for the fact that only one downstream component is influenced by an upstream
component at a time. Due to the presence of logical
relationships between components, parallel and sequential change propagation patterns exist in the design process. A logical dependency matrix for illustrated
example is shown in Figure 1(b). The numerals in the
cells indicate the existence of logical dependency
between the components. If digits in a row are the same,
then ‘‘And’’ logical dependency exists between the corresponding components. Otherwise, the logical dependency ‘‘Or’’ occurs. For instance, if component D is
modified, then components B and C may be changed
concurrently due to the presence of ‘‘And’’ logical
Figure 1. (a) DSM—information flow interaction and (b) logical dependencies between components.
Ullah et al.
5
between components. Change initiated in one component propagates to the other connected components.
Therefore, the total execution cost comprises the redesigning cost of the initial aspects of design and also
caused by change propagation. Once the component
dependencies have been captured, the possible CPPs
can be determined. Distinct ECRs have different initial
rework-risks, termed as, planned rework-risk, that
depend on the degree up to which the initiating component should be affected by the change request. One
CPP as a result of ECR(s) is highlighted in Figures 2
and 3.
Figure 2. Change propagation network in a product’s
structure as a result of single ECR. Change initiated in
component c1 due to engineering change requirement (ECR).
Layers1 2 k represent the change steps.
dependency. However, if change propagates to component A, it may be changed alone because of ‘‘Or’’ logical
dependency. The change flow between the components
is explained by considering a product consisting of m
components as shown in Figures 2 and 3.
For managing ECRs, two primary approaches are
considered. First, ECRs are implemented on an immediate basis when they are raised as shown in Figure 2.
Second, ECRs are accumulated and then executed at
once as presented in Figure 3. In both methodologies,
same ECRs are utilized to explore an effective strategy.
In Figures 2 and 3, c1 to cm denote the number of product’s components, whereas K2p represents the number
of change steps as a result of ECR2. In both cases, n
distinct ECRs are initiated during the PD process in a
single product. The arrow lines depict the dependency
Rework-risk propagation and assessment
Quantitative risk analysis based approach is suggested
to manage ECRs during the PD process. Information
interaction between design components as a result of
product functionality usually leads to rework in PD
process. The links between product’s components by
rework probability and impact permit the changes to
propagate to the associated components. The rework
probability and impact have values between 0 and 1.
Rework-risk by its very nature always has some negative impact in terms of cost, schedule, and quality. The
proposed model relates the rework-risk to the amount
of rework needed to be done to accomplish the ECRs.
Let us consider a product comprising of m components. As a result of ECR, component ci propagates
the change to component cj with the rework probability
of RPij and rework impact of RIij. Then, according to
Van Bossuyt et al. (2013) and Zhang et al. (2015), the
rework-risk RR(ci, cj) between directly connected components can be expressed as
Figure 3. Change propagation network in a product’s structure as a result of multiple ECRs. Change initiated in different
components c3, c2, and c1 due to multiple engineering change requirements (ECRs). Layers represent the change steps for a
particular change requirement.
6
Concurrent Engineering: Research and Applications 00(0)
RR(ci , cj ) = RPij 3 RIij
ð1Þ
In equation (1), i and j denote the change instigating
and affected components, respectively. CPPs are the
chain of changes that consist of two distinct types of
rework-risk, that is, planned rework-risk PlRR and
propagated rework-risk PrRR. Planned rework-risk is
caused as a result of ECR because it must be executed
to fulfill the need. Conversely, propagated rework-risk
is produced due to the change propagation. Both the
risks can be expressed as
Pl RR(r, ci ) = RPr, i 3 RIr, i
ð2Þ
Pr RR(ci , c1 ) = RPi, 1 3 RIi, 1
ð3Þ
In equation (2), RPr,i and RIr,i are the rework probability and impact because of the change request r, respectively. Whereas, in equation (3), PrRR(ci, c1) is the
propagated rework-risk between the instigating component ci and the directly connected component c1.
Likewise, change propagation takes place throughout
the whole product structure. The rework probability
and impact are defined for the components that are
directly linked to each other. However, changes can
propagate to other components, which are not directly
connected. By considering both effects of change propagation, the predictive model is extended to calculate
the cumulative rework-risk, as a result of single ECR
and can be expressed as
RRkr (ci , cj ) = Pl RR(r, ci ) 3 Pr RR(ci , c1 ) 3 Pr RR(c1 , c2 )
3 3 Pr RR(ck2 , ck1 ) 3 Pr RR(ck1 , cj )
ð4Þ
In equation (4), RRkr (ci , cj ) is the rework-risk between
the instigating component ci and the end component cj
to realize ECR r in k change steps through k 2 1 components. Equation (4) can be generalized for n number
of change requests as follows
In equation (6), k1 up to kn represent the number of
change steps in the same CPP for specific change
requests. Iterations are the essential characteristic of
the design process, and even small changes in iterationlikelihoods can have substantial impacts on process
effort and duration in concurrent design processes
(Shapiro et al., 2015). Iterations are mostly triggered by
incomplete information (Hollins and Pugh, 1990).
During each iteration, designer’s familiarity and experience boost regarding product design. Therefore, less
effort is needed to accomplish the design tasks in successive iterations (Maier et al., 2014). Each iteration
serves to improve the results and increase the product
quality. In the proposed model, computation of the PD
time is facilitated by incorporating the learning effect.
During the change propagation process, the component
affected by an upstream component to a small amount
will also influence the downstream component to a little extent and vice versa. Therefore, the risk propagated
to the downstream component depends on the change
risk of an upstream component. Thus, the risk propagated from a component i to j in the xth change iteration, considering the learning effect, can be expressed
as follows
RR(ci , cj )½x = (RPij 3 RIijx ) 3 RR(ci1 , ci )
ð7Þ
Andersson et al. (1998) defined a curve termed as
‘‘learning-by-doing,’’ in which the accomplishment time
decreases because of each iteration with an associated
learning curve function. Therefore, equation (7) is
derived based on the assumption that the component
change impact has a nonlinear relationship with the
number of iterations between each pair of components
to incorporate the learning effect. The total redesign
duration (TRD) of any CPP to be resolved completely
can be expressed as
9
RRKr1 r2 rn (ci , cj ) = ½ ½½Pl RR(r1 , ci1 ) 3 Pr RR(ci1 , cr11 ) 3 Pr RR(cr11 , cr21 ) 3 3 Pr RR(crk11 2 , crk11 1 ) 3 Pr RR(crk11 1 , ci2 ) >
>
r2
r2 r2
r2
r2
r2
>
+ Pl RR(r2 , ci2 ) 3 Pr RR(ci2 , c1 ) 3 Pr RR(c1 , c2 ) 3 3 Pr RR(ck2 2 , ck2 1 ) 3 Pr RR(ck2 1 , ci3 ) >
>
>
=
..
.
>
>
..
>
>
.
>
>
;
rn
rn rn
rn
rn
rn
+ Pl RR(rn , cin ) 3 Pr RR(cin , c1 ) 3 Pr RR(c1 , c2 ) 3 3 Pr RR(ckn 2 , ckn 1 ) 3 Pr RR(ckn 1 , cj )
ð5Þ
In equation (5), cin represents the instigating components, while crknn 2 denotes the intermediary components
for a particular ECR in the CPP. Moreover, k indicates
the whole number of change steps in the CPP to realize
the desired n number of change requests in a product
and can be expressed as
ð8Þ
K = k1 + k2 + k3 + + kn
ð6Þ
TRD =
y
X
RRi1, i 3 DDci
i=1
In equation (8), y denotes the number of changes
caused by ECRs in a single CPP to fulfill the desired
need, and DDci represents the component design
Ullah et al.
7
Figure 4. Flowchart for exploring propagation paths as a result of single ECR.
duration. The design duration of each component may
be in days or months, depending on the project.
Algorithms for managing single and
multiple ECRs
For the better management of ECRs during the PD
process, two algorithms based on the above-mentioned
mathematical model in different formats are proposed.
First, execute the change request promptly when it
occurs, as explained in Figure 4.
Second, the ECRs are accumulated, which is followed by execution when a certain lot size is grouped,
as detailed in Figure 5.
Graph-based search technique is used to explore different CPPs in the suggested algorithms because the
graph takes account of cycles, which represent iterations in the PD process. The algorithm proposed by
Dijkstra (1959) is used to explore the shortest paths
from a single initiating node to all other nodes in the
graph. Whereas, the advanced algorithms can discover
the most time-saving CPPs initiating from a single or
multiple components to the associated components.
Moreover, the Dijkstra algorithm is used to explore the
paths between finite nodes, and the node once visited
will never be checked again; consequently, no stop criterion and iteration are considered in the algorithm.
Queue data structure is applied, which works on the
principle of first-in, first-out (FIFO). It implies that the
child components attained by expanding the parent
component are added to the FIFO queue, and they are
explored in the same order in which they arrived. In the
proposed algorithms, when the instigating component
is selected, it explores all the descendants of the
initiating component before exploring any successor of
its child components. Both the algorithms systematically search the paths to explore every component,
which is reachable from the instigating component.
In a single ECR algorithm, two data arrays are
introduced, that is, traced array and propagated path
array. Whereas, in a multiple ECRs algorithm, one
additional array named as instigating components
array is presented. Traced array in both algorithms is
used to keep track of the in-process CPPs, while propagated path array maintains a record of the completed
paths. Instigating components array in multiple ECRs
algorithm stores the data of change initiating components, which depend on the number of ECRs. The inprocess CPPs are stored in the form of layers in traced
array, and it serves on the rule of FIFO queue. From
the literature, it is revealed that changes can usually
propagate up to four change steps (Pasqual and De
Weck, 2012); therefore, it is used as a stop criterion in
the suggested algorithms.
Inputs to both the algorithms are rework probability
and impact matrices, logical dependency matrix, component design duration, instigating components, and
the number of change steps. When the simulation is
run, the planned rework-risk as a result ECR r1 is calculated and all the child components along with the
parent component are stored in the succeeding layer of
the traced array. In each step, it will assess the type of
logical dependency that exists between the components.
Then, the process will check the repetition of the design
component pair to add the learning effect in the process. Whereas, in the case of multiple ECRs, it will also
check that the new component is an instigating component or not. In the case of instigating component, the
8
Concurrent Engineering: Research and Applications 00(0)
Figure 5. Flowchart for exploring propagation paths as a result of multiple ECRs.
planned rework-risk due to change request rn will be
calculated and added to the propagated rework-risk. If
the accumulated rework-risk becomes greater than ‘‘1,’’
then it should be replaced by ‘‘1,’’ which means that the
whole design of the component should be changed. In
both algorithms, if the number of change steps in propagated path reaches up to four, then the path will be
stored in the propagated path array along with TRD.
Next, the simulation run will go back to the traced
array to pick the succeeding path and hence repeat the
process. Conversely, if the number of change steps is
less than the defined value, then it will pick all the child
components and add it to the traced array along with
the parent component in the succeeding layer and
repeat the process. The simulation will be executed
until the traced array is empty. Thus, all the CPPs from
different instigating components to the associated components are explored.
Case description
To demonstrate the usefulness of the proposed methods, the design project of an optical mouse is considered. The dependencies between the components and
Ullah et al.
9
Table 2. Completion time of design components (Kang and
Hong, 2009).
S. no.
Design components
Completion time (days)
1
2
3
4
5
6
7
8
9
Connection cable
Top case
Bottom case
Wheel mechanism
Main board
Microprocessor
Click mechanism
Balance weight
Optical sensor
2
11
8
6
8
8
3
2
6
their design duration are taken from the article by
Kang and Hong (2009). The designers’ team from the
optical mouse manufacturing company was consulted
regarding the initial assessment of the suggested
approaches. The designers have vast experience in the
related field. Both the approaches were evaluated by
the designers, and it was found that the methods could
help to better focus discussions on management strategies of design change requests. The optical mouse component list, along with expected completion time, is
presented in Table 2. However, numeric DSMs provide
information regarding dependencies and logical relationships between components, as illustrated in
Figures 6 and 7.
In Figure 6, the number above the line in each cell
represents the rework probability, whereas the number
below the line denotes the rework impact. For instance,
a rework probability of 0.3 at the position of the design
component (i, j) means that there is a 30% probability
for changes to propagate to the component j when
component i is completed. The logical dependencies
between components have been acquired by consulting
the designers from the manufacturing firm, as shown in
Figure 7.
For instance, a design change is made in Bottom case
(E3), which has a 70% probability to propagate the
changes to Microprocessor (E6), with the rework
impact of 90%. The rework-risk for a given design component can be estimated by multiplying the respective
values of rework probability and impact. Moreover,
component redesign time can be computed by multiplying the rework-risk by the expected completion time.
Three design changes in an optical mouse are proposed
by the designer to explore the best possible approach
for managing ECRs. The designer based on his experience suggests the initiating components, that is, Bottom
case (E3), Microprocessor (E6), and the Optical sensor
(E9) having initial rework-risk of 0.5, 0.9, and 0.7,
respectively. The following sub-sections explain that
how ECRs can be implemented in two different ways.
Immediate implementation of ECRs
In this method, ECRs are executed without any delay,
and the rework is done immediately. In this case study,
instigating components are categorized based on the
risks mentioned in Table 1, and it is considered that
change initiating components have medium and high
Figure 6. Probability and impact matrix for optical mouse design process (Kang and Hong, 2009).
10
Concurrent Engineering: Research and Applications 00(0)
Figure 7. Logical dependencies between the components of optical mouse.
Figure 8. Redesign duration of CPPs in three different cases.
initial rework-risks. The change requests are implemented separately in three distinct components, and as a
result, several CPPs are achieved. The redesign duration
of all possible CPPs in three different cases are shown
in Figure 8.
It is evident from Figure 8 that all the CPPs have
different redesign duration, as well as the number of
CPPs also varies. The Bottom case (E3) has medium
initial rework-risk of 0.5; therefore, it gives minimum
redesign duration as compared to other instigating
components. In Bottom case (E3), a sudden increase in
the redesign duration can be seen in Figure 8: this rise
is due to high propagated risk between components
Bottom case (E3) and Microprocessor (E6), as shown in
Ullah et al.
11
Table 3. Accumulative number of distinct change components
involved in several CPPs.
S. no.
Number of CPPs
CPPs (%)
Number of distinct
components
1
2
3
4
5
6
7
8
6
42
116
236
627
1408
830
107
0.18
1.25
3.44
7.00
18.59
41.76
24.61
3.17
2
3
4
5
6
7
8
9
CPP: change propagation path.
Figure 9. Number of distinct components in various CPPs for
all the three initiating components.
Figure 6. The Optical sensor (E9) and Microprocessor
(E6), both have high initial rework-risk of 0.7 and 0.9,
respectively. Therefore, they contribute substantially to
accumulative redesign duration. From the above, it can
be inferred that for any instigating component, the
number of CPPs depends on three factors, that is, (1)
the number of directly connected components, (2)
rework probability and impact values, and (3) the presence of logical dependency between components.
Different CPPs have distinct design components. It
can be seen in Figure 9 that the frequency distribution
of propagated path containing different design components varies for all the three instigating components.
For Bottom case (E3), the number of distinct components reaches up to nine, while in the case of
Microprocessor (E6) and Optical sensor (E9), it reaches
up to eight. Although Microprocessor (E6) and Optical
sensor (E9) have high initial rework-risk, the number of
distinct components is less than Bottom case (E3). It
owes to the fact that Bottom case (E3) propagates
changes to the components, which have ‘‘And’’ logical
dependency, as shown in Figure 7.
It can also be witnessed from Figure 9 that in
Bottom case (E3), 45.35% and 30.80% of CPPs contain
seven and eight numbers of distinct components,
respectively. Whereas, in Microprocessor (E6) 32.61%
and Optical sensor (E9) 25% of CPPs comprise seven
number of distinct components. From this analysis, it
can be established that increase in a number of CPPs
and distinct components not only depends on the initial
rework-risk but also on the components to which the
change is propagated and the logical dependencies
between them. To analyze the accumulative results,
consider Tables 3 and 4. The number of distinct change
components involved in different CPPs is presented in
Table 3, whereas accumulative redesign duration and
CPPs are shown in Table 4.
ECRs implementation in batch
In batch processing, an appropriate sequence of ECRs
is identified to avoid futile effort during the redesign
process. Whereas, an appropriate sequence can be
defined as ‘‘the best possible sequence of ECRs that
provides minimum redesign duration for the implementation of initiated change requests.’’ First, ECRs are
gathered in a group of a predefined size, followed by
the execution process. In this case study, a group size of
three ECRs has been defined. Therefore, each sequence
comprises three components. The Bottom Case,
Microprocessor, and Optical Sensor are the instigating
components for each ECR. To implement the design
changes, the designer should decide the execution
sequence of ECRs. In this case study, following six possible sequences of design changes can be implemented:
Bottom case (E3)–Microprocessor (E6)–Optical sensor (E9);
Bottom
case
(E3)–Optical
sensor
(E9)–
Microprocessor (E6);
Microprocessor (E6)–Bottom case (E3)–Optical sensor (E9);
Microprocessor (E6)–Optical sensor (E9)–Bottom
case (E3);
Optical
sensor
(E9)–Bottom
case
(E3)–
Microprocessor (E6);
Optical sensor (E9)–Microprocessor (E6)–Bottom
case (E3).
In all the six sequences, changes are initiated in different instigating components to satisfy the change
requirements. As a result, several CPPs are obtained to
12
Concurrent Engineering: Research and Applications 00(0)
Table 4. Accumulative redesign duration and number of CPPs.
S. no.
Component
description
Minimum redesign
duration (days)
Maximum redesign
duration (days)
Average redesign
duration (days)
Propagation
Paths
1
2
3
Bottom case
Microprocessor
Optical sensor
Total
4.19
7.28
6.54
18.01
6.94
8.45
8.07
23.46
4.29
8.24
7.09
19.62
2516
696
160
3372
CPP: change propagation path.
Table 5. Redesign time and CPPs for six different sequences.
S. no.
Sequence
Minimum redesign
duration (days)
Maximum redesign
duration (days)
Average redesign
duration (days)
Propagation
Paths
1
2
3
4
5
6
E3–E6–E9
E3–E9–E6
E6–E3–E9
E6–E9–E3
E9–E3–E6
E9–E6–E3
15.62
15.60
15.64
17.73
10.73
12.29
45.13
48.07
22.12
33.61
32.38
24.04
26.74
26.64
18.80
24.19
18.82
17.06
968
442
23
532
78
82
CPP: change propagation path.
Figure 10. Redesign duration of CPPs in batch processing.
implement the changes. The redesign duration of all
the propagated paths in the entire sets of sequences is
presented in Figure 10.
The redesign duration and number of CPPs of the
entire sets of sequences are indicated in Table 5. All the
six sequences have different minimum and maximum
redesign duration to resolve the change requests as
shown in Table 5. By comparing the results of both
approaches, it can be observed that all the six sequences
in batch processing have a smaller minimum redesign
duration than the accumulated minimum redesign duration in individual processing. However, only one
sequence E6–E3–E9 has a smaller maximum redesign
duration than the cumulative maximum redesign duration in individual processing. In product designing,
some tolerances are kept in the component parameters,
which decrease over a period due to the incorporation
of changes. Moreover, the strategy of design freeze is
used for standardized and expensive components.
Therefore, the designer should avoid the propagated
path, which contains such components, despite the fact
that they have minimum redesign duration. In view of
the above, the conclusion is made on the basis of average redesign duration because it represents the entire
sets of propagated paths. The average redesign duration
of three sequences, that is, E6–E3–E9, E9–E3–E6, and
E9–E6–E3 provide better results than the individual processing as highlighted in Table 5, while other three give
the worst result as compared with individual processing.
It can be apprehended from Figure 11 that the path
distribution in all the six sequences is different in perspective of a numbers of distinct design components. It
is evident from Figure 11 that seven and eight numbers
of distinct components are involved in 85.54% and
88.69% of CPPs in sequences E3–E6–E9 and E3–E9–E6,
respectively. Whereas, in sequences E9–E6–E3 and E6–
E3–E9, the path distribution is almost uniform. The
entire sets of sequences have 71.55% of propagated
paths, which contain seven and eight numbers of distinct change components while only 5.04% of CPPs
contain nine numbers of distinct change components as
shown in Figure 11. In most cases, the propagated path
comprising a fewer number of change components will
be easier to execute the changes with lesser time. The
Ullah et al.
Figure 11. Number of distinct change components in various
CPPs for six different sequences.
results from the above-conducted study show that performing ECRs in a batch with a proper sequence has a
significant impact on the design process duration. To
verify these findings further, the outcomes were later
presented to the designer team from the optical mouse
manufacturing company. The designers appreciated
achieved results and stated that they have no idea that
the execution sequence of ECRs has such drastic effects
on the redesign duration of CPPs. The designers’ team
suggested that the proposed technique may be assessed
further by considering more complex case examples.
Concluding remarks and future work
Managing ECRs in a batch processing with appropriate sequence provides better results than individual
processing. Moreover, ECRs execution sequence has a
substantial effect on the PD process in terms of lead
time. In this article, two different techniques individual
and batch processing were introduced to manage ECRs
during the PD process. These techniques are based on
the time computing models where iterations of the earlier design components are also considered. The process
starts with building the product model in view of the
rework probability and impact matrices. The product
design process is described by considering the logical
relationships ‘‘And/Or’’ between the components.
ECRs are categorized by urgency and rework-risk,
whereas the term rework-risk is applied to the amount
of rework required to be done to redesign the product’s
components. All the CPPs are explored in product’s
structure using the proposed algorithms and a mathematical model.
An example based on an optical mouse design process illustrated the feasibility of the suggested methods.
Three ECRs having different initial rework-risks are
considered to compare the outcomes of both
approaches. In the first method, after the change
13
initiation, ECRs are implemented immediately and the
rework is done without any delay. While in the second
approach, ECRs are treated in a batch and the execution takes place when a group of predefined size is collected. In batch processing, six possible sequences of
design changes are implemented. The sequence E9–E6–
E3 causes 15% decrease in the redesign duration of
CPPs whereas another sequence E3–E6–E9 results in
36.23% increase in the redesign duration of CPPs as
compared with individual processing. Based on the case
study, it can be inferred that the number of CPPs and
distinct design components not only depends on the initial rework-risk but also on the components to which
the change is propagated and the logical dependencies
between them. The results from a single, simple case
study indicates that running ECR batches with proper
sequence can be beneficial.
The authors, however, admit that more work is
required to validate the modeling approach further. The
case study discussed in this research work is simple, having a few coupled components, whereas the component
dependencies increase substantially in complex products.
Therefore, the suggested approach may be extended to
complex systems, which as a result increases the research
scope and also provides opportunities to assess the techniques against more complex products. The proposed
approach has one limitation: it cannot be applied if
ECRs are of safety critical nature. Because, in safety critical nature ECRs, an immediate action is required as the
process is much more focused on the quality and functionality of the product rather than the lead time or cost.
Acknowledgements
The authors express their gratitude to the anonymous
reviewers for their insightful feedback.
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with
respect to the research, authorship, and/or publication of this
article.
Funding
The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this
article: This work was supported by the National Natural
Science Foundation of China under grant number 51575264
and Qing Lan Project.
References
Acar BS, Benedetto-Neto H and Wright IC (1998) Design
change: problem or opportunity. In: Engineering design
conference, Brunel University, UK, 23–25 June 1998, pp.
445–454. London, UK: Professional Engineering Publishing.
14
Andersson J, Pohl J and Eppinger SD (1998) A design
process modeling approach incorporating nonlinear
elements. In: ASME 10th international conference on
design theory and methodology, Atlanta, GA, 13–16
September.
Balcerak KJ and Dale BG (1992) Engineering change administration: the key issues. Computer Integrated Manufacturing Systems 5(2): 125–132.
Balogun J and Jenkins M (2003) Re-conceiving change management: a knowledge-based perspective. European Management Journal 21(2): 247–257.
Clarkson PJ, Simons C and Eckert CM (2004) Predicting
change propagation in complex design. Journal of Mechanical Design 126(5): 788–797.
Cohen T, Navathe SB and Fulton RE (2000) C-FAR, change
favorable representation. Computer Aided Design 32(5–6):
321–338.
Dijkstra EW (1959) A note on two problems in connexion
with graphs. Numerische Mathematik 1(1): 269–271.
DiPrima M (1982) Engineering change control and implementation considerations. Production and Inventory Management 23(1): 81–87.
Earl CF, Eckert CM and Clarkson PJ (2005) Design change
and complexity. In: 2nd workshop on complexity in design
and engineering, Glasgow, 10–12 March.
Eckert C, Clarkson PJ and Zanker W (2004) Change and customisation in complex engineering domains. Research in
Engineering Design 15(1): 1–21.
Eckert CM, Pulm U and Jarratt TAW (2003) Mass customization, change, and inspiration–changing designs to meet
new needs. In: Folkeson A, Gralen K, Norell M, et al
(eds) 14th international conference on engineering design,
Stockholm, Sweden, 19–21 August, pp. 1–10. Glasgow:
The Design Society.
Giffin M, De Weck O, Bounova G, et al. (2009) Change propagation analysis in complex technical systems. Journal of
Mechanical Design 131: 081001.
Hamraz B, Caldwell NHM and Clarkson PJ (2012) A multidomain engineering change propagation model to support
uncertainty reduction and risk management in design.
Journal of Mechanical Design 134(10): 100905.
Hamraz B, Hisarciklilar O, Rahmani K, et al. (2013) Change
prediction using interface data. Concurrent Engineering:
Research and Applications 21(2): 141–154.
Harker SDP, Eason KD and Dobson JE (1993) The change
and evolution of requirements as a challenge to the
practice of software engineering. In: IEEE international
symposium on requirements engineering, San Diego, CA,
USA, 4–6 January 1993, pp. 266–272. IEEE.
Hollins B and Pugh S (1990) Successful Product Design. London: Butterworths.
Huang GQ and Mak KL (1998) Computer aids for engineering change control. Journal of Materials Processing Technology 76(1–3): 187–191.
Huang GQ and Mak KL (1999) Current practices of engineering change management in UK manufacturing industries.
International Journal of Operations & Production Management 19(1): 21–37.
Concurrent Engineering: Research and Applications 00(0)
Huang GQ, Yee WY and Mak KL (2003) Current practice of
engineering change management in Hong Kong manufacturing industries. Journal of Materials Processing Technology 139(1–3): 481–487.
Hull E, Jackson K and Dick J (2005) Requirements Engineering. London: Springer.
INCOSE (2010) Systems Engineering Handbook: A Guide for
System Life Cycle Processes and Activities (INCOSE-TP2003-002–03.2). John Wiley & Sons Inc.
Inness J (1994) Achieving Successful Product Change. London:
Financial Times/Pitman Publishing.
Jarratt TAW, Clarkson PJ and Eckert CM (2004) Engineering
change. In: Clarkson PJ and Eckert CM (eds) Design Process Improvement: A Review of Current Practice. London:
Springer, pp. 262–285.
Jarratt TAW, Eckert CM, Caldwell NHM, et al. (2011) Engineering change: an overview and perspective on the literature. Research in Engineering Design 22(2): 103–124.
Kang C and Hong YS (2009) Evaluation of acceleration effect
of dynamic sequencing of design process in a multiproject
environment. Journal of Mechanical Design 131(2): 021008
(11 pp.).
Keller R, Eckert CM and Clarkson PJ (2009) Using an engineering change methodology to support conceptual design.
Journal of Engineering Design 20(6): 571–587.
Kidd MW and Thompson G (2000) Engineering design
change management. Integrated Manufacturing Systems
11(1): 74–77.
Lam W and Shankararaman V (1999) Requirements change:
a dissection of management issues. In: 25th EUROMICRO
conference: informatics: theory and practice for the new millennium, Milan, 8–10 September, pp. 244–251. New York:
IEEE.
Lee HJ, Ahn HJ, Kim JW, et al. (2006) Capturing and reusing knowledge in engineering change management: a case
of automobile development. Information Systems Frontiers
8(5): 375–394.
Li W and Moon YB (2012) Modeling and managing engineering changes in a complex product development process. The International Journal of Advanced Manufacturing
Technology 63(9): 863–874.
Li YL and Zhao W (2014) An integrated change propagation
scheduling approach for product design. Concurrent Engineering: Research and Applications 22(4): 347–360.
Lindermann U and Reichwald R (1998) Integriertes Anderungsmanamement. Berlin, Heidelberg: Springer.
Love PED (2002) Influence of project type and costs in building procurement method on rework construction projects.
Journal of Construction Engineering and Management:
ASCE 128(1): 18–29.
Maier JF, Wynn DC, Biedermann W, et al. (2014) Simulating
progressive iteration, rework and change propagation to
prioritise design tasks. Research in Engineering Design
25(4): 283–307.
Masmoudi M, Leclaire P, Zolghadri M, et al. (2017) Change
propagation prediction: a formal model for twodimensional geometrical models of products. Concurrent
Engineering: Research and Applications 25(2): 174–189.
Ullah et al.
Maull R, Hughes D and Bennett J (1992) Special feature. The
role of the bill-of-materials as a CAD/CAPM interface
and the key importance of engineering change control.
Computing & Control Engineering Journal 3(2): 63–70.
Mohringer S (2006) From design errors to chances—a
computer-based error tracking system in practice. In:
International design conference, Dubrovnik, 15–18 May,
pp. 943–950. Bristol: The Design Society.
Morkos B and Summers JD (2010) Requirement change propagation prediction approach: results from an industry
case study. In: ASME international design engineering technical conferences, Montreal, QC, Canada, 15–18 August,
pp. 111–121. New York: ASME.
Nadia B, Gregory G and Vince T (2006) Engineering change
request management in a new product development process. European Journal of Innovation Management 9(1):
5–19.
Nuseibeh B and Easterbrook S (2000) Requirements engineering: a roadmap. In: Conference on the future of software
engineering, Limerick, 4–11 June, pp. 35–46. New York:
ACM.
Ollinger GA and Stahovich TF (2001) RedesignIT – a
constraint-based tool for managing design changes. In:
ASME design engineering technical conferences, Pittsburgh,
PA, 9–12 September, pp. 197–207. New York: ASME.
Pahl G and Beitz W (1998) Engineering Design: A Systematic
Approach. London: Springer.
Palmer G, Morkos B and Summers JD (2010) Investigation
of design tools as complexity management techniques. In:
ASME international design engineering technical conferences, Montreal, QC, Canada, 15–18 August, pp. 511–522.
New York: ASME.
Pasqual MC and De Weck OL (2012) Multilayer network
model for analysis and management of change propagation. Research in Engineering Design 23(4): 305–328.
Pikosz P and Malmqvist J (1998) A comparative study of
engineering change management in three Swedish companies. In: ASME design engineering technical conference
(DETC98), Atlanta, GA, 13–16 September, pp. 1–11.
New York: ASME.
Reidelbach PE (1991) Engineering change management for
long-lead-time production. Production and Inventory Management 32(2): 84–89.
Shankar P, Morkos B and Summers JD (2012) Reasons for
change propagation: a case study in an automotive OEM.
Research in Engineering Design 23(4): 291–303.
Shapiro D, Hamraz B, Sommer AF, et al. (2015) Investigating
the impact of changes in iteration-likelihoods on design
process performance. Concurrent Engineering: Research
and Applications 23: 250–264.
15
Sugden RC and Strens MR (1996) Strategies, tactics and
methods for handling change. In: IEEE symposium and
workshop on engineering of computer based systems, Friedrichshafen, 11–15 March, p. 457. New York: IEEE Computer Society.
Tang D-B, Yin L-L, Wang Q, et al. (2016) Workload-based
change propagation analysis in engineering design. Concurrent Engineering: Research and Applications 24(1): 17–34.
Terwiesch C and Loch CH (1999) Managing the process of
engineering change orders: the case of the climate control
system in automobile development. Journal of Product
Innovation Management 16(2): 160–172.
The Standish Group (1995) The Standish group report. Chaos
1: 8.
Ullman D (2003) The Mechanical Design Process. New York:
McGraw-Hill Education.
Ulrich KT and Eppinger SD (1995) Product Design and Development. New York: McGraw-Hill Education.
Van Bossuyt DL, Dong A, Tumer IY, et al. (2013) On measuring engineering risk attitudes. Journal of Mechanical
Design 135(12): 1–13.
Vianello G and Ahmed-Kristensen S (2012) A comparative
study of changes across the lifecycle of complex products
in a variant and a customised industry. Journal of Engineering Design 23(2): 99–117.
Wasmer A, Staub G and Vroom RW (2011) An industry
approach to shared, cross-organisational engineering
change handling–the road towards standards for product
data processing. Computer-Aided Design 43(5): 533–545.
Watts F (1984) Engineering changes: a case study. Production
and Inventory Management 2(4): 55–62.
Worinkeng E and Summers JD (2014) Analysing requirement
type influence on concept quality and quantity during
ideation: an experimental study. In: ASME international
design engineering technical conferences, Buffalo, NY, 17–
20 August.
Wright IC (1997) A review of research into engineering
change management: implications for product design.
Design Studies 18(1): 33–42.
Yu X, Yang Z, Wang G, et al (2013) Study on design change
review for small and medium-sized enterprises. In: 2013
IEEE international conference on industrial engineering and
engineering management, Bangkok, Thailand, 10–13
December, pp. 556–560. New York: IEEE.
Zhang J, Song X, Chen H, et al. (2015) Optimisation of critical chain sequencing based on activities’ information flow
interactions. International Journal of Production Research
53(20): 6231–6241.
16
Concurrent Engineering: Research and Applications 00(0)
Appendix 1
Notation
kn
number of change steps as a result of nth change request
K
m
total number of change steps in a single CPP
number of product0 s components
n
Pl RR(r, ci )
number of change requirements
planned rework risk from change request 0 r0 to instigating component 0 ci 0
Pr RR(ck2 , ck1 )
propagated rework risk between any two successive components
RIij
RPij
rework impact between component 0 i0 and 0 j0
rework probability between component 0 i0 and 0 j0
RR(ci , cj )
rework risk between component 0 i0 and 0 j0
RRKr1 r2 rn (ci , cj )
rework risk propagated from component 0 i0 to 0 j0 as a result of 0 n0 change requests in 0 K 0 steps
TRD
x
total redesign duration of propagated path
number of iterations
y
number of changes caused by change requests
Author biographies
Inayat Ullah is a Ph.D. candidate at Nanjing University of Aeronautics and Astronautics,
Nanjing, China. He received his Master degree in industrial and manufacturing engineering from
University of Engineering and Technology Taxila, Pakistan in June 2010. His research is mainly
focused on Engineering Design, Engineering Change Propagation, Design Change analysis and
optimization.
Prof. Dr. Dunbing Tang earned his Ph.D. from Nanjing University of Science and Technology
(NUST). During 2002-2005, he conducted the scientific research at Aachen University (Germany)
and Cranfield University (UK). He joined Nanjing University of Aeronautics and Astronautics at
the end of 2005. Prof. Tang’s research interests include Intelligent Manufacturing System and
Automation, Product Design Theory and Methodology.
Qi Wang is currently a Ph.D. candidate at the College of Mechanical and Electrical Engineering,
Nanjing University of Aeronautics and Astronautics, China. His research interests include Product
Design Theory and Methodology.
Leilei Yin is currently a Ph.D. candidate at the College of Mechanical and Electrical Engineering,
Nanjing University of Aeronautics and Astronautics, China. His research interests include Product
Design Theory and Methodology, Design Change analysis and optimization.
Ishfaq Hussain is currently pursuing the M.S. degree (Communication and Information System) at
Nanjing University of Aeronautics and Astronautics, Nanjing, China. His research interests include
programming, algorithm development, computational electromagnetics, and communication
systems.
Документ
Категория
Без категории
Просмотров
4
Размер файла
2 625 Кб
Теги
1063293x17735359
1/--страниц
Пожаловаться на содержимое документа