AyMINE – Technical documentation
Modules
Task, project & quality management
Manager approval with the task report
Why some data can't be deleted
Adminitration of areas, projects, calendars
Region / project / methodology
Change management process in a project
GDPR and record of qualifications
Qualification of user or contact
Right to Manage Qualifications
Task, project & quality management
Administration of the Task Management Module
System rights for the task management module
Methodology and Quality Management systems
What a methodology / QMS consists of
Collaborative Resolution of Multiple Problems
Customer Service Response Generation
Incident and Quality Issue Management
Objects affected by the problem
Problems, Incidents, Helpdesk Tickets
Return project plan by baseline
Sample tasks and methodologies of the area
Effect of the task on the right to modify the attached object
The person responsible for the task
Working procedure – task definition
Objects related to the task pattern
Contacts and directories module (CRM)
Order overview for customer groups
Contacts and directories module (CRM)
System Permissions and CRM Module Settings
Send bulk messages in compliance with GDPR
How to correctly forget a person's details
Unsubscribe and set preferences
for bulk mail
Web management and automation
Receiving a message from the web
Human resources
Personalistics – User Permissions
Human Resources module security
Manage department / division data
Overview of Personnel Information for pracov# Employment Contract
Synchronizing staff and system users
Products, assets and sales
Received order for goods or services
Finance management
Metrics and Measurements
Technical Modules
Sabre plugin module
Enterprise Architect connector
Database link to Enterprise Architect database
Enterprise Architect connector
System Modules
The AyMINE Framework Module
AyMINE — Tips for Mobile Usage
Configure how your system looks and works
Gestures and Keyboard Shortcuts
More about how the system works
Private notes and tags for objects
Overview of Modules and Record Types
Filtering in the list of records
System Management
Securing posts and internal discussions
Additional functions with files
Copying and moving files between objects
Files (documents) linked to the object
Formatted texts in the application
Gateway settings for external messages
IMP gateway settings for email communication
Internet Call Gateway Settings
Configuration Package
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.)
Open package
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.
Notes
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.