Review Process with type of checklist as a workitem workflow transition

Description
sk-tsb
Posts: 28
Joined: Tue Jul 17, 2018 8:23 am

Review Process with type of checklist as a workitem workflow transition

Postby sk-tsb » Wed Feb 03, 2021 1:24 pm

Hello ,

my customer asks for a way how to execute a Review with a attached checklist in a usual workitem workflow or even in a liveDoc workflow. The workitem specific checklist has got all the points to check and a field as text or checkbox exists to write the result of each point in this checklist. Does anybody have experience with that ?
The goal is to achieve a well documented review process.

Workitem in this case can be type of requirement or implementation of sw, hw or even mechanics

If this does not fit into a workflow process are there any well known alternatives ?

Cheers Sven

Jürgen
Posts: 115
Joined: Tue Sep 12, 2017 1:02 pm

Re: Review Process with type of checklist as a workitem workflow transition

Postby Jürgen » Fri Feb 05, 2021 11:16 am

Hi, Sven

At the moment it sounds like "exaggerating a well documentation" to me. The regular approval process in Polarion is already "well-documented", as the reviewer must approve every single item and sign afterwards.

So my first question would be, if the process itself shall be well-documented (so the checklist would contain points like "reviewer has seen the item", "reviewer approves the item"), or if the checklist shall contain all checks for the content of a work item (like "wording is ok", "requirement is linked to design", "requirement does not contain words like 'approximately' ").

No matter which of them, having a checklist in each single work item would make a review process extremely slow, because for every work item the reviewer would have to fill out the checklist. This I would see as too much under normal circumstances. Having a checklist is basically ok, but I would only have it as "hint" for the reviewer, or maybe fill it out for a complete document, but not for each work item.

But if it is really needed to have a checklist for each work item, then I would probably do that by creating a custom field in the work item, that contains the initial checklist and must be filled during review. Using the state field with different transitions in the work item, one could reset the review field before a review, so that when the work item is in state "reviewed", the list is filled out, and in a state "ready for review", the list is initialized.

Of course there are other possibilities, like real attachments, or a linked "review-list" work item, but that would make it even more time-consuming to fill it out.

Regards
Jürgen

sk-tsb
Posts: 28
Joined: Tue Jul 17, 2018 8:23 am

Re: Review Process with type of checklist as a workitem workflow transition

Postby sk-tsb » Sat Feb 06, 2021 10:39 am

Hello Jürgen,

thanks for your information and suggestion.

In this case the used case is a Software Review. Each Reqirement has to get a "task" work item where a developer is instructed to do some programming. When the developer says the task has been done a second devloper has to do a corresponding software review. The customer has got a long internal code style guide and other rules which have to be fulfilled. These rules cannot checked by PC-Lint or QAC or other tools (naming conventions...) . To ensure that each software implementation task fulfills all these mentioned rules there should be a list where the reviewer can check. Otherwiese the probability that the reviewer forgets some rules to check is quite high. In the meanwhile i thought about to use something like a test case ? The test steps are all the rules and regulations . And the reviewer could say OK/NOK to each reviewed rule (test step) of the list. What do you think about this solution ?

Of yourse to use a custom specific Rich Text field could also be a solution. Thanks for this so far.


Regards Sven

Jürgen
Posts: 115
Joined: Tue Sep 12, 2017 1:02 pm

Re: Review Process with type of checklist as a workitem workflow transition

Postby Jürgen » Sun Feb 07, 2021 3:49 pm

Hi, Sven

some additional thoughts

- There are tools that also can check style guide, e.g. https://www.jetbrains.com/help/resharper/Coding_Assistance__Naming_Style.html. It works at least for C++ and C#
- Having a checklist is basically ok, but I would not request the reviewer to fill out >50 lines by checking each single one of them. Maybe group-wise..., but ok.
- Doing it with a test case would definitely work, at least regarding the content. But there is some overhead involved with it.
-- I assume for filling out the test case you would need to execute it, so you would need a test run. And the reviewer would need tester rights.
-- If you are using test cases also for their real purpose (testing :-) ) you will end up with a mixture of test cases for different goals.
-- If the test case fails, do you want to create a defect? And when the failures are fixed, you want to repeat the test execution, i.e. filling out all the fields again?
-- where shall the documentation be stored? In Polarion? If it shall be stored in another system, you will need to export it, which might become difficult with test reports.
-- Are the test cases then linked to the implementation task or to the requirement?
-- Is it assured that there will always be 1:1 between RQ and Implementation task? Often this tends to become 1:n.

Maybe it would be a good idea to model the whole workflow, at least on paper, to find possible traps.

Regards
Jürgen

sk-tsb
Posts: 28
Joined: Tue Jul 17, 2018 8:23 am

Re: Review Process with type of checklist as a workitem workflow transition

Postby sk-tsb » Wed Feb 10, 2021 6:38 pm

Hello Jürgen,

thanks for the long, detailed answer,

- I will try to solve the demands from the customer only with polarion. To have a lot of other tools which have be "special" configured and tested make problems. This is my experience in the past.

-> In one of my last projects the customer used Jira, Confluence, Doors and PTC Integrity. Fortunately i was not the Admin :D . The project overall data integrity and traceability was a disaster. Checking and ensuring integrity and traceability created a lot of work (hundreds of hours ) that was unnecessary.[/i][

- In the meantime, the customer has suggested using its own "Checklist" work item. At this time i am not quite sure wether this is a good solution, what do you think ( Jürgen and the Polarion Community )

- The solution with the Test Steps , i will suggest in the next few days. But Jürgen you are very right that this involves other mechanisms which have to be think about. To have more QA or ALM licences is also a big disadvantage of this solution.

- Due to the question of automatic generation of errors if sub-goals of the review are not achieved, I will soon follow up with the customer

- The result has to be stored in Polarion. As i mentioned above, i will try to have all Activities and Results within Polarion. Only really unsolvable demands should then include additional tools if necessary.

- The review shall be "applied" for all kinds of Work Items ( Requirements, Design, Software-Implementation, Hardware-Implementation .... ) Hence we need quite a lot of different Review - Lists.

- The normal way , which i expect is that one requirement will create multiple tasks.

- Yes, the customer and I want to prepare this well so that it can be used as effectively as possible. It will therefore not be a snapshot.

Cheers Sven

Jürgen
Posts: 115
Joined: Tue Sep 12, 2017 1:02 pm

Re: Review Process with type of checklist as a workitem workflow transition

Postby Jürgen » Sun Feb 14, 2021 4:58 pm

Hi, Sven

hmm...yes .. "a fool with a tool is still a fool"....

The question, if tool integrations work well, is directly connected to the knowledge of the tools and the corresponding workflows. If implemented in a bad way, it can get a nightmare. On the other hand: if done right it has a lot of benefits.

With a tool like Resharper (or PClint... whatever) it is a little different though: When you use a tool that enforces specific coding rules, the main benefit is that you do not need to worry any more about reviewing and therefore tracing. They simply fall out of the list. Those tools do not need to be "integrated" with anything else. It is just necessary to document the functionality once somewhere, afterwards it may be forgotten (from tracing perspective).

However: If Polarion is the one and only tool to be used, then using a specific work item type is a usable solution, I think. It has several benefits compared to a test case, which we already mentioned earlier. It has a history, so the process of doing a review more than once could be covered. It also can be adapted over time. You can create a default content with a table that only needs to be completed during review. You can even give it a state like in Jira to put a process to it.

The drawback is that you end up with a LOT of work items which look all the same. You should think about some unique title, even if it is generated. And you should use a dedicated link role only used by that type, not using a role like "relates_to" but rather something like "reviewed_by". Maybe even a field that contains the type of the reviewed document, to be able to filter for them easily; or a different type of review work item depending on the review item, so that the default content can be applied easier.

When you create multiple implementation tasks for one e.g. requirement (1:n) you will also need several review items for one requirement, logically one for each task.

When I think this through, I recognize that by doing everything in Polarion, you risk ending up with re-implementing Jira functionality in Polarion. I just thought about using Polarion's "planning" functionality for this, but I never used it so I have no experience.

That's all I can say at the moment.
Jürgen

sk-tsb
Posts: 28
Joined: Tue Jul 17, 2018 8:23 am

Re: Review Process with type of checklist as a workitem workflow transition

Postby sk-tsb » Thu Feb 18, 2021 7:15 pm

Hi Jürgen,

thanks for all the thoughts, hints and tips.

My current concept is :

- We use Workitem type "Implementation" that covers (linking) the realization of 1..n requirements ( Traceability : Are all requirements implemented )
-> Implementation workitem has Custom Specific Field which defines Implementation Type ( Software Implementation, Schematic Design, PCB unbundling....... )

- We also use Workitem type "Review".
- Each "Review" workitem has to add an attachment which is a specific form ( System Requirement Engineering, Detailed Requirements [ Software / Hardware / Mechanics / Documentation ], Softwareimplementation, Schematic Design, PCB unbundling ). This attaching has to be done by the reviewer. The form is stored in a company form library.
- The attachment has to be filled out by the reviewer ( Attachment is a Word-Dokument / PDF-Dokument for example )
- "Review" workitem got a custom field which says successful ,failed or blocked

- We use workitem "Task" which describe litte portions of work to do ( Task has got custom specific type and subtype , for example : type :Software , subtype:change )

- The workitems "Implementation", plus all types of Requirements, TestCases and so on do all have a linked "Review" with its own Review-Specific Link-Type

- If the Review is "failed" the Reviewer-Person has to create and add one ore more tasks to the "Review" that describe what "little" changes have to do to get a successfull Review. ( Implementation Workitem status is NOT changed )

- After realization of 1..n Tasks the "Review" Workitem gets a second attachment which hopefully has all points within the attachment fulfilled. ( + update of status )

- So the deepest Review Link-Chain for a implementation is :

Requirement WI->Implementation WI ->Review WI ->Task [b]WI[/b]

- The deepest Review Link-Chain for a Requirement is :

Requirement WI->Review WI->Task [b]WI[/b]

Whereas the red Workitem Tasks only occur when there was a finding in the first "review"

As you said the WI Review has got the history of the review and the attachments have the details.

Is there something i missed ? Is this concept manageable ?


Regards Sven

Jürgen
Posts: 115
Joined: Tue Sep 12, 2017 1:02 pm

Re: Review Process with type of checklist as a workitem workflow transition

Postby Jürgen » Tue Feb 23, 2021 1:31 pm

Hi, Sven

it is rather difficult to judge this by just reading the "dry" description. I think it can be done. However, difficulties often come up first when the life cycle management happens, so what happens in the future when things are changed (like requirements), when things are deleted, when things are done differently in two variants/versions, and so on.

I didn't think all of that through, but for example: what shall happen to the existing review item, when the requirement is a) changed, and b) deleted somewhere in the future? Shall it still be available? Shall it be deleted, too?

Maybe you want to spent some time to think about those "future" changes to existing items.
That seems the only thing I could add to the idea atm.

Regards
Jürgen

sk-tsb
Posts: 28
Joined: Tue Jul 17, 2018 8:23 am

Re: Review Process with type of checklist as a workitem workflow transition

Postby sk-tsb » Tue Feb 23, 2021 2:20 pm

Hello Jürgen,

you are right.

i will give feedback in the next time once i have som experience with this concept.
If there will be any changes in the concept i also will give feedback.


Regards Sven


Return to “Polarion Application Lifecycle Management (ALM)”

Who is online

Users browsing this forum: No registered users and 18 guests