2013
DOI: 10.1007/978-3-642-30817-8_20
|View full text |Cite
|
Sign up to set email alerts
|

Optimizing Overlap between Testing and Design in Engineering Product Development Processes

Abstract: Abstract. To reduce product development time, upstream testing and downstream design processes are often overlapped. Existing studies do not recommend overlapping in situations where test results may have a significant effect on downstream redesign. However, this study identifies that, due to long procurement time and lengthy physical tests, companies may have no choice but to overlap these tasks to meet product delivery deadlines. This research investigates how a case study company manages these overlaps, and… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
2
2
1

Citation Types

0
5
0

Year Published

2018
2018
2023
2023

Publication Types

Select...
3

Relationship

0
3

Authors

Journals

citations
Cited by 3 publications
(5 citation statements)
references
References 7 publications
0
5
0
Order By: Relevance
“…Special attention should be reserved to the choice between physical and virtual prototypes. In fact, this is acknowledged to be an important and not self-evident decision (Tahera et al , 2012), impacting the product design and development outcomes. Someone believes that the role of virtual prototype is that of substituting physical ones (Wang, 2002), maybe considering a different design-build-test cycle, as shown by Ullman (2010), where a higher number of fruitful iterations between “designing” and “testing” (virtually) should be possible.…”
Section: Resultsmentioning
confidence: 99%
See 1 more Smart Citation
“…Special attention should be reserved to the choice between physical and virtual prototypes. In fact, this is acknowledged to be an important and not self-evident decision (Tahera et al , 2012), impacting the product design and development outcomes. Someone believes that the role of virtual prototype is that of substituting physical ones (Wang, 2002), maybe considering a different design-build-test cycle, as shown by Ullman (2010), where a higher number of fruitful iterations between “designing” and “testing” (virtually) should be possible.…”
Section: Resultsmentioning
confidence: 99%
“…Still another point of view is that of Elverum and Welo (2015), who observe that within the context of new product development of automotive parts, physical prototypes provide larger potential for exploration that digital (or virtual) ones. More generally, some pros and cons related to the two different prototyping types have been highlighted in literature (Broek et al , 2000; Camburn et al , 2015; Jensen et al , 2016; Tahera et al , 2012) and some preferred application for virtual ones have been inferred (Chun et al , 2012; Dunlap et al , 2014; Tiainen et al , 2014). It has also been observed that an integrated use of the two mentioned approaches, if correctly used, can certainly bring to non-negligible benefits (Tahera et al , 2010, 2014).…”
Section: Resultsmentioning
confidence: 99%
“…eye tracking for data acquisition. According to Tahera (2014), other virtual testing methods already bring about a reduction in testing costs. Therefore, VR can also be a promising approach in this regard.…”
Section: Discussionmentioning
confidence: 99%
“…Physical prototypes are being pushed back for these cost reasons. (Tahera, 2014) These advantages of common CAT support the assumption of investigating novel processes for their suitability. Virtual Reality (VR) technology can represent a new possibility in this context.…”
Section: Introductionmentioning
confidence: 95%
“…Indeed, multiple works [15][16][17] have identified that designers maintain subjective beliefs about the true state of the system design during the design process. In this regard, verification activities mitigate the epistemic uncertainty on a system design by revealing more information about the true current state of the system design 18 Yet, a majority of the literature on verification activities adopts the aleatory uncertainty approach 2,3,5, [19][20][21][22][23][24][25][26][27][28][29][30][31][32][33][34] The reader is referred to 13,35 for a discussion on these works and the drawbacks of adopting the aleatory uncertainty approach to model systems engineering projects.…”
Section: Introductionmentioning
confidence: 99%