Important note: there is no such a thing as ETVDX model in software industry. I checked three books on project management, Wikipedia and Google, and none have relevant references about ETVDX. Thus, the following is just pure speculation without solid references. If you want to have a definitive answer, ask your lecturer.

Having said that and considering the context of your recent questions, I would suppose that ETVDX is about the tasks which can be considered autonomous and evaluated in terms of time and cost, i.e. level four of the Work Breakdown Structure (WBS). Putting those tasks at level four, and not level five, enables to attribute the task itself to one person or team, while the quality verification will be done by another one.

Once one finishes the WBS, separate work packages can be assigned to different people, given that those work packages are combined into tasks. ETVDX are the different aspects of every task.

Let’s take an example of a product of an e-commerce website which also has a desktop client. A sample task T_n would consist of creating the part of the desktop application which enables the user to search for the products.

• Entry would represent tasks required to be done in order to start T_n. This will include:

  • The task T₁ of defining the interface of the web service which allows the desktop application to retrieve products,

  • The task T₂ of defining the framework of the desktop application,

  • The task T₃ of creating the component which displays a list of products in desktop application.

  In other words, E(T_n) = {T₁, T₂, T₃ }.

• Task will be the task itself, i.e. the management required to do the search part, the unit testing, the coding and the documentation. This is what is actually done by a developer of a team of developers who are assigned to T_n. The work of this developer or this team will be based on both the requirements, the overall architecture of the project and the interfaces with the dependencies like T₁.

• Verification would be what QA department does: checking that:

  • The component works without crashing every two minutes.

    The component may match the requirements, but if it makes the application crash, it wouldn’t be very useful nor appreciated by the end users.

  • The component matches exactly the original requirements.

    If those requirements describe that the border of the search bar is blue, and the actual border is gray, it wouldn’t make the end users scream and throw away the application, but would still be a gap between what requirements ask and what is actually done.

• Delivery represents the moment when T_n is fully tested by QA department and can be delivered to the customer. It belongs then to the customer to confirm that this part of the product matches exactly the business needs originally expressed in SOW and translated into technical terms inside the WBS.

  There are two possibilities:

  • Either the customer confirms that what was done in T_n is exactly what was originally asked. This results in moving the task to the Exit step.

  • Or the customer points out a gap between the original needs and the final result. This gap may result from a misunderstanding, a misinterpretation of the business needs, the fact that the requirements weren’t detailed enough, that it wasn’t originally possible to predict a certain case, etc.

• Exit would represent the moment when T_n is considered finished, confirmed by the stakeholders and ready for production. It doesn’t mean that the product itself can be released, but only that the task is tested, considered conform to the requirements, and ready to be used by other tasks which rely on T_n.

  In the same way, Entry step would have ensured that T₁, T₂ and T₃ were exited before starting T_n itself.

  For example, starting T_n while T₁ is still pending would increase the risk of going out of schedule. Imagine that the developers’ team actually finished the task T_n, and QA department was currently testing this task, when T₁ was invalidated by the customer: it appeared that the interface of the web service was based on requirements which were wrongly interpreted by the company, and the customer insist on changing the interface. Not only T₁ would change, but T_n would require to change as well.

For me, ETVDX is not the same as the Waterfall model. In Waterfall, chronologically, one:

1. Gathers the requirements,

2. Does the architecture and design,

3. Implements the product, ← ETVDX is here

4. Verifies it,

5. And maintains it.

ETVDX would be involved repeatedly during the implementation phase of the Waterfall model. ETVDX expects WBS and Gantt Chart to be done, and is based on them. It is also what enables the project to flow according to the Network Analysis (and Gantt Chart): for example if the precedence diagram shows that T_n relies upon T₁, T₂ and T₃, while T_A and T_B rely upon T_n, then you know that:

• The Entry of T_n would follow the Exit of T₁, T₂ and T₃,

• The Entries of both T_A and T_B would follow the Exit of T_n.

Note: if Agile methods are used, Waterfall flow will coincide with the task itself. In this case, ETVDX corresponds, chronologically, to the Requirements → Verification step, i.e. the whole Waterfall flow. Both would still signify different things as they are about different aspects of project management.