Packages are used to group information. The act of grouping items under a package defines a scope of work, while the practice of searching the information contained by a package helps users to understand the scope and find what they need.
Within SPF the content of a package is defined by those objects that have a relationship to the package object. This is different from systems where a package name has been specified as an attribute of an object.
The following table lists the basic package types defined for the project in SPF:
|
Package Type
|
Description
|
Hierarchical Structure
|
Other Notes
|
|
Contract Package
|
Defines items pertinent to a contractor (the purchase of a service)
|
Yes
|
Integrates with SMat (refer to item 1.)
|
|
Procurement Package
|
Defines items pertinent to the purchasing of goods
|
Yes
|
Integrates with SMat (refer to item 1.)
|
|
Engineering Work Package
|
Defines items grouped for the act of designing
|
No
|
|
|
Construction Work Package
|
Defines items grouped for the act of building
|
No
|
Integrates with Design Tools (refer to item 2.)
|
|
Commissioning System
|
Defines items grouped for the act of commissioning
|
Yes
|
Integrates with Design Tools and SC (refer to item 2.)
|
|
Scope Work Package
|
Groups items for the purpose of defining a scope of work
|
No
|
|
-
In the case of contract and procurement packages, these objects are built in SPF and related information can be sent to or imported from SMat.
-
In the case of construction work packages and commissioning systems, the objects are instantiated in SPF so that a design tool can assign them to a tag. When the design tool publishes the tag to SPF, a relationship between the package and tag will be automatically created in SPF.