Software System in Different Cultural Environment - Research Paper Example

?Investigating the Different Perception s on Safety, Performance, and Security Non-Functional Requirements of a Software System in different cultural environment 3.0 Methodology 3.1 Research Methods Used The research method used by the researcher was the mixed research method, which makes it possible for the researcher to combine both qualitative and quantitative research procedures (Practitioner Research and Evaluation Skills Training, 2004). In consonance with the qualitative research, the researcher employed the use of secondary data collection to gain insight into specific issues of differences in cultural perception of customers on the safety, performance and security of software systems. It would be noted that the collection and use of secondary data requires the review of existing works of research that are related and relevant to the current study (Kimberly, 2009). In effect, the researcher employed the use of comprehensive literature review to serve the purpose of qualitative data collection. For the quantitative method, the researcher made use of primary data collection, which required the collection of first hand data from an identified research setting. The research setting comprised the IT systems development environment where the researcher made use of IT students, IT engineers, IT employees, and other IT experts. The primary data collection took place by designing a questionnaire, which contained questions on various thematic areas, relating to the purpose of the study. There were two major components of the questionnaire. The first sought to collect general background data or information on the respondents. Examples of these had to do with their nationality, years of experience in the field of IT and their role in software system. The second part contained questions on the actual hypotheses that the researcher was testing. 3.2 Reasons for choice of Research Methods used A number of factors and reasons informed the use of questionnaire and literature review as methodologies for the study. The first is that the combination of a secondary data collection process and a primary data collection process went a long way to improve the reliability and internal validity of the study. It will be noted that the reliability of a study is achieved when the results from the study are found to be empirical (Practitioner Research and Evaluation Skills Training, 2004). This means that when repeated with the same variables, the research must produce the same results within different locations or settings. Now, with the combination of questionnaire and literature review, the researcher was offered the opportunity of testing the results gathered through primary data collection with data from secondary sources. In effect, it was possible to internally check for consistency of responses and how they conformed to universally accepted standards. With the questionnaire as an independent data collection tool, the advantage that it offered the researcher was that it made quantitative data analysis very easy. This is because almost all the questions posed were closed ended questions, requiring the respondents to select their answers from given options (Kimberly, 2009). This way, it was possible to easily quantify the answers into mathematical indexes. What is more, the literature review was very useful in collecting highly authenticated data because options of researchers were compared and contrasted with each other before making personalized conclusions to suit the research problem. 3.3 Shortfalls of other available Research Methods Apart from the use of literature review and questionnaire, there are other research methodologies that the researcher could employ in the data collection process. However, these were not selected because they do not pose merits and advantages that surpassed the ones that the questionnaire and literature review offered. Two of these research methodologies that the researcher could fall on are interview and field observation. An interview is a question and answer session that a researcher has with a group of respondents in an oral form (Oatey, 1999). The reason the use of interview was not appropriate for this study was that it would have been very time consuming, considering that the researcher would have had to be physically present during the collection of responses. Meanwhile, there were several areas of the research that the researcher needed time to attend to. Using an interview would have therefore affected the remaining aspects of the study, causing them to be done in a rush. What is more, the interview could not have offered the researcher the kind of quantitative data that was being looked for. The absence of quantitative data would have also meant that data analysis was going to be personalized and based of discretional judgment of the researcher instead of basing it on empirical statistics (Kimberly, 2009). On the part of field observation, it would have also had the same problem of not offering empirical quantitative evidence in the data collection process (Kajornboon, 2005). 4.0 Data Analysis 4.1 Analysis of Primary Data from Questionnaire 4.11 Effect of Security controls on Performance The sixth item on the questionnaire sought to collect data from the response for their opinion on the relationship that the use of security controls on a software system could affect performance. The researcher posed this question because of data that was collected on security controls for software systems in the literature review. From the literature review, it was established that having security controls on a given software system ensures that the software is free from external manipulations (Le Grand, 2006). Meanwhile, other researchers whose works were reviewed debated that restricting security controls could have a negative effect on performance because it restricts the level of ingenuity that system operators could put into the usage, manipulation and management of the system (Sans Institute, 2013). Once the question was posed to the respondents for their version of philosophy of the effect of security controls on performance, the figure below shows the various outcomes that were produced. Fig 4.1 Reponses on relationship between security controls and performance From the figure above, it can be realized that a total of thirty three (33) responses were gathered. In percentage wise, 12.12% strongly disagree with the opinion that the higher the security controls on a software system, the lower the performance on the system would be. 30.30% disagreed with the notion, whiles 24.24% had a neutral opinion. On the part of 30.30% respondents, they agreed with the notion, whiles 3.03% strongly agreed. At the discussion section, the implications of these results shall be critically analyzed. 4.12 Stage to use functional requirement in system development During the literature review, the system development lifecycle was critically discussed. While doing this, two interesting schools of thought popped up. The first was the failure mode and effects analysis, which opted for a bottom-up approach to the use of the functional requirement in a system development process. The second was the fault tree analysis, which employed a top-down deductive approach. As a bottom-up approach, the failure mode and effects analysis recommends the inculcation of functional requirements at the early stages of system development whiles as a top-down approach, the fault tree analysis prefers the use of functional requirements at the concluding stage of the system development. Because of the variety in opinion, the respondents were asked to express their opinions if the absence of functional requirement during the early development process of a software system could lead to a software failure. The figure below represents their responses. Figure 4.2: Use of Functional Requirements at the Early Stage of System Development From the figure above, it can be realized that in consonance with the failure mode and effects analysis, 87.88% of the respondents believed that the functional requirements should be introduced at the early stage of the system development as a failure to do this could trigger a software failure. The remaining 12.12% however supported the fault tree analysis, opining that the absence of functional requirement during the early development process of a software system would not lead to a software failure. A clear reflection of the support of greater percentage of the respondents for the functional requirements to come at the early stage of the development was further revealed in the graph below when greater percentage of the respondents agreed that functional requirements should be identified at the early stages of software development. Fig 4.3 Functional Requirements at early stage of development 4.13 Need for Software Security awareness training During the review of related literature, the researcher found out from other researchers that the security aspect of functional requirements is a very complex and delicate component of software systems development. This is because much of the future functionality issues of the software demands on the level of security that the system possesses (Le Grand, 2006). To this end, there were two major debates among the various cultural environments that were under discussion. Whiles one group felt that security affairs should be left in the hands of some few IT skilled men within the organization, another group felt that security affairs should be the prerogative of all employees within the organization. From the first opinion holders, they contended that security is jeopardized the very moment it becomes controlled by many hands and so it was always necessary to ensure that only a few people could access security components of a system (Le Grand, 2006). On the part of the second group of opinion holders, the need for security assistance could be called upon at any moment in time during the functioning of the system (Office of the Director of Defence Research and Engineering, 1970). To this end, any available employee should be in a position to offer needed security assistance when the need came. A tie breaking moment was thus used with the questionnaire as the issue was raised for respondents to debate it. The figure below outlines the responses received. Fig 4.4: Training of Employees on Software Security Issues From figure 4.3, it can realized that as many as 96.67% of the respondents were of the opinion that organizations should provide a software security issues awareness-training program for their employees. These opinions were in relation to literature from Asian and European environments. The remaining 3.33% said there was no need for such training, conforming to the African and American cultural environments. On the fears that when greater number of the employee base has access to security training it could bring about security breaches, the figure below outlines the suggestions that respondents give to controlling such a situation. According to them, training should go with strict policy on security violations. From that question, 13.33% strongly disagreed with the statement that violation of an organization’s information security policies must be taken seriously but none of the respondents disagreed. 6.67% had neutral opinion while 36.67% agreed with 43.33% strongly agreeing. Fig. 4.5 Security policies against violations 4.14 Priority between safety and performance requirements In often cases, during the development of software systems, developers have wondered which of the two functional requirements to give priority, whether safety or performance. In the literature review, it was realized that most developers in Africa and Asia were more particular about performance as against safety. In effect, they would put performance ahead of safety in the development of software systems. However in the European and American contexts, the attention was on safety as against performance. In effect, most works of literature reviewed from these two cultural environments suggested that the priority on software system development should be on safety rather than performance as in their opinion, performance cannot be achieved when there is no guarantee on safety (Sans Institute, 2013). To draw a mid-point for the two sides of debate, the researcher posed a statement on the questionnaire that read “safety requirements should be observed before performance requirements when developing a software system”. The following responses were gathered from the respondents. Fig. 4.6 Priority for safety over performance From the figure above, it will be realized that the percentage of respondents who strongly disagreed with the statement was 0%. Those who disagreed were also 13.79% whiles another 13.79% held a neutral position. The modal score was 51.72%, agreeing to the statement with the remaining 20.69% strongly agreeing. It can be concluded therefore that in consonance with the American and European cultural environments, greater percentages believed that it was advantageous to safety requirements coming before performance requirements when developing a software system. In a closely related development, there were more respondents agreeing that security requirements should come before performance requirements. The responses given by these people is shown below with 10% strongly disagreeing, 3.33% disagreeing, 20% holding neutral opinion and 50% agreeing with the statement. The remaining 16.67% strongly agreed. Fig 4.7 Priority of security requirements over performance requirements 4.15 Software Safety Principles In relation to the responses given by the respondents on the need for there to be a training program for all employs on the non-functional requirements of software development, the researcher proceeded to ask them to spell out of some the specific software safety principles that an organisation should follow under the 19th question on the questionnaire. Generally, a number of very thought provoking and innovative contributions were made by the respondents. Some of the key software safety principles that were pointed out by the respondents have been labelled below: i. Definition of software role according to situation and job situation ii. That software should meet the principles of the software user iii. That only original software should be used iv. That there should be rigorous public client management of the software v. That there should be rigorous testing and all rigorous testing medthods must be followed. Despite the useful opinions expressed by some of the respondents above, what was noticed was that most of the respondents also gave out responses that touched on security principles instead of safety principles. Though not acceptable, the obvious reason that can be given to this situation is that most IT managers and for that matter IT customers are more accustomed to security principles as against safety principles and this is clearly revealed in the trend that was followed in answering question 22. Some of the unacceptable responses have been enumerated below i. Educating users on importance of security practices ii. Authorization/authentication of people who use the system, traceability, backup policy iii. Use of McAfee Software iv. Record the entry of any user and the time v. Use of Software Firewall, Anti virus, Network seq. 4.2 Why some participants did not to answer some questions The responses gathered from the questionnaire shows that it was not all questions that were answered by all respondents. In some cases, some of the key questions on the thematic areas that the researcher set in accordance with the research objectives and research questions were skipped by some respondents. Even though skipping some questions did not directly affect the validity of results in anyway, reasons behind the actions of these respondents must be clearly outlined. In the first place, it was realized that some questions were skipped because of differences in cultural environmental variables. That is, there were some variable within the questions that were not applicable to the cultural environments of the respondents. In relation to the literature review that was conducted, it would be noted that there were some approaches to safety, security and performance that were peculiar to certain cultural environments only. For example federal aviation regulations are used in the United States alone, whiles the defense summit is used by the people in the Asian continent alone. Therefore, asking questions on these approaches to someone who was not from either the United States or Asia would mean that the person would not be able to answer the questions. Another situation that the researcher observed was that some of the respondents felt that answering certain questions that bordered on the safety, security and performance of their companies would expose their outfits to public ridicule. 4.3 Why the majority of participants chose (Neutral) as an answer choice The questionnaire that was prepared for the respondents was made to contain several close ended questions. These close ended questions could be explained as questions on the questionnaire that requires that the respondents will select specific answers from a list of options given to them by the researcher (Oatey, 1999). For the questions that sought to collect opinions of respondents on the safety, security and performance of software systems pertaining to their cultural environments, the researcher used a likert scale in measuring the responses of the respondents. This means that the respondents were expected to rank their perception on safety, security and performance according to a scale, determined with the scales, strongly disagree, disagree, neutral, agree, and strongly agree. In any statistical analysis using statistical software, these responses could be graded using score such as 1, 2, 3, 4, and 5 respectively. One major realization that was made was that most of the respondents selected ‘neutral’ in their answers. One reason that can be assigned to this is that most respondents selected this response as a response of convenience for situations where they were not sure of the specific answers to select. From a statistical perception however, it will be noted that ‘neutral’ comes as a median answer, for which reason it is selected to show a sense of linear stability within the responses. 4.0 Findings and Discussion The literature review had three major thematic areas. In this section, the results gathered from the questionnaire and as analysed above are compared to the literature review to draw an empirical relationship between the primary and secondary data. 4.1 Perception and Importance different cultural environments attach to requirements of Software System From the theme given above in the literature review, it was realised that each of the four cultural environments that were examined had different degrees of importance and perceptions towards requirements of software system development. In general terms however, there were those who placed premium on safety and security over performance and those who place premium on performance over safety and security. There was enough evidence in the literature review that safety and security cannot be sacrificed ahead of performance because where there is performance without safety and security, IT employees cannot have sound mind to go about their duties (Sans Institute, 2013). Rightly so, the data collected from the questionnaire using questions 15 and 17 showed that there were several respondents who preferred that attention should be given to safety and security ahead of performance. The explanation for this trend of response by the respondents was reflected in question 18 where most of the respondents stressed that failure of software systems can lead to hazardous consequences. It will opined therefore that software system developers must not see performance as an end in itself but that they should always foster the achievement of safety and security as a means to the end. 4.2 Technical assessment and evaluation of non-functional requirements of software system As far as the literature review was concerned, the theme of technical assessment and evaluation of non-functional requirements of software was tested as a means of understanding the approach to functional and non-functional requirement inclusion in the software development lifecycle. Generally, the literature review pointed out that the use of failure modes and effects analysis (FEMA), which permitted developers to include functional requirements at the early stages of development, was more application with modern IT engineers as against the use of fault tree analysis (FTA), which preferred the issuance of functional requirements at the concluding parts of the development (Institute for Healthcare Improvement, 2013). In a much related manner, the questionnaire through questions 7to 10 pointed out majority of the respondents supported the position taken by the literature review. By implication, technical assessment and evaluation of the software system development process must be approached as a bottom-down technique, requiring for a stage-by-stage assessment and evaluation of the non-functional requirements. This way, defects and faults in the software system will be detected at an earlier convenience so that some of the systems hazards pointed out by the respondents in question 20 of the questionnaire will not be experienced. 4.3 Effect of Customer Perception on Software Development Lifecycle The literature review made a clear realisation that the customer is the end user of all software systems development. To this end, it is always important to factor the perception and opinion of the customer on the software development lifecycle in the development process. It was therefore realised though the review that at each stage of the software development lifecycle, there are some key roles that the customer can play. In relation to the primary data collection, the customers used were various people with background and training in IT. From the 1st to 5th questions on the questionnaire, the technical expertise and nationalities of these customers are clearly defined. Judging from the various levels of input that these respondents made to the study by answering the questions on the questionnaire, it is very evident that at each level of development, the customers hold a key role and can have varying inputs that contribute to the success of the software development lifecycle. From questions 21 to 23, what is particularly interesting in this discussion is that the customer would want to see an effect of non-functional requirements that puts premium on security, followed by safety, and them performance. The fact that in each column of the three non-functional requirements a good number of respondents made selections means that none of the three components should be neglected but there should be an integration methodology that ensures that each of them gains the level of importance needed to make the software system complete. The fact that most respondents gave security principles when asked about safety principles in question 19 also confirms the level of importance that they attach to security of software. 5.0 Conclusion and Further Work. 5.1 Conclusion The results that have been collected through the literature review and the use of questionnaire can make the researcher draw a number of conclusions on the perception of customers from different cultural environments on the safety, security and performance of software systems. First and foremost, on the issue of perception of different customers from different cultural environments on safety, security and performance requirements in software systems, it can be concluded that the major line of differences that exists in terms of perceptions take place on a continental basis, with each continent having its own line of perception. Regarding the issue of importance that customers from different cultural environments attach to each of the listed requirements of software system, the researcher can conclude that Europe and Asia attach much importance to the listed requirements as against America and Africa. However, the America level of importance could be explained as being more proactive than that which exists in Africa. From the research questions also, there was the question of whether or not customers from different cultural environments perceive and evaluate the stated requirements differently. From the answers gathered from the questionnaire, the simple answer that can be given to this question is yes, there are differences in the evaluation of the stated requirements namely safety, security, performance. There was also the question of effect of customer perception on the success of a system development process project. The conclusion that can be drawn on this theme is that the degree of importance that the customers within the cultural environment attach to the requirements forces the developers of software systems to put in much priority in the development process of an IT project. 5.2 Limitations and suggestions for further research Even though the methodologies used by the researcher has been praised as being very effective in bringing about the collection of core data to understand the differences in cultural perceptions that people from different environment, there were a number of challenges and limitations that the researcher faced in order to achieve this. The first of these has to do with the availability of relevant and related works of literature that contained as sufficient information as the researcher needed for all the cultural environments he was dealing with. Because the researcher did not have the means to travel from one continent to another to access literary materials, he had to intensify his search to ensure that within a very small locality, he could get reference materials from all the major cultural environments that were used for the study. Virtually the same kind of problem was faced with the primary data collection as the researcher found it extremely challenging, constituting a sample size that will be made up of people from all the identified cultural environments. The only way to make this realization work was for the researcher to use a very large population for the study so that the possibility of having a representative from each of the cultural environments will be possible. Finally, the need to deal with a very large database within a short stipulated time for the entire research to be completed put a lot of pressure on the researcher. It is therefore suggested for further research that future researchers will use a case study instead of a survey because case study present them with relatively smaller database to deal with. REFERENCE LIST Institute for Healthcare Improvement (2013) Failure Modes and Effects Analysis (FMEA) Tool [Online] http://www.ihi.org/knowledge/Pages/Tools/FailureModesandEffectsAnalysisTool.aspx [Accessed: 24th August, 2013] Kajornboon A. B (2005) Using interviews as research instruments [Online] Available from http://www.culi.chula.ac.th/e-journal/bod/annabel.pdf [Accessed: 25th August 2013] Kimberly A. G. (2009) Qualitative, Quantitative and Mixed Methods Approaches to Research and Inquiry. [Online] Available from http://spahp2.creighton.edu/OfficeOfResearch/share/sharedfiles/UserFiles/file/Galt_SPAHP_Methods_Presentation_082609.pdf [Accessed: 24th August, 2013] Le Grand C. H. (2006) Establishing Controls for Software Security Assurance. [Online] Available from http://www.theiia.org/intAuditor/itaudit/archives/2006/may/establishing-controls-for-software-security-assurance/ [Accessed: 25th August, 2013] Oatey A. (1999) The Strengths and Limitations of Interviews as a Research Technique for Studying Television Viewers. [Online] Available from http://www.aber.ac.uk/media/Students/aeo9702.html [Accessed: 23rd August, 2013] Office of the Director of Defence Research and Engineering (1970) Security Controls for Computer Systems. [Online] Available from http://csrc.nist.gov/publications/history/ware70.pdf [Accessed: 25th August, 2013] Practitioner Research and Evaluation Skills Training (2004) Mixed Research Methods. [On line] Available from http://www.col.org/SiteCollectionDocuments/A5.pdf [Accessed: 24th August, 2013] Sans Institute (2013) Critical Control 6: Application Software Security. [Online] Available from http://www.sans.org/critical-security-controls/control.php?id=6 [Accessed: 23rd August, 2013] Read More