You have to deploy a "security plan" like this:
GROUPS:
ADMIN_PERMISSIONS: group with ALL the permissions checked
USER_PERMISSIONS: group with ALL the permissions checked except those related to "Security - ...", "Manage locks", "Administer Database"...
ANALYSTS: group with no permissions (used only for establish locks)
DEVELOPERS: group with no permissions (used only for establish locks)
TESTERS: group with no permissions (used only for establish locks)
USERS:
Tom --> assigned to groups: ADMIN_PERMISSIONS, ANALYSTS, DEVELOPERS and TESTERS.
Peter --> assigned to groups: USER_PERMISSIONS, ANALYSTS.
Marge --> assigned to groups: USER_PERMISSIONS, DEVELOPERS
Ian --> assigned to groups: USER_PERMISSIONS, TESTERS.
Each user, inherits the functional permissions by pertenence to ADMIN_PERMISSIONS or USER_PERMISSIONS group. Peter, Marge and Ian can't establish lock to packages or assign permissions to himself.
LOCKS:
Tom (the administrator) is the responsable of set the locks to the packages: Logical views, are locked for ANALYSTS group, Design classes packages, are locked for DEVELOPERS group. Test Cases packages are locked for TESTERS group.
Now, Peter only can do WHAT USER_PERMISSIONS say WHERE the locks allows (Peter only can work in Logical views packages).
Marge only can work in Design class packages, with the same permissions than Peter.
Ian only can work in Test Cases packages, with the same permissions than Peter and Marge.
This is only an example of how permissions groups, users and locks can be managed. Other possible ways is to lock a entire project for a group (as ANALYSTS, DEVELOPERS groups... but with PROJECT 1, PROJECT 2 names)
Ufff!!! sorry for my spanglish