{'fraction_non_alphanumeric': 0.0209412542709137, 'fraction_numerical': 0.005125096439986774, 'mean_word_length': 5.2168550873586845, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Criticality estimation of IT business functions with the Business Continuity Testing Points method for implementing effective recovery exercises of crisis scenarios

The primary goal of the present paper is the introduction of a new approach of defining IT unit business functions exact criticality levels and respectively categorize them to the appropriate recovery tests, prior to their thorough documentation which includes actual desired recovery time frames. The method is entitled as Business Continuity Testing Points and it is based on the concept of Use Case Points, a fundamental project estimation tool utilized for sizing of object-oriented system development. The aim of the contribution is to ameliorate the existing manual way of determining recovery time of IT business functions that is based exclusively on experience of IT personnel, by introducing a calculation method of multiple factors that can negatively affect the recovery process. The elimination of damage as a result of tested immediate response action in a crisis situation that disrupts core IT operations constitutes the aimed advantage of the proposed contribution


Introduction
The present enterprise operations are fully dependent on information technologies, complex software applications and multiple corresponding business functions. Thus, one of the most important, and nowadays obligatory, tasks of the modern enterprises and organizations is the development and the establishment of an efficient and effective Business Continuity Management [1]. It is by many experts considered to be one of the key Areas of ICT Competencies [2]. Its imperative establishment in terms of enterprise operational policy and strategy stems from multiple and various unexpected and forecasted physical, human or even technical threats that many organizations have experienced within the recent years.
Immediate system recovery for minimization of operational and financial damage stems from a cautiously documented Business Continuity Plan (BCP) [3] [4]. The BCP specifies the methodologies and procedures required to backup and recover every functional units of the business [5]. Thus regular testing in a simulative but as real as possible mode of the most critical business functions should be scheduled for controlling the stable functionality of IT business functions in crisis situations. Criticality estimation of business functions and corresponding applications is a vital task to be solved by IT managers when planning business continuity testing exercises that concern their unit. The organization and implementation of successful business recovery tests presuppose the creation of a detailed and accurate documentation of the critical business functions and corresponding applications to the Business Impact Analysis (BIA) template [3] [4].
Primary discussed and analyzed topics of the present work are all placed within the context of testing important IT business functions' rapid recovery according to a hypothetical simple, average or complex testing crisis scenario decided on the basis of corresponding process criticality level.
The author's attempt is to develop and propose a standard methodology for defining the most crucial IT business functions and processes in order to thoroughly document them in the Business Impact Analysis document and subsequently propose the appropriate recovery test type after calculating and defining exactly their criticality level. The determination of this level is based on consideration of corresponding impact value level [6] and additionally the minimum of business functions which must be up and running to ensure the company's basic operation in emergency events. The applied theory behind the construction of the new approach is the Use Case Points method [7]. Use Case model is one of the most tested in practice methodologies for defining user requirements [8]. Additionally, the Business Continuity Management document core characteristic is that it constitutes a requirements' document as well, though from the scope of business function testing procedure within a crisis situation. Required task by the organizations is the recovery of a business function within the desired Recovery Time Objective (RTO) or even the Maximum Acceptable Outage [4] [3], as they are determined by the Business Continuity team and documented in the BIA template.
Thus, by implementing the Use Case concept can help IT managers perform accurate and objective business function criticality scoring and respectively determine the testing approach of each function, according to the BIA process documented data. The scoring of function criticality is applied according to the rules of the Use Case Points methodology by considering multiple factors, both technical and environmental which ultimately affect the business function recovery process and the timeframe that it can be accomplished. The estimated effort required to "bring back to life" a vital IT business function will comprise of the key indicator of the corresponding testing approach intended to be applied to the specific function.

Testing critical IT business functions within a defined enterprise Business Continuity Management policy
From the point of view of scientific literature and industrial practice BC addresses questions of how to handle risk issues in the case that critical business processes of an organization fails [9]. Historically, BC addressed IT processes, later on, business processes came up as the final purpose of their supporting IT processes [10] [1].
The importance of Business Continuity Testing is outlined and thoroughly analyzed by many experts. Precisely it is stated that organizing regular exercises such as desktop and simulation drills is the only way to discover gaps and address them [11].
The current paper focuses on the IT department's successful documentation and testing of the most critical functions and processes; hardware and software should support critical business functions, so the IT functions, in large part, will be driven by all the other departments. HR might say "we have to have our payroll application"; marketing might say "without our CRM system, we can't sell any products"; manufacturing might say "without our automated inventory management system, we can't even begin to make anything." Therefore, the IT department's critical business functions are driven externally, to a large degree [12]. However, the successful IT business continuity management policy should focus to the immediate recovery of the indeed most important operations of the enterprise, defined by the ISO 22301:2012 as Minimum Business Continuity Objective, briefly stated as MBCO [4].
Creating a continuity plan is a long-term process and companies should review the existing documentation as an ongoing project [13] [14]. The actual purpose of testing is to achieve organizational acceptance that the solution satisfies the recovery requirements. Plans may fail to meet expectations due to insufficient or inaccurate recovery requirements, solution design flaws or solution implementation errors [3]. The differentiation of critical (urgent) and non-critical (non-urgent) organization functions/activities is the core task of B.I.A. Critical functions are those whose disruption is regarded as unacceptable. Acceptability is mainly affected by the cost of recovery solutions. A function may also be considered critical in the case that it is imperative due to specific law.

Exercise Categories
The exercises as they were defined by the Business Standards Institute are divided into 3 basic categories [3]: Tabletop Exercises: they typically involve a small number of people and participants, who work through a simple scenario, discuss specific aspects of the plan and only a few hours are consumed.
Medium Exercises: conducted within a "Virtual World" and bring together several departments, teams or disciplines.
Complex Exercises: also occur within a virtual world, but maximum realism is essential and duration is unknown.
The results of insufficient and poor testing of software applications are known and obvious within the enterprise environment. Test engineering is seldom planned for in most organizations and as a result, products enter the market insufficiently tested. Negative customer reactions and damage to the corporate image is the natural consequence [15]. Similarly, the test engineering process for critical business functions from the business continuity management standpoint is essential, since the negative enterprise effects caused by unsuccessful response to a real crisis event will be an established fact. Consequently, according to the above statement all business functions should be tested regularly so that all involved staff will be prepared for a real crisis event. The idea behind the proposed contribution is that test success is based on mapping of each IT business function to the most suitable of the above analyzed exercise levels after determination of its impact value level. The way that the mapping is performed is depicted at the following section (see Table8).

Impact Value Levels of IT business functions
Darril Gibson [6] indicates the impact value level of each business function according to its accepted downtime period without causing negative effects to the enterprise or the organization. The four levels of impact value are: The above mentioned levels will be applied to the new proposed Business Continuity Testing Points methodology so that the responsible IT manager of a specific business function will be able to classify it to the appropriate exercise category.

Classifying Actors and Use Cases
The primary step of the Use Case Points procedure is to classify and calculate the Actors' weights and the weight of a Use Case. Classification method with regard to complexity degree of both Actors (see Table1) and Use Cases (see Table2) are listed respectively. Simple Actor [7] [23] [24] represents another system with a defined Application Programming Interface, API, an average actor is another system interacting through a protocol such as TCP/IP, and a complex actor may be a person interacting through a GUI or a Web page.
By counting the number of actors of each kind (complex, average or simple), multiplying each total by its weighting factor and finally adding up the products we calculate the the total Unadjusted Actor Weights, briefly mentioned as UAW. The result of the calculation is provided by Eq. (1): where n= Number of Actors, A= Actor, W= Actor's Weighting Factor.
In a similar way the Unadjusted Use Case Weight (UUCW) value is calculated by multiplying number of each use case category by the corresponding weighting factor, and the products are added up according to Eq. (2), where n= Number of Use Cases, U= Given Use Case, W= Use Cases weighting factor The UAW is added to the UUCW to get the unadjusted use case points from Eq. (3)   The formula applied for calculating Technical Complexity Factor (TCF), is provided by Eq (4): after multiplying the value of each Technical Factor (see Table3) by its corresponding weight and then adding all these numbers to get the sum called TFactor.
In the same way Eq. (5) is applied for calculating Environmental Factor (EF): after multiplying the value of each Environmental Factor (see Table4) by its corresponding weight and then adding all these numbers to get the sum called EFactor.
The final calculation of the Adjusted Use Case Points (UPC) is provided by Eq. (6): The estimation effort is the final part of the Use Case Points method. By multiplying the specific value (man-hours) by the UCP, estimated effort can be obtained [23] [25]. A factor of 20 man-hours per UCP for a project is suggested by Karner [7].

Motivation, utilized theory and algorithmic process behind the BCTP methodology
The basic motivation for the construction of the BCTP approach as to defining exact exercise category for each IT function and enabling the implementation of effective recovery tests according to the defined RTO and MAO timeframes of business impact analysis documentation, has been the elimination of erroneous BIA documentation of high priority functions and processes which usually leads to poor testing implementation. As it was already mentioned, the basic reason is that RTO and MAO timeframes documentation in a BIA template is based on employers' everyday operational experience within the organization.
The following step was the selection of the appropriate existing and proved by practical implementation theory in order to derive the new model. With the above stated assumption, since the BIA documentation constitutes a basic element of the general Business Continuity Plan, which is considered to be a requirements' document from system recovery standpoint, a standard requirement analysis and practically implemented methodology such as Use Case Points approach was required as a driving method for the construction of the Business Continuity Testing Points approach. Moreover the testing goal is to satisfy organizational acceptance that the solution meets the recovery requirements.
As in the case of the Use Case Points methodology, the proposed model's construction is separated in 2 parts. The first part constitutes the mapping of Actors and Use Cases for calculation of Unadjusted Use Case Points, to the Actor Types 1 (Human Level) and 2 (Application Level) and Business Processes, instead of Use Cases, in order to calculate Unadjusted Business Function Testing Points (UBFTP). The idea is that in case of obvious and simple business function with low score of unadjusted points there will be no need for further analysis, and thus direct decision about impact value level and exercise category will be made in the final 2 nd part. It is assumed that this simple approach concerns only business functions which are not included in MBCO and the corresponding exercise category planned will be either tabletop or medium. Exercise category is based on the derived number of unadjusted points and impact value level (3 or 4).
The second part constitutes a process intended for more complicated IT business functions for which complex exercises should be planned. Thus, exact impact value level should be decided first. The idea is the utilization of technical recovery, environmental recovery and also unexpected recovery factors which will enable better understanding of the exact impact value level (1 or 2) of the business function. The term Unexpected Recovery Factors is a new additional factor category included in the proposed model since Business Continuity Tests should be characterized by hypothetical unexpected conditions that will could prolong the recovery process.
Consequently the algorithmic steps to be implemented in terms of classifying IT business functions to the appropriate exercise category defined by the Business Standard Institution are the following: Step 1: Defining Actor Types of both levels (Human and Application) Step However, if exact definition of the above elements is desired by the organization, the process is the same as it is in the case of complex IT functions that are included in MBCO.
Step7: If Function is included in MBCO then exact impact value level (1 or 2) must be defined. Determined exercise category is complex. The exact Impact Value level is calculated by considering Technical Recovery Factors, Environmental Recovery Factors and Unexpected Event Factors. Impact value level depends on the Adjusted Business Function Recovery Points (ABFRP) value and the total Recovery Effort value that will be computed. For better understanding of the analyzed algorithmic steps, a schematic presentation is also included in the current work (see Fig.1) via a UML Activity Diagram.  Table5). Moreover, Actor Type 2 represents the application involved in the same function or process (see Table6).

Weighting Factor
Simple Tasks   1   Average   2   Complex   3 Eq. (7) and Eq. (8) respectively provide the results of the calculation of each Actor type The Total Unadjusted Actor Weights (TUAW) is calculated by Eq. (9) Additionally, Use Cases are now replaced by Business Processes. We do not count Use Case Unadjusted weights but Business Process Unadjusted Weights. The business process complexity is now classified according to the number of process steps (see Table7). The calculation of the Unadjusted Business Process Weights is implemented with Eq. (10) By obtaining the value of unadjusted points the first level evaluation of function criticality has been terminated. Functions that are not urgent can be simply documented to BIA template either with Impact Value Level3 and Medium Exercise Plan or with Impact Value Level4 and Tabletop Exercise plan (see Table8).    Table11). The consideration and calculation of the specific factors is considered to be highly important; the negative influence of such factors could result to time deviation from the desired RTO and MAO of a business function recovery effort. The equation that will provide the URFactor, and the weight of each individual factor constitute subject of further research. However a short reference to each unexpected factor is required.
Weather conditions can constitute preventive element from reaching the recovery site or special office. The Disaster Type should also be considered in a testing scenario. Slight system interruption differs from building collapse in terms of recovery time. Additionally Timely Information Distribution of Crisis Event can result either to immediate response of staff or late response if the message is sent later on.
The above number will be considered towards the calculation of the Recovery Testing Effort (RTE) of a unique IT business function. The value of the effort should be less than or equal to the desired RTO, or by the worst case scenario equal to MAO. In any other case recovery tests or RTO, MAO values must be modified. The equation and method for calculating Recovery Time Effort is also a future feature of the model.

Conclusions
IT Business continuity constitutes a crucial issue of modern enterprises.