Task, project & quality management
Contacts and directories module (CRM)
Web management and automation
Products, assets and sales
Sabre plugin module
Enterprise Architect connector
The AyMINE Framework Module
An configuration package is a set of objects that together form a complete set of data describing the state of a project.
Configuration bundles are used to store the status of a the project at a specific point in time, typically the end of phase or before the change management start. Configuration management is a process area required all modern project management standards as well as quality and safety management in development and production.
How to use an configuration package
A package has two fundamentally different states: open and locked. (Reopen package returns to the open state but the history of the package records that it was closed and is reopen again.)
Project members can insert objects into an open package or remove them again. Operations are allowed to members of the package contributors group; this can be all people from project or even non-project members but also only selected people responsible for phase or activity related with the configuration bundle.
The package is typically open either for the entire project phase, or a short point at the end when it is being filled. The organization of the fulfilment (whether continuous or one-off) depends on the project methodology and type of the phase. The open and close time is always managed by the bundle manager.
If there is no special reason for long-time open package, it is recommending to have one-time fulfilment at the end of a stage, as it requires less time and has a higher probability of not forgetting to put something important in the package.
Closing and locking the package
After the package manager verifies that everything required is in the package, he/she closes the package – change its state. Closes configuration package locks everything in it for editing.
The system never allows editing object in the locked package with single exception: the object can be marked obsolete in case that a new version from it is created.
Locked archive package
A closed package archives everything that belongs in it, creating an archive. A locked package locks the objects that are stored in it.
If what is stored inside is to be changed, there are basically two possible paths:
- Open the package to unlock its contents, repair the contents, and lock the package again. This operation should be performed if the document is erroneous and needs to be corrected.
- Create a new version from the object, leave the archived version in the package unchanged, and continue working with the new version. This procedure is standard when dealing with versioned documents or objects that typically have a new version with the new project stage.
The contents of a closed package cannot be handled, but can be viewed – it is a closed folder.
The package can be viewed by the people who created the package and by people who are in the reader group. However, the groups can be modified by the project manager.
A single document or an object can be in multiple packages – both configuration and user's defined. Each package that has locked an object creates its own lock – so an object that is in seven locked packages is locked seven times. To modify such an object, all seven locks shall be unlocked. .
For a locked object, people can see what packages has locked it.
Including an object in a package does not change the access rights to the object. People who have the right to insert the object into a package do not have the automatic right to look into the objects. They can see what's in the package, but they can't examine the details – that is, they can't open a detail of the object or access a document.
Configuration packages in projects
Configuration packages are technically very close to the archiving bundles, except that single object is never in more archiving bundles but it is not uncommon to place some object – e.g. a requirement – to more configuration bundles.
Projects running according to methodologies such as ISO 26262, ASPICE, CMMI and others shall always manage configuration management for documents created in project phases. These documents are locked for editing and stored so that they can be opened at any time in the future and linked to the stage. An important significance of the closure is the stabilisation of the content after the completion of the stage for use in the next stage. For a more detailed description, please refer to the project management methodology used.
In a project, the responsibility is determined by the methodology. Some methodologies require a CMB – Configuration Management Board (a special committee that reviews the package closure), the standard responsibility is on the project manager or configuration manager but a special board could be defined if required.