## 4 Discussions and Conclusions  
The proposed model facilitates the fast adoption of different life-cycle approaches to attain high flexibility, fast rework, improved reaction time, and clear deliverables for the customer, involved since the early stages of the design. Differences in scopes between different mediums can and will provide some roadblocks; on the other hand, the APQP backbone or other baseline development canvas is the mitigation platform to achieve the results. The new approach helps delivery, flexibility, and cross-domain convergence for end-user valuation and short lead times, iteratively providing minimum viable deliverables \begin{table}
\begin{tabular}{c c c c c} \hline \hline  & **Concept to** & **Programme Approval** & & & \\  & **Programme Approval** & & **to Prototype** & & **Pilot to Launch** \\ \hline Standard APQP (months) & 3 & 9 & 6 & 3 \\ Proposed model (months) & 4 & 6 & 4 & 3 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Timing comparison between standard APQP timing duration and the proposed model. for feedback, current VDI, ASPICE, or CMMI focused on documentation as a first and a linear approach for all domains with common targets and no deviations. Flexibility, when necessary, for complex headlights with unknown but expected changes along with linear development processes, adds high risks and less opportunity to check the performance or design. The new model is proposing exactly these; one domain can change one point irrespective to another one, which can continue on a parallel track but will cover on APQP target to ensure maturity and quality over expected planning. Data gathering and requisition were based on LED-based headlights with dedicated controller units to cover the volume of features required by the proposed methodologies. Figure 7 reflects the orientation and data for this model proposed. The headlights data development is covering each APQP milestone with planned and actual delivery required to achieve a minimum viable product. Major iterations were denoted with integer values, whereas the small iterations, which had no cross-domain impact, were denoted with fractions. This was performed for each major activity SW (software), El (electronics), MES (mechanical and optical engineering system) on projects that followed VDI methodologies and Agile methodologies (AgM). X denotes the assumed model expected behaviour. The planned total was added to the graph to reflect the deviation from current projects. The error concerning the data shown in Figure 7 depends on indirect factors like market trends (which imposed re-designs due to other similar designs) or light signatures (which were launched on market). The new proposed model can function like a white-box type of development where the OEM will take the lead on the application software and  
Figure 7: Delivery baseline LED-based Headlight development—planned versus actual. will impose different vendors for different parts of the headlamp. Moreover, the work and the segregation will be achieved through the contract agreement and duly covered by roles and responsibility matrix agreement. Expectations, timings, and iterations irrespective of final methods applied, where they are converged to deliver the work products over a quality development methodology with stable milestones and work with asynchronous development methodology on each domain, will drive, based on company maturity and flexibility, to short delivery timelines. Development life-cycle based on VDI methodology forced stakeholders on early agreement on project scope and imposed fixed time delivery and fixed expected results, whereas the agile methodology approach encountered on software activities with flexible project scope from suppliers end until the expected maturity will be achieved. VDI and Agile methodology can be similar if the scale is ignored.