>
> |
Scope is usually used to define the boundaries for a Project, Job, or Task. In other words, you can use scope to define which design objects are allowed to be viewed, edited, deleted, etc. when a designer is working on a specific Task. If you want to exercise precise control, scope will let you do that. For example, you could define a Task to modify the CUSTOMER MAINTENANCE input process and you could specify that only that one specific design object (CUSTOMER MAINTENANCE) is allowed to be changed and that it is not allowed to be deleted. However, on the other extreme, if you, as a project manager, don't want to control access to specific design objects, then you can simply not define a scope for a Task.
When defining the scope for a project, job, or task it is sometimes easier to specify the exceptions. For example, you might define a scope to Exclude all design objects and then, by exception, you might define additional scope records identifying specific design objects to be included. Or, you might take the opposite approach and define a scope to Include all design objects and then, by exception, you might define additional scope records identifying specific design objects to be excluded.
Scope can be defined for Projects, Jobs, and Tasks. Scope can also be defined for Suites, Versions, and Applications. If you define scope for a Suite, then all projects tied to that Suite, its Versons, or its Applications will be constrained by the scope defined for the Suite. If you define scope for a specific Version of a Suite, then all projects tied to that Version or its Applications will be constrained by the scope defined for the Suite and the Version. The scope defined for a Project, Job, or Task cannot broaden the scope defined for the Suite, Version, or Application that the projected is tied to. |
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.