In a lecture, the lecturer described the following model :
E – entry (the preconditions to a task).
T – task – doing the task
V – verifying the tasks quality
D – Delivering the tasks
X – Exit.
or ETVDX
If anyone is familiar with this ‘generic compliance model’, how does it fit into software development exactly? I presume it’s equivalent to the waterfall model of negotiating requirements > defining/decompose stage > estimating effort > estimating resources > developing schedule.
0
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 Tn 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 Tn. This will include:
-
The task T1 of defining the interface of the web service which allows the desktop application to retrieve products,
-
The task T2 of defining the framework of the desktop application,
-
The task T3 of creating the component which displays a list of products in desktop application.
In other words, E(Tn) = {T1, T2, T3 }.
-
-
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 Tn. 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 T1.
-
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 Tn 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 Tn 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 Tn 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 Tn.
In the same way, Entry step would have ensured that T1, T2 and T3 were exited before starting Tn itself.
For example, starting Tn while T1 is still pending would increase the risk of going out of schedule. Imagine that the developers’ team actually finished the task Tn, and QA department was currently testing this task, when T1 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 T1 would change, but Tn would require to change as well.
For me, ETVDX is not the same as the Waterfall model. In Waterfall, chronologically, one:
-
Gathers the requirements,
-
Does the architecture and design,
-
Implements the product, ← ETVDX is here
-
Verifies it,
-
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 Tn relies upon T1, T2 and T3, while TA and TB rely upon Tn, then you know that:
-
The Entry of Tn would follow the Exit of T1, T2 and T3,
-
The Entries of both TA and TB would follow the Exit of Tn.
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.
1