Summary
This article aims to identify the relationship between the requirements of systems and the risk of IT projects. The article provides a description of the project definition, risk and information systems. The article also describes the project area associated with the requirements of computer systems and methods to assess these factors. Par-ticular attention was paid to the dependence of the hazards of the project from the requirements for information systems.
Keywords: information system, IT project, risk, risk management in IT projects 1. Introduction
The primary objective of computerization of an organization can be more competitive, increase operating efficiency or adapt to the changing conditions of reality. An information system is a tool for computerization. The concept of an information system refers to a set of interrelated elements such as hardware, software and users. The hardware and the users are part of the system that can be easily defined. But the software is much more difficult in the description; it is a link between the hardware platform and users. Implementation of the system is usually associated with the introduc-tion of innovaintroduc-tion in an organizaintroduc-tion, resulting in the destabilizaintroduc-tion of the existing structure as technical and personal. The system is designed to streamline, modernize, improve efficiency and, on the other hand, requires the staff’s need to learn, reorganizes the current work, which is not always conducive to acceptance of the new solution. It is important that the user at least participated in phases of requirements analysis and system testing. It should be noted that all the stages – from requirements analysis to implementation and organization of the care system – make up the project. With regard to the computerization of the application is the definition of an IT project, which mainly includes the realm of technological functioning of the organization: its effects allow the introduction of key assumptions.
An important component of any project is an event commonly called ‘risk’ that may arise during the implementation of the work and its effects can have a positive or negative impact on the project. Zarychta giving a definition of risk refers to them as an integral and unnoticed part of the project, which by logical, coherent, coordinated action, possible to achieve specific, defined, specific goals1. Ability to identify and assess the risk has a significant impact on project work carried out with suc-cess. It should be emphasized that the risk in the project may have a double meaning, because on the one hand may contribute to the failure of the project, but may also appear independent of the situations-workers that cannot be accurately predicted, it cannot be completely prevented and that
will affect the increasing the effectiveness of the work2,3. Zurek says that every project is carried out in the changing environment and in each of the areas there is a probability of the risk4.
The risk in the project is a very complex issue because of its multidimensional nature. Wroblew-ski5 writes “the technology, complex manufacturing processes, the impact of legal issues to the as-pects of design, a strong competitive environment common to most projects, a strong influence of the human factor in the process of gathering requirements and the manufacturing process itself”. Risks include the number of factors, most often one is not able to predict and that have an impact on all phases of project management. Computerization constitutes an important element of the devel-opment organization and the activities associated with it are often not the end-user acceptance; there is no reliable and complete information, which leads to the large number of factors that could jeop-ardize the attainment of its objective. The ability to define risk areas is important, which should manifest itself in an increase in efficiency and the implementation of the project design, which in turn will enable the organization to adapt to the dynamics of contemporary changes.
2. System requirements as a component of the overall project risk
Software requirements can be divided into two groups: user requirements and system require-ments6. The user specifies the expectations of the system, including the imitations in which the tem will work. The same system requirements apply to determine the specific services that the sys-tem is implemented within the specified user action. In other words, a user, by specifying his/her needs to the software, allows for the definition of the requirements for the system, which are divided into:
functional requirements that relate to services performed by the system, including the reaction behaviour in specific situations,
non-functional requirements, including the limitations of the system services. Re-strictions include the execution time, norms, standards, etc.
During the phase of defining the scope of the project (the software analysis and design), the main risks associated with customer's requirements, inter alia, an unclear vision system, too small or too detailed accuracy requirements or incomplete requirements. However, these are risks that can be eliminated by creating diagrams or diagrams that easily allow the user to verify the assumptions and evaluate the proposed plan in relation to the expectations. More complex elements are require-ments for information systems, which relate primarily to their complexity. Additionally, we can define as a source of risk in the areas of system requirements the following:
scalability, reliability, compatibility, uniqueness, expansion,
2 Federation of European risk management associations, Standard Zarządzania Ryzykiem, AIRMIC, ALARM, IRM: 2002. 3 Kaczmarek T.T., Zarządzanie ryzykiem handlowym i finansowym dla praktyków, OĞrodek Doradztwa I Doskonalenia Kadr, GdaĔsk 1999.
4ĩurek B., Zarządzanie ryzykiem z wykorzystaniem oprogramowania wspomagającego RMS, Materiały I Konferencji Project Management – DoĞwiadczenia i Metody, GdaĔsk 1999.
5 Wróblewski P., Zarządzanie projektami informatycznymi dla praktyków, Helion, Gliwice 2005. 6 Sommerville J., InĪynieria oprogramowania, Wydawnictwo Naukowo-Techniczne, Warszawa 2003.
performance.
that are described in detail later in this article. Complexity
The measure of system complexity is the size that describes the amount of the elements of the system. The complexity of the system should be calculated by FPAfunction points7,8,9,10. The chosen method allows one to estimate the productivity of the system attributes, but it is distinguished by five categories of attributes of productivity:
1. inputs to the system; 2. outputs from the system; 3. internal data sets; 4. external data sets; 5. inquiries into the system.
Each category can be assigned one of three levels of complexity, namely: 1. simple;
2. medium; 3. complex.
The individual attributes are entitled to weight, which are given in Table 2.1. Table. 2.1. Attributes of a production system
No. Attribute Complexity level of the attribute
Simple Medium Complex
1 Inputs to the system 3 4 6
2 Outputs from the system 4 5 7
3 Internal data sets 7 10 15
4 External data sets 5 7 10
5 Inquiries into the system 3 4 6
Source: [2].
The values of individual weights are used to calculate the global value unadjusted function points NPF, according to the formula:
ܰܲܨ ൌ ܹܰ ଷ ୀଵ ହ ୀଵ
where: W – value of weight factor;
N – number of elements in the project; i – number of processing elements; j – number of levels of complexity.
7 FPA (ang. Function Point Analysis) – function points method developed by Allan J. Albrecht in the work team of employees of IBM. Currently being developed by the organization IFPUG (ang. International Function Point User Group).
8 Szyjewski Z., Zarządzanie projektami informatycznymi, Placet, Warszawa 2001. 9 Szyjewski Z., Metodyki zarządzania projektami informatycznymi, Placet, Warszawa 2004.
10 Garmus D., Herron D.: Function Point Analysis: Measurement Practices for Successful Software Projects, Addison-Wesley Information Technology Series, Boston 2000.
The next step is a method of correcting the resulting value of the NFP, taking into account fourteen factors that affect the operation of the system, rated on a scale of 0 to 5 (0 – no impact, 5 – very high impact). Correction factors used in the method are:
1. Occurrence of communications equipment 2. Scattering process
3. Required parameters processing speed 4. Complexity of the processing logic 5. Number of transactions
6. Introduction of online data 7. End-user performance 8. Updating the online data 9. Dispersion of the territorial 10. Complexity of data processing 11. Software portability
12. Ease of installation 13. Ease of use
14. Projected changes during the operation.
The comprehensive value of the adjusted function points are calculated according to the for-mula ൌ כ ሺͲǡͷ ͲǡͲͳ כσ ଵସ୧ୀଵ ୧ሻ
where: PF – comprehensive value of the adjusted function points; NPF – the global value unadjusted function points; K – value of the correction factor.
Factors of 0.65 and 0.01 are determined on the basis of experience and surveys of IBM. The final adjustment of function points in the range from 0.65 to 1, 35 and are the positive or negative influences of the initial assessment of the complexity of the system.
The last step of the method is to define the indicator LOC (called Lines of Code), the estimated number of lines of code of the software, which is calculated according to the formula
ܮܱܥ ൌ ܲܨ כ ܯ
where: PF – comprehensive value of the adjusted function points, M –multiplier assigned according to the rule given in Table 2.2.
Table. 2.2. Value of multiplier
Programming language M Assembler 320 C 128 C++ 53 Cobol/Fortran 105 Pascal 90 Jzyki obiektowe 30 Source: [4].
The resulting number of lines of code is a source of data to calculate the effort and enables one to estimate the feasibility of the work in the specified time and within budget, because:
raised to the power 1.15 is an estimate of the number of pages of documentation generated in the project;
raised to the power 1.2 is an estimate of the number of test cases;
raised to the power 0.4 is an estimate of time-consuming design work (in person-months); divided by 150 is an estimate of the number of people needed for the project11.
The measure of system complexity can be classified into one of five groups:
1 – time spent in the range <81–100%> provided for the execution time, high complexity system, high workload, little chance of implementation;
2 – time spent in the range of <61% .. 80%> of time provided for execution, high com-plexity system, high workload, little chance of implementation;
3 – time spent in the range of <41% .. 60%> of time provided for execution, medium complexity system, high labour intensity, a good chance of implementation;
4 – time spent in the range of <21% .. 40%> of time provided for execution, moderate complexity system, the average effort, a good chance of implementation;
5 – time spent in the range <0% .. 20%> of time provided for execution, low complexity system, low labour intensity, a good chance of execution.
Scalability
Scalability of the system is the amount of information describing the capabilities of the system to meet the requirements of the organization that is to be used. Scalability reflects the possibility of implementation of tasks by the system, taking into account the varying degrees of intensity of these tasks. A measure of scalability shows the minimum and maximum number of elements at which the application is most efficient. A measure of scalability is expressed by speed and efficiency12. Speed can be expressed in the formula:
ܵ ൌ݊ ʹ݈݃݊ כ where: n – number of processes,
p – number of processors.
Efficiency is expressed in the formula: ܧ ൌ݊ ʹ݈݃݊ where: n – number of processes,
p – number of processors.
The higher the speed of S and the efficiency of E, the greater scalability of the system, the ability to work in a similar capacity by increasing the scale of the system, or increase in the number of users. In fact, the estimated value of the scalability of the system enables the provision of adequate
11 Mirecki J., Szacowanie wdroĪeĔ, Computerworld, Wydanie: 39-2008. 12 Kwiatkowski J., Skrypt do wykładu, Uniwersytet Wrocławski, Wrocław 2010.
performance, especially in the case of the evolution of the system or hardware modification or change users' needs. Depending on the obtained values of speed and efficiency to the degree of scalability of SKi, the proposed system can be attributed to one of five groups, according to the rule:
1. speed and efficiency provide 0% – 20% of the assumed productivity, 2. speed and efficiency provide 21% – 40% of the assumed productivity, 3. speed and efficiency provide 41% – 60% of the assumed productivity, 4. speed and efficiency provide 61% – 80% of the assumed productivity, 5. speed and efficiency provide 81% – 100% of the assumed efficiency. Reliability
Reliability of the information system is called the degree of probability with which the system will work flawlessly in a given period of time, in a particular environment, implementing a specific purpose13.
Reliability is measured by examining the frequency of failure, the rate ROCOF (called Rate of Failure Occurrence – the frequency of failure). The incidence rate of unexpected behaviour allows one to specify the number of errors that are likely to occur in 100 time units of the system. For example, an ROCOF rate of 0.02 means that a period of 100 time units will probably be two fail-ures14.
Another factor taken into account when assessing the reliability of the system is the method of procedure in the event of a fault. Taken into account in this regard are three approaches: namely to avoid detection, removal and fault tolerance. Depending on the used technique in the computer sys-tem to respond to the occurrence of faults, MN uses a multiplier that is assigned a value according to the rule:
3 – Avoiding faults – no need to use methods to create a system that minimizes the probability of confusion or allows them to be identified prior to failure: for example, avoiding the error-prone design of pro-gramming languages;
2 – Troubleshooting – no need to use methods of verification and acceptance, which increase the likelihood of identifying and removing defects before using the system, such as continuous testing;
1 – Tolerating faults – requires the use of methods, which guaran-tee that the occurrence of faults in the system does not cause errors, such as the introduction to the system of internal control mechanisms and the use of redundant modules.
The total value representing the degree of confidence can be expressed by the formula ܱܰ௦ൌܯכ ܴܱܥܱܨ*0,01
13 Gierszewska G., Romanowska M., Analiza strategiczna przedsiĊbiorstwa, PWW, Warszawa 2001.
14 Yeh L., Calculating the Rate of Occurrence of Failures for Continuous-time Markov Chains with Applications to a Two-component Parallel System, Journal of the Operational Research Society, Vol. 46, No. 4, Apr. 1995.
MN =
Depending on the resulting value of the evaluation of reliability, an IT system can be assigned a value between <1, 5>, where:
1. ONs{0..20}, system with a low degree of reliability, unpredictable operations results; 2. ONs {21–40}, system with a low degree of reliability, predict the operations results; 3. ONs {41–60} system with a medium degree of reliability, predict the operations results; 4. ONs {61–80} system with a high degree of reliability, the expected results of operations; 5. ONs {81–100} system with a high degree of reliability, the expected action results. Compatibility
The compatibility system is its ability to work with existing technologies in the organization. Compatibility is considered in two areas – hardware and software. In the hardware, compatibility means you can move the individual elements of the system between the system and operations car-ried items. During assessment, the compatibility of the hardware should be remembered that the higher degree of hardware compatibility, the less the financial outlay for the purchase of new equip-ment. The area of software refers to the action of the individual components of the system, among new and old system modules or between new system and the software already functioning in the organization.
A measure of compatibility is the interval <1, 5>, where:
1- system is entirely incompatible with the hardware and soft-ware in an organization;
5 – system is fully compatible with existing hardware and software used in the organization.
In other cases, Ki takes values between 0 and 5. Uniqueness
The uniqueness (U) of the information system is the degree of innovation. Uniqueness reflects the degree of changes that are associated with the implementation of the system and the effects that occur during the implementation of the functioning of the organization. Risks associated with the uniqueness refer to the two key aspects, namely the scope of the system and the future users, who may show a reluctance to change or have problems using the system. Risks associated with the improvement of existing technologies are less than the total innovation. Closely associated with the scope of this project, which represents the degree of complexity and risk, for example, is the imple-mentation of the additional module will be much lower than the risk associated with the implemen-tation of the system in the organization of low-tech.
Uniqueness is a subjective measure that can be assigned a value range of <1, 5>, according to the rule:
U = 1 – full of innovation – means that the system is new in the functioning of the organi-zation;
U = 2 – partial innovation – means that the implementation of the new system will take place only in some areas of the organization;
U = 3 – average innovation – means a modification of the already implemented a system that is not associated with any business organization;
U = 4 – improvement of existing technology – means that the system will be expanded with additional modules;
K =
U = 5 – improve existing technologies – means that the organization functioning regulatory system will be modified slightly.
Expansion
An expandable system is the possibility of modifying the new modules when the organization changes. Providing an expansion system allows for the organization to add more required modules without having to make excessive modifications.
A measure of expansion Ri can take a value of <1, 5>, where: 1 – no possible expansion of the system; 5 – full opportunity to extend the system.
No possible expansion of the system (Ri = 1) means that the system does not have a mechanism of expansion; there is no possibility for expansion modules.
Full opportunity to extend the system (Ri = 5) means that the system has a mechanism of expan-sion, that is, it is possible to extend the system without having to make unnecessary changes. Performance
System performance is that of determining how much work will craft a system in a given period of time, according to the relationship that the more work the system will perform in a given time, the greater its efficiency. System performance is measure using a Markov model15,16, which assumes that the probability of an event depends only on the result of preceding events. In other words, the final state depends on the state preceding it. The Markov model is assumed to calculate the average length of stay E(si) in the transition state si, according to the formula
ܧሺݏሻ ൌσ ͳ ߣ אሺ௦ሻ
where: E(si) – average length of stay in the transition state; i – parameter exponential random variable.
The Markov model also assumes the calculation of the average number of passes E(ti) through the transition state si, according to the formula
ܧሺݐሻ ൌ ܧሺݐሻ כ אூሺ௦ሻ
ሻ
where: E(ti) – the average number of passes through the transition state; pki – the transition function.
After calculating the value of E(si) and E (ti), the Markov model allows the calculation of the average execution time across the network of E(t), according to the formula 17,18
15 Winiarski J., Zastosowanie iloĞciowych technik zarządzania ryzykiem w procesach projektowania i budowy systemów in-formatycznych, System wspomagania organizacji, Katowice 2009.
16 Szekli R., Wprowadzenie do stochastycznych modeli sieci, Skrypt do wykładu, Uniwersytet Wrocławski, Wrocław 2009. 17 Winiarski J., Zastosowanie iloĞciowych technik zarządzania ryzykiem w procesach projektowania i budowy systemów in-formatycznych, System wspomagania organizacji, Katowice 2009.
18 Szekli R., Wprowadzenie do stochastycznych modeli sieci, Skrypt do wykładu, Uniwersytet Wrocławski, Wrocław 2009. R
ܧሺݐሻ ൌ ܧሺݏሻ כ ܧሺݐሻ ସ
ୀଵ
Pointing to the relationship between system performance and costs incurred to obtain the system performance is obtained as , which is calculated from the formula
߱ ൌ ݉ כ ܹ where: – system performance;
W – value of weight factor,
m – multiplier whose value is assigned to a system based on the value of average run-time network activity E(t). The value of the multiplier m {1,2,3,4,5} is assigned according to the rule:
1- average execution time of the network activities between 0% – 20% of the assumed produc-tivity,
2- average execution time of a network of activities in the range 21% – 40% of the assumed productivity,
3- average execution time of a network of activities in the range 41% – 60% of the assumed productivity,
4- average execution time of a network of activities in the range 61% – 80% of the assumed productivity,
5- average execution time of a network of activities in the range 81% – 100% of the assumed productivity.
The value of weight can take a value of {0.5, 1, 1.5, 2} according to the rules: 0.5 – poor performance at high price,
1 – poor performance at a low price,
1.5 – high performance evaluation at a high price, 2 – high performance evaluation at a low price. 3. Summary
System requirements are the link between key people in the project, the client, end users and the project team. The customer counts on benefits, particularly financial, to implement the system. You, in turn, will work with the system and requires him to make it easier for him to perform eve-ryday tasks. The project team based on system requirements analyses and builds the software. Eval-uation of the complexity, scalability, reliability, compatibility, uniqueness, extensibility and perfor-mance allows the estimation of the feasibility of the system within the established time and budget. Determining the value of these elements enables the identification of areas that may pose a risk to achieving the planned scope of the system.
The calculation of measurement described in Chapter 3 provides a qualitative assessment of risks to the project area relating to the system requirements. Depending on the specific project, you can select the major requirements and designate only the essential values or add additional require-ments not included in the article. After estimating the values of the individual requirerequire-ments in order to quantify the risk, Table 4.1. presents the rule to assign weights Wi for the measurement values obtained.
W =
Table 4.1. Values of weights Wi
Value Wi Value Wi Value Wi Value Wi Value Wi
Complex-ity 1 0 2 1 3 2 4 3 5 4 Scalability {0..20} 0 {21..40} 1 {41..60} 2 {61..80} 3 {81.100} 4 Reliability {0..20} 0 {21..40} 1 {41..60} 2 {61..80} 3 {81.100} 4 Compati-bility 1 0 2 1 3 2 4 3 5 4 Unique-ness 1 0 2 1 3 2 4 3 5 4 Expansion 1 0 2 1 3 2 4 3 5 4 Perfor-mance {0.5.. 1.5} 0 {1.6.. 3.9} 1 {4.0.. 5.9} 2 {6.0.. 7.9} 3 {8.0..10} 4 Source: own computations.
On the basis of measurement values assigned to the weights on a scale of 1 to 5, the total risk of this area can be calculated in accordance with the formula:
ܳൌ݉ܽݔ σ ܹͳ
ୀଵ כ ܹୀଵ
where: Wi – weight measurement,
max – the maximum value of the sum of the weights, i – an index of measurement.
The resulting value of the risks associated with the requirements of the classification system places the project into one of four groups of Q = {I, II, III, IV, V}:
QI – the value of Qi א <0; 0.24>, the system of high complexity, low score of the other requirements, the requirements difficult to achieve a negligible likelihood of comple-tion of work;
QII – the value of Qi א <0.25, 0.50>, the complexity of large systems, requirements difficult, but at a high volume of work possible to satisfy the small likelihood of exe-cution;
QIII – the value of Qi א <0.51, 0.75>, the system of medium complexity, demands moderate, but not requiring much effort and a high probability of execution;
QIV – the value of Qiא <0.76, 1.00>, the complexity of the system feasible, the re-quirements indicate a high probability of realization.
Risk is inherent in the implementation of IT projects, which is why one should pay special attention to them. Management of this element, particularly in relation to user requirements, should acquire a growing importance, and should be an integral part of every project. Implementation of information systems is designed to streamline processes, realization organization and proper evalu-ation of system requirements indicated may decide to execute the project successfully. Useful in determining the value of individual requirements appear to be different assessment methods, the use of which increases the precision of estimates. Assessing the requirements described and other sys-tems dependent on the specific project not included in the article, enables the identification of isys-tems
that may constitute a source of threats and allow the proposed scheme to assign one of four groups depicting the probability of the project.
Bibliography
[1] Federation of European risk management associations, Standard Zarządzania Ryzykiem, AIRMIC, ALARM, IRM: 2002.
[2] Garmus D., Herron D.: Function Point Analysis: Measurement Practices for Successful Software Projects, Addison-Wesley Information Technology Series, Boston 2000. [3] Gierszewska G., Romanowska M., Analiza strategiczna przedsibiorstwa, PWW,
War-szawa 2001.
[4] Humphrey, Watts, A Discipline for Software Engineering, Addison-Wesley, 1995. [5] Kaczmarek T.T., Zarzdzanie ryzykiem handlowym i finansowym dla praktyków,
O rodek Doradztwa I Doskonalenia Kadr, Gdask 1999.
[6] Kwiatkowski J., Skrypt do wykładu, Uniwersytet Wrocławski, Wrocław 2010. [7] Mirecki J., Szacowanie wdroe, Computerworld, Wydanie: 39–2008.
[8] Sommerville J., Inynieria oprogramowania, Wydawnictwo Naukowo-Techniczne, Warszawa 2003.
[9] Szekli R., Wprowadzenie do stochastycznych modeli sieci, Skrypt do wykładu, Uni-wersytet Wrocławski, Wrocław 2009.
[10] Szyjewski Z., Metodyki zarzdzania projektami informatycznymi, Placet, Warszawa 2004.
[11] Szyjewski Z., Zarzdzanie projektami informatycznymi, Placet, Warszawa 2001. [12] Winiarski J., Zastosowanie ilo ciowych technik zarzdzania ryzykiem w procesach
projektowania i budowy systemów informatycznych, System wspomagania organiza-cji, Katowice 2009.
[13] Wróblewski P., Zarzdzanie projektami informatycznymi dla praktyków, Helion, Gli-wice 2005.
[14] Yeh L., Calculating the Rate of Occurrence of Failures for Continuous-time Markov Chains with Applications to a Two-component Parallel System, The Journal of the Op-erational Research Society, Vol. 46, No. 4, Apr. 1995.
[15] Zarychta J., Przygotowanie i zarzdzanie projektem UE. Zastosowanie metodologii struktury logicznej Łód, 2008.
[16] urek B., Zarzdzanie ryzykiem z wykorzystaniem oprogramowania wspomagajcego RMS, Materiały I Konferencji Project Management – Do wiadczenia i Metody, Gdask 1999, str. 15.
WYMAGANIA SYSTEMU JAKO SKŁADOWA RYZYKA PROJEKTÓW INFORMATYCZNYCH
Streszczenie
Celem artykułu jest wskazanie zaleĪnoĞci pomiĊdzy wymaganiami stawianymi wo-bec
systemów, a ryzykiem projektów informatycznych. Artykuł zakłada opis definicji pro-jektu, ryzyka oraz systemu informatycznego. W artykule opisano takĪe obszar projektu informatycznego związany z wymaganiami systemu i metody umoĪliwiające ocenĊ tych czynników. Szczególną uwagĊ zwrócono na zaleĪnoĞü stopnia zagroĪenia przed-siĊwziĊcia od wymagaĔ stawianych systemom informatycznym.
Słowa kluczowe: system informatyczny, projekt informatyczny, ryzyko projektów informatycz-nych
Aleksandra Radomska-Zalas
Pastwowa Wysza Szkoła Zawodowa Instytut Techniczny
ul. Teatralna 25, 66-400 Gorzów Wlkp. e-mail: aradomska-zalas@pwsz.pl
