If you are designing the best setup for your Software Change Management system (specifically TURNOVER V100 for iSeries) these notes might help.
We have four main user groups:
- Software Solution Analysts
- Change Administrators
- Development Team
- QA/UAT Team
We need to clean the IBM I authorities so they correctly let these group members *USE , *CHANGE or *ADMIN different parts of the machines. Remove *ALLOBJ or *SECOFR from all developers on all machines. Correctly create group profiles for these roles and have the members part of those groups.
Within Turnover we have these functional areas:
- Systems – which IBM-I systems are where and wether they are DEV, TST, QA, UAT or PROD
- Applications – which applications (duh!) or libraries/programs are on which machine
- Projects – the work being planned, actively worked on or completed
- Tasks – subsets of projects that have been assigned to developers
- Programmer worklist – list of things being worked on as part of a project tasks
- Forms – code promotions as part of programmer worklists
We need to correctly define the TURNOVER definitions for these groups something like this:
Change Administrator – these are the *SECOFR of the turnover world. A rare beast and something the developers should never have access to. Can create/delete everything.
Development Team – these need rights to *USE Projects, *CHANGE tasks and create/run DEV/TST/QA forms
Software Solution Analysts – *USE rights to investigate and look at everything. Possibly rights to create/assign tasks to developers? No rights to create distribution forms or change code.
QA Team – only have rights to read data files and perhaps look at object history. It’s likely that SANDS QA users will not use turnover.
The programmers that are defined to Turnover should be setup so that they can only see the applications that they are working on.