Advertisement
opexxx

ASL®2 - Application Services Library 2 - Glossary (EN)

Sep 28th, 2015
204
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 34.21 KB | None | 0 0
  1. Ad hoc service request : An assignment that is issued over and above previously scheduled activities but falls within the scope of the agreed service.
  2.  
  3. Note: The following are examples of ad-hoc assignments: a request to carry out a production run, to draw up a list, to install a new package, and so forth.
  4. Application documentation : A description of the structure, functionality and design choices of a program.
  5.  
  6. Note : As a supplement to functional and technical design, program documentation is a tool used by programmers to implement modifications.
  7. Acceptance criteria : Previously defined measurable, verifiable requirements to which a product must comply, if it is to be accepted.
  8. Agreements and procedures dossier : A document recording the agreements and procedures covering the interaction between a client and an ICT supplier.
  9. Annual plan : A plan in which projects scheduled for the year ahead are described along with ongoing activities as well as the required people and resources .
  10. Application : The automated part of an information system consisting of application software, application-related data, the storage structures (physical and otherwise) in which this data is embedded, and the relevant documentation.
  11.  
  12. Note: In some publications the term information system is used as another word for application.
  13. Application development : Development of new applications.
  14.  
  15. Note: often used to denote development of a new application but also for Additive maintenance.
  16. Application management : All of the tasks, responsibilities and activities which are required in order to ensure that applications are maintained in such a condition that they continue to satisfy the stipulated requirements and the needs of their owners during the full life span of the business processes that are supported by the applications.
  17. Application management organization strategy : The clusters of processes in which the future is determined for the application management organization.
  18. Application management plan : A document setting out all of the activities, which are required to ensure that proper application management, can be carried out.
  19.  
  20. Note: It contains a description of the relevant organization, roles, responsibilities, the processes and activities that are to be carried out, the resources (methods, technologies and tools) that are to be used, and the requirements for the processes of an application management team. It is part of the quality assurance system.
  21. Application object : Any part which is directly related to or which constitutes part of an application, such as programs, sources, data files, documentation, data definitions, test files and scripts, and so forth.
  22.  
  23. Note: See also: configuration item.
  24. Application owner : An official or department who makes decisions about the functionality, funding and service requirements of a system.
  25. Application portfolio : A collection of applications that are used by an organization.
  26. Application portfolio management : The process that involves the definition of a strategy for all of the applications and the information provisioning which supports a business process.
  27.  
  28. Note: This process addresses the significance and performance of the various applications for a business process, translates the relevant business policy into various objects that are part of the information supply, and uses this as the basis to determine a strategy for the future of the application portfolio.
  29. Application Services Library : A public domain standard for improvement of application management processes consisting of a framework, best practices and a maturity model.
  30. Application strategy : The cluster of processes that focuses on the lifecycle and future development of applications, and which leads to a strategy and defined action for the improvement of an application portfolio.
  31. Approved change proposal : An implicit instruction to carry out one or more approved change proposals at a specified point in time.
  32. Attribute : A feature of an entity type of which the values are tied to individual entities (occurrences).
  33. Availability : The extent to what an application object is able to offer the desired functionality at a given time or for a certain period of time.
  34. Build : See realization
  35. Business information management : The IT management domain by which an organization efficiently plans, collects, organizes, uses, controls, disseminates and disposes of its information, and through which it ensures that the value of that information is identified and exploited to the fullest extent.
  36.  
  37. Business Information Management refers to the activities that organizations perform in order to ensure that they are using information in an appropriate manner and that they are acquiring and using the appropriate information systems.
  38. Calamity or Disaster : An unforeseen or unavoidable disruption of the service which has a major impact (for example, as a result of an earthquake, power failure, flood and so forth).
  39. Call : An incident or call is a question, request (for information, additional services or otherwise), failure report, etc. with respect to an existing application or its operation.
  40.  
  41. See incident.
  42.  
  43. Note: Failure.
  44. Capabilities definition : The process by means of which strategy is defined in order to ensure access to any knowledge and skills required within the organization in the future.
  45. Cause : The immediate cause of an event, which leads to the report of a call to a service desk.
  46. Causer : A body, department or person who is responsible for any failure or defect reported to the service desk.
  47.  
  48. Note: The configuration item that causes the failure is not meant here.
  49. Chain processes : Processes, which actively involve multiple organizations in, partner chains.
  50.  
  51. Note: Examples of partner chains include those involving purchases and sales, concluding contracts, making arrangements, exchanging goods (logistics) and information, collaboration and competition.
  52. Change : The cluster of processes which aim to adjust an application because of changed requirements or (expected or detected) defects.
  53.  
  54. The modification of an information system.
  55. Change management : The process that provides a means to identify, prioritize, initiate, evaluate and adjust the changes which have to be made to the application.
  56. Change package : A collection of application objects, which have been modified and approved for transfer to the production environment. See also change set and shipment.
  57. Change proposal : A proposal to fulfil a Change request, based on an impact analysis.
  58. Change request : A request for new or additional service or functionality of which the impact is to be advised. This is responded to with a Change proposal, which can be approved or rejected.
  59. Change request : A request for new or additional service or functionality of which the impact is to be advised.
  60. Change set : A collection of application objects which may be modified following a release, that is to say those objects which have been more or less assigned to a release or have been earmarked for modification. See also change package and shipment.
  61. Client : Someone who obtains products and services from an (application management) organization.
  62. CMDB : Configuration management database, a tool for recording information about the use of application objects.
  63.  
  64. Note: The aim is to itemize all application objects and configuration settings for which the application management organization is responsible, and to provide accurate information about this in order to assist other application management processes. Amongst other things, records are kept of the application versions which are running and where this occurs.
  65. Complaint : A call made by a client to indicate that he is dissatisfied.
  66.  
  67. See incident.
  68.  
  69. Note: In general, a complaint does not deal with a substantive issue but the manner in which it is dealt with by the relevant IT organization.
  70. Configuration item : An IT component about which information is recorded.
  71.  
  72. Note: A distinction is drawn between components such as hardware, software, procedures, services, documentation and so forth. Application objects are configuration items as well.
  73. Configuration management : The process that involves recording and updating information about the various versions of application objects.
  74. Connecting processes : The cluster of processes which synchronizes and coordinates the other operational process clusters.
  75. Continuity management : The process that is used to take measures in order to ensure the continuity and support of the provisioning of information (by information systems) in the long term.
  76. COTS package : Commercial off-the-shelf application. Preferred term: Standard application.
  77. Custom software : An application or applications tailored specifically to accommodate the functionality required by the relevant client. Compare with software package.
  78. Customer environment strategy : The process used to survey developments affecting the environment of a user organization.
  79. Customer organizations strategy : The process used to survey developments within user organizations.
  80. Customization : Changing the functionality or operation of an application by customizing its settings (instead of modifying the software).
  81. Data : An objective presentation of facts or knowledge with which the characteristics of any real person, object or act can be described.
  82. Data (electronically recorded) : A collection of facts concepts and instructions suitable for processing by a computer.
  83. Data flow : A set of data or processed data, which may result in the provision of information to other processes or organizations.
  84. Data management : The control and structure of corporate information within an organization.
  85. Data model : A model which contains a description of entity types and their relationships.
  86.  
  87. Note: In fact this is the description of an entity-relationship data model, other types of data models are e.g. network and hierarchical data models.
  88. Database : A collection of related data, the consistency and integrity of which is ensured by a database management system.
  89. Database : A collection of related data, the consistency and integrity of which is ensured by a database management system.
  90. Database access analysis : Optimizing accessibility to the data by creating or modifying paths to the database and its indexes.
  91. Database management (optimization and tuning) : All of the activities aimed at ensuring that database and entity sets are accurate, complete and up-to-date, and that they can be used satisfactorily.
  92.  
  93. Note: Database management plays an important role as part of both application and technical infrastructure management.
  94. Database management (optimization and tuning) : All of the activities aimed at ensuring that database and entity sets are accurate, complete and up-to-date, and that they can be used satisfactorily.
  95.  
  96. Note: Database management plays an important role as part of both application and technical infrastructure management.
  97. Denormalization : The merging of entity types within a normalized data model, thereby reducing the number of such entities in it.
  98.  
  99. See also normalization.
  100.  
  101. Note: Denormalization is often used to boost performance.
  102. Design : The process in the course of which (user) specifications are detailed in a functional design recorded so as to ensure that they can be implemented and tested in an unambiguous manner.
  103. Design (product) : A structured description of an application or functionality which is required.
  104.  
  105. Note: Such a description can be of a functional or technical nature.
  106. Domain knowledge : Degree of expertise in a specific area.
  107.  
  108. Note: In general, this refers to the expertise of a user organization but also knowledge of specific applications. Business knowledge is an important field of expertise.
  109. Emergency fallback : All of the procedures and facilities which are activated, if an information system can no longer operate or be maintained and managed in its normal location as a result of a disaster.
  110. End user : A person who performs his/her daily work with the aid of one or more applications.
  111. Entity : A concrete or abstract object which is significant to an organization, and about which information has been recorded.
  112. Entity set : A structured, coherent collection of related data.
  113.  
  114. Note: It is sometimes called data set.
  115. Entity type : A class of entities about which the same type of information is kept.
  116. Escalation : A demand to provide more information or to make decisions in case of insufficient knowledge or powers (functional or hierarchical escalation).
  117. Failure : A failure is a situation in which an application or service acts differently from what it may be expected to do on the basis of the relevant specifications or expectations.
  118. Functional system design : A more detailed elaboration of the specifications (in relation to the users or otherwise) of an information system or changes to it, so as to make it possible to implement them in an unambiguous manner.
  119.  
  120. Note: The results can be described in a document with the same name or in use cases, etc, depending on the system development method used.
  121. Functional system test : See testing (activity).
  122. Functionality : The functionality of an application refers to what the latter is capable of doing.
  123.  
  124. Note: From an information managers point of view: what an application should be able to do.
  125. Help desk : See service desk.
  126. Impact : The implications of an incident or change request for users and/or IT management organizations.
  127. Impact analysis : The process that determines the effect of the proposed changes, which is then used to select the best solution for realizing the change.
  128. Implementation : The process that includes all activities to be carried out to make the change requests (from change management) effective in operations and data processing.
  129. Incident : An incident or call is a question, request (for information, additional services or otherwise), failure report, etc. with respect to an existing application or its operation.
  130.  
  131. Note: A failure is a situation in which an application or service acts differently from what it may be expected to do on the basis of the relevant specifications or expectations.
  132. Information : Any significance that a person accords to data (or a data set) or derives from it.
  133. Information management : See Business information management (synonym)
  134. Information provisioning : Information provisioning: (1) the information that is made available to (a part of) an organization, and (2) the people, procedures, data, data carriers, software and hardware that produce this information.
  135.  
  136. Note 1: An organization's information provisioning usually consists of several information systems that each fulfil part of the information demand.
  137.  
  138. Note 2: Data carriers are either digital or analogue (e.g. paper).
  139.  
  140. Note 3: In addition to the user data needed to produce the required information for the user organization, 'data' also includes artefacts such as information policy, requirements, designs etc. that are needed to support the information provisioning activities.
  141. Information request : A call which can be dealt with merely by responding to it, and which does not result in the immediate modification of an infrastructure or application.
  142.  
  143. Note: In some cases repeated requests concerning a specific matter may lead to action and or proposals for change in order to improve an existing information system.
  144. Information system : Information system: the people, procedures, data, data carriers, software and hardware that produce information to accomplish goals of (part of) an organization.
  145.  
  146. Note 1: An information system may be automated or non-automated or a combination of both.
  147.  
  148. Note 2: An information system often supports one business process or a part of it.
  149.  
  150. Note 3: Another more limited definition is often used in practice: the application software and digital data carriers and data sets used by an organization for carrying out or supporting information processing procedures. BiSL usually uses the limited sense of the term.
  151.  
  152. Note 4: An information system is part of the information provisioning for one or more organizations.
  153. Information system development : Creation of a new information system, including initial development of applications
  154. Information system management : Verb: to manage (an information system / application / infrastructure)
  155. Infrastructure : See technical infrastructure
  156. Infrastructure management : An IT management domain which seeks to ensure the ongoing operationalization of an information system, consisting of hardware, an operating system, system software and databases.
  157. Initial development : The initial development of an application.
  158.  
  159. Note: New development can also replace an existing application, for example, if its economic and technical useful life has expired.
  160. Integration test : See testing (activity)
  161. IT developments strategy : The process which monitors and reviews new developments in technology and in which the ICT developments are being identified that may be relevant to the user organization and its information provisioning.
  162. IT infrastructure : All technical components, system and application software, procedures and documentation that are being used to make information available to the users. See also technical infrastructure
  163. Logical system design : See functional system design
  164. Maintenance : The modification of an information system aimed at eliminating failures and adding wanted functionality.
  165.  
  166. Note: In general terms, maintenance can be broken down into:
  167. - Unscheduled maintenance: The modification of an information system as a response to an unforeseen and unscheduled event.
  168. - Scheduled maintenance: The modification of an information system based on arrangements made in advance.
  169. Maintenance, Adaptive : The modification of one or more components of an information system as a result of required changes. It can be triggered by maintenance performed on another component (usually within a subordinate layer) of the information system, a change made to an information system which is connected through an interface, or as a result of a change in the legislation or rules concerning the business function which is supported.
  170. Maintenance, Adaptive : The modification of one or more components of an information system as a result of required changes. It can be triggered by maintenance performed on another component (usually within a subordinate layer) of the information system, a change made to an information system which is connected through an interface, or as a result of a change in the legislation or rules concerning the business function which is supported.
  171. Maintenance, Additive : Enhancement of the functionality of an information system.
  172. Maintenance, Additive : Enhancement of the functionality of an information system.
  173. Maintenance, Corrective : See maintenance
  174. Maintenance, Corrective : The repair of any defective components in an information system. In the case of corrective maintenance the use and operation of the information remain unchanged.
  175. Maintenance, Perfective : The modification of a component of an information system to accommodate changes in users' quality requirements.
  176. Maintenance, Preventive : The correction of a component of an information system in the absence of any reason in the form of a problem report. Its aim is to (a) avoid future problems, or (b) facilitate maintainability.
  177. Management processes : The cluster of processes which is responsible for the comprehensive management time-based management of capacity, costs, quality and what has been agreed (such as service levels).
  178. Mean time between failures : The average time an application runs without defects (mean time between repair and failure).
  179. Mean time to repair : The average time required solving a failure (mean time between failure and repair).
  180. Normalization : A technique used to eliminate redundancy in a data model.
  181.  
  182. Note: The functional interdependence of attributes is the basis for normalization. In the course of normalization attributes are regrouped in such a way that functional interdependence only remains within entity types.
  183. Office automation : The hardware and software, which ensures that general everyday administrative office tasks can be performed.
  184.  
  185. Note: These office tasks often serve to support business processes (primary or otherwise).
  186. Operating system : All of the software which ensures the management of and access to hardware and basic functionality in relation to networks, communications, middleware, transaction monitoring and databases.
  187. Operation : The cluster of processes that ensures that the applications are operated and used in the best possible way to support the business processes, using a minimum of resources and causing the least disruption in the organization.
  188.  
  189. Verb: to support and manage (an information system etc.)
  190. Operational processes : The clusters of processes which describe which everyday activities occur within the application management domain and the relationships which exist between them.
  191. Operational processes : Collective name for the Clusters: Application support, Application maintenance and renewal, and the Connecting processes
  192. Outsourcing : The transfer of business processes and the relevant resources and staff to a supplier and the receipt of these processes as services provided by this supplier in an output based contract.
  193. Package : See software package.
  194. Patch : Modification of a program which solves defects (reactive and proactive).
  195.  
  196. Note: A patch is usually released quickly, between the scheduled releases.
  197. Perfective maintenance : See maintenance.
  198. Performance : The behavior of an application in terms of input speed, transport, processing, storage and output (an application's response time as observed by an end user).
  199. Performance management : Monitoring the performance of an application and defining measures to ensure that its performance continues to satisfy the relevant requirements.
  200. Planning and control : The process which ensures that the agreed services are provided at the right time and with the right capacity, by deploying the right IT and human resources at the right time.
  201. Pre-change request : A formal request for the provision of information about the overall impact of a possible change, which is submitted to an administrative organization, and is recorded and dealt with by it.
  202.  
  203. Note: It is sometimes called a Request for Information.
  204. Preventive maintenance : See maintenance.
  205. Priority : The order in which an activity must be dealt with or completed in relation to other activities.
  206.  
  207. Note: The priority is usually based on the impact of not performing the activity.
  208. Problem : An undesirable situation concerning an application or application management, which demands structural analysis and a solution.
  209. Problem management : The part of the process quality management which concerns the analysis of underlying causes of failures and defects affecting any products and services that have been supplied, and their resolution and prevention.
  210. Production environment : A collection of technical infrastructure components which are structured to facilitate the use of an application (as opposed to development, maintenance, testing and acceptance).
  211. Production or Operations : Making an application available for use together with its underlying data and technical infrastructure.
  212. Production test : See testing (activity)
  213. Production test : See testing (activity).
  214. Production verification : Verifying and ensuring that data processing occurs or has occurred as agreed.
  215. Project management : All of the managerial activities which are required to ensure that a project achieves it goals.
  216. Project plan : A description of a project's prerequisites, underlying principles, goals, achievements, activities, decision-making, structure and resources.
  217. Quality assurance system : The organizational structure, responsibilities, procedures, processes and facilities which are required for the purposes of quality assurance.
  218.  
  219. Note: Quality assurance implies the reduction, elimination or prevention of qualitative defects in products and services. Preventing defects, based on a systematic analysis of structural causes of defects is part of problem management.
  220. Quality management : This process is responsible for maintaining the quality (internal or otherwise) of the relevant processes and product by defining and monitoring them.
  221. Realization : The process by means of which a functional system design is translated into a technical system design and then into software which passes a unit test.
  222. Release : A new version of an application within which a number of change requests recorded in the change management process are designed, realized, tested and implemented as a coherent entity.
  223. Release management : The activities concerning the composition (in change management), adjustment (based on an impact analysis, for example), planning and managerial correction of a release (during planning and control).
  224. Reliability : The extent to which an object or service provides the agreed or expected functionality over a specified period of time.
  225. Renewal : Those activities which ensure that an information system continues to satisfy the stipulated requirements in economic, technical and functional terms.
  226.  
  227. Note: Aim: to ensure that business processes continue to receive the best possible support using any relevant application(s).
  228. Renovation scenario : Potentially new architecture (application and otherwise) along with the relevant pros and cons, and the way in which it is to be created.
  229. Request for change : See change request.
  230. Requirement : A formally recorded specification which an application or application management needs to satisfy (and continue to do so).
  231.  
  232. Note: In the case of applications a distinction is usually drawn between functional and non-functional requirements.
  233. Resource management : Those activities which seek to provide one with an insight into the (non-human) resources which constitute part of the appropriate infrastructure, application and relevant developments, and which have an impact on capacity.
  234.  
  235. Note: The allocation of available staff to the various activities which need to be performed, is generally referred to as human resource management. Resource management is an aspect of capacity management.
  236. Risk management : Those activities that ensure that threats are surveyed and action is taken to limit the implications of a threat.
  237. Scheduled maintenance : See maintenance.
  238. SDDB (Service delivery database) : The administration of services covered by a service level agreement and its extrapolation into service items.
  239. Security management : Those activities and procedures which are part of the process, continuity management, which seek to ensure that security measures are adopted in order to avoid threats or to limit their potential effect on continuity to an acceptable level.
  240. Service call : See incident.
  241. Service catalogue : A description of the characteristics of products and services which a client can obtain from a supplier.
  242. Service change request : A request for different or more extensive services than agreed (in the relevant SLA). See incident.
  243. Service delivery definition : The process used to identify supply and demand, and to translate this into a strategy for the services provided by the application management organization in the future.
  244. Service desk : The part of an organization which is the point of contact between the customer and the service and is (also) responsible for incident management.
  245.  
  246. See also first/second/third line.
  247. Service desk, First line : The service desk staff accept the calls, record their details and, if possible, deal with them immediately or send them to a specialist.
  248. Service desk, Second line : The specialists in the same company who are enlisted by the first line, if they cannot deal with a call.
  249. Service desk, Third line : Other specialist assistants who are called on to find a solution for calls, such as external suppliers.
  250. Service level report : A report in which the supplier accounts for the services provided to the client. Note : Such a service level report may also contain recommendations concerning the services.
  251. Service provisioning : Note: Service delivery is an acceptable synonym.
  252. Service team : The point of contact for business information management with whom arrangements are made about any services that are to be or have already been provided as part of application and technical infrastructure management.
  253. Service window : The period during which an information system and or any related services can be used.
  254. Shipment : A set of changed objects, which have to be transferred together to one or more production environments, including the relevant implementation instructions. See also change package and change set.
  255. Skills : The knowledge and competencies (of people) that are required or are present within an organization to provide any services that are requested or are required.
  256. Software : A collection of instructions based on a technical system design that indicate what a computer should do.
  257. Software control and distribution : The process associated with the maintenance and distribution of application objects (operational or otherwise) to the various development, testing and production environments.
  258. Software development : See: Application development.
  259. Software function : Part of an application that concretely implements a preference and/or requirement stipulated by the end users.
  260. Software package : Application which is created and supplied by a supplier and which contains standard functionality that can be used by multiple user groups in various organizations. Cf. custom software.
  261.  
  262. Note: Application management is performed by both the software package supplier (the management of generic functionality) and the relevant user organizations (the control of the parameters and tailored aspects which determine any functionality that is specific to the client concerned). For example, programs for enterprise resource planning, standard software which incorporates the most important business functions into a singly overall program.
  263. Specifications : The formulation of requisite functionality in terms, which are as concrete as possible.
  264. Strategic processes : Collective name for the Clusters: Application management organization strategy and Application strategy
  265. System defect (or Software defect if not hardware) : An imperfection in a component or system that can cause the system to fail perform its required function.
  266. Table : A structured entity set which is made up of a group of simple data elements.
  267.  
  268. Note: A table is usually in the form of a file which constitutes part of a database. A table is also referred to as an entity in a data model.
  269. Technical infrastructure : That part of an ICT infrastructure, which is responsible for the operation of the systems (the hardware, operating system, relevant documentation and so forth). They make up the ICT infrastructure together with the relevant application software, documentation and procedures.
  270. Technical infrastructure management : See Infrastructure management (synonym)
  271. Technical life span : A period following which it is necessary to replace a hardware system for technical reasons.
  272. Technical system design : A technical description of the manner in which a system is to implement the functionality that is set out in the functional design, in technical terms.
  273. Technical system test : See testing (activity).
  274. Technology definition : The process that determines which technology an organization will be using to provide services in the future.
  275. Test script : A description of how tests are to be conducted, a series of related actions and assessments relating to physical testing scenarios, whose implementation order has been stipulated.
  276. Test set : Representative test cases which can be reused in order to conduct various tests.
  277. Test, Acceptance : A test with the aim of assessing actual operation and/or of demonstrating such operation for the purposes of making any decision concerning a change or its approval.
  278.  
  279. Note: An acceptance test consists of different types of tests for various target groups (for example, production: technical aspects; users: user-friendly aspects; functional: proper data processing).
  280. Test, Functional system : A test which determines whether an application has been modified correctly (in accordance with the relevant functional system design), and whether the entire information system has the agreed functionality.
  281. Test, Integration : A test designed to determine whether an information system is still capable of accurate, comprehensive and timely operation after part of it has been modified.
  282. Test, Production : The assessment by or on behalf of technical infrastructure management whether any system which is to be put into service, satisfies the primary performance requirements and the secondary ones in relation to production documentation, capability for adjustments and the like.
  283. Test: Technical system : A test that is used to ascertain whether everything that has been done, complies with the relevant formulated design, whether what has been modified, operates as part of the whole, whether the latter can still be maintained following implementation, and satisfies the quality criteria agreed to from the perspective of administration and maintenance.
  284. Testing : #1 The process which seeks to ensure whether, what has been designed, has indeed been implemented.
  285.  
  286. Note: The unit and acceptance tests are not part of the testing process.
  287.  
  288. #2 Scheduled activities which purpose is to ensure that the anticipated operation of an information system coincides with its actual operation. Note: The test activities and findings are recorded for the purposes of ensuring that it is possible to accept an information system based on these details. A distinction is drawn between the various types of tests.
  289. Unit test : A type of test that assesses whether each program that has been created or modified, complies with the requirements stipulated in that respect.
  290.  
  291. See testing (activity).
  292. Use support : The process which ensures the communication from and to customers.
  293. User : See end user.
  294. Version : A collection of related programs with specific functionality, which together constitute an application. Multiple releases containing minor modifications may be issued as part of a version.
  295. Workload management : Monitoring and providing an insight into developments in proximity to a system and formulating measures based on this for the purposes of ensuring capacity as agreed.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement