تنش در اطراف پذیرش و تکامل نرم افزار سیستم های مدیریت کیفیت: یک رویکرد تحلیلی به گفتمان

This paper reports some results from a project to uncover the non-technical factors that affect the adoption and evolution of software quality management systems (SQMS). The data which the paper discusses comes from interviews with people involved in the quality effort in four different companies. Our approach to data collection was to use semi-structured interviews and to encourage interviewees to talk about their experiences of quality management and software development in their own organizations. We analysed this data using discourse analysis, informed by ethnographic observation, and identified a number of themes, one of which was the tensions that exist around the adoption and evolution of SQMS. In this paper, we present and discuss our approach to discourse analysis and some results that illustrate the tensions we found. We hope, thereby, to demonstrate how software engineers may use a technique from the social sciences to better understand their own practices.

This paper describes the collection and analysis of qualitative empirical data to investigate the non-technical factors influencing the adoption and evolution of software quality management systems (SQMSs). We collected a variety of data through our project, but in this paper we concentrate on data from semi-structured interviews conducted with quality managers. The importance of non-technical factors in the success of software engineering projects has been recognized for many years (e.g. DeMarco and Lister, 1987; Curtis et al., 1988). Few empirical studies have been reported that look at the impact of non-technical factors on software development practices, although work in the area is growing (e.g. Baddoo and Hall, 2002b) and the significance of studying the human aspects of software engineering through qualitative methods is receiving more attention (e.g. Seaman, 1999; Seaman and Basili, 1998). We began our project because of our concerns that technical innovations did not appear to be producing better quality software systems. Our particular focus was on the effect of quality initiatives such as ISO9000 certification schemes, and the social factors affecting the success, adoption and evolution of SQMSs in response to those schemes (Hall et al., 1993; Hovenden et al., 1994; Sharp et al., 1999). In the remainder of this introductory section, we provide some background on SQMSs, and the wider project of which this work forms a part. In the next section, we introduce the methods used for data collection and analysis. Then in Section 3, we present the results of discourse analysis that led to our focus on the tensions around the adoption and evolution of SQMSs. This section includes example discourses from our data that illustrate the tensions we found, where these tensions occurred and where they did not occur. In Section 4 we discuss our results in the context of other relevant work. Finally, we share some observations about the use of discourse analysis in this context. 1.1. Sofware quality management systems An SQMS is intended to make the process of software development visible and public. This is partly about accountability, but, more pragmatically, makes knowledge (especially that relating to the practice of developing software) communal, minimizing the problems arising when team members are away, or have left. It also helps to make the process visible to those who have not been involved in the development, such as senior managers, auditors and customers. An SQMS makes the process auditable because it provides guidelines, or benchmarks which can be tested against, and it provides some assurance of adherence to house style. This fulfills a range of requirements, including indicating to customers that certain standards are being met, and strengthening a market image by ‘branding’ through conformance to certain standards. Hence, the introduction of an SQMS can reinforce management control as well as enforce internationally established guidelines. The following are quoted from (ISO8402, 1994) which provides internationally standardized definitions of quality terms. • Quality: the totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs. • Quality policy: the overall quality intentions and direction of an organisation as regards quality, as formally expressed by top management. • Quality management: that aspect of overall management function that determines and implements quality policy. • Quality system: the organizational structure, responsibilities, procedures, processes and resources for implementing quality management. This set of definitions have arisen from a desire to have organizational and managerial forms of quality management, following on from the works of gurus, such as Deming (1982), Juran (1988) and Crosby (1979). This movement in turn led to certification schemes such as BS5750 (1987) and ISO9000, (also known as ISO EN BS 9000). Other, more explicit models have also been developed, such as the Capability Maturity Model (Paulk et al., 1997) and later the People CMM (Curtis et al., 2002) and CMMI, SPICE (El Emam, 1997) and total quality management (Oakland, 1994). 1.2. The SoFEA project The SoFEA project aimed to identify non-technical factors influencing the adoption and evolution of quality management systems. It began in 1993 when we raised issues regarding SQMSs and sought stories from attendees at a conference on software quality. From this initial contact, we collaborated with five companies to explore the issues further. In each case, we interviewed the initial contact. Further involvement with the organization varied, depending on the opportunities that presented themselves. In one case, this led to a 1-week ethnographic study which included participant observation. The project has looked specifically at the introduction of SQMSs in the context of certification to standards such as ISO9000 (2000). We have used qualitative data collection and analysis. Our analyses so far have underlined the importance of involving influential developers in the production of the SQMS (Hovenden et al., 1996), discussed observations on the effect an organization's culture may have on attitudes to software quality (Sharp et al., 1999), and presented some reflections on the implications for software engineers of our interdisciplinary approach (Sharp et al., 2000).

In this paper, we have reported some results emerging from a study of the non-technical factors affecting SQMSs focusing on the existence of tensions around their adoption and evolution. These results were achieved using discourse analysis supported by an ethnographic stance, an approach that we believe is novel in understanding software practice. We conclude by reflecting on our use of discourse analysis, the results we have described and further development of these ideas. 5.1. Reflections on our use of discourse analysis Software engineers and computer scientists are trained to be systematic and explicit in all aspects of what they do, for example, in eliciting requirements for software-based systems. They are taught to eschew uncertainty and vagueness, to search for and remove omissions and ambiguity. The use of discourse analysis and the interpretation of its findings therefore present a challenge to software engineers and computer scientists whose training is for dealing with explicit facts and opinion rather than tacit knowledge. In reflecting on our use of this technique, three aspects of the application of discourse analysis that struck us as particularly challenging were. Seeing beneath the explicit facts to find the hidden knowledge and meaning. A straightforward reading of interview transcripts will reveal explicit facts and opinions. However it will not yield implicit knowledge and meaning. Yet, the explicit and the implicit complement each other and allow us to build up a more complete picture. We were therefore determined to identify both and we used discourse analysis to reveal this implicit knowledge and meaning. The way someone expresses themselves can reveal a lot about them and their (professional) world. This was a real benefit of using discourse analysis: it allowed us to uncover tacit information. However, as software engineers who are far more used to collecting, analysing, interpreting and using the explicit, it was difficult to see the implicit because it was so much easier to focus on the explicit. Avoiding judgement. Following the ethnographic tradition, we strove to maintain a non-judgemental position and treated everything as ‘strange’, throughout the study and subsequent analysis. This meant pretending to ourselves that we did not understand much about software development or quality initiatives—except to the extent we could have a real conversation and begin analysis with a minimum of assumptions. This helped to reinforce the view that our interviewee was always the expert, but there was a balance to be struck between knowing nothing and knowing enough for our interviewees to feel that they could talk knowledgeably to us. From our experience we believe that this approach allowed our collaborators to express their own viewpoints more fully, and this therefore allowed us to gain a better perspective. We found that maintaining a non-judgmental stance was not always easy, and particularly in discussions of the data, we often had to keep each other in check. Communicating our findings. Our collaborators had expected us to be judgmental and comparative. They wanted us to be experts, consultants. They regarded us as ‘one of them’ because we shared a common background, being software engineers with knowledge of quality management issues. This allowed us to enter into informed discussion with them, but our observations needed to remain impartial, and our ability to enter into such discussion may have led them into thinking that we would provide different feedback. They did not, however, feel that they had been misled as to the nature of our study. 5.2. Recommendations for avoiding tensions In this paper, we have presented some factors affecting the adoption and evolution of SQMSs in four companies. Through our use of discourse analysis, we have found that tensions exist around this process. By comparing companies that do and those that do not experience them, we are able to suggest ways in which the tensions may be alleviated or avoided. • The need for a quality manual, and for quality initiatives, should be clearly explained to all staff. • Staff who have to implement the procedures should be encouraged to write them. • The manual itself should include explanation and varying levels of insistence; it should not be entirely prescriptive. • The manual should be flexible and allow decisions to be taken ‘on the ground’. • The company's commitment to quality should be visible and maintained. 5.3. Future directions We have used discourse analysis and ethnographically-informed techniques in other related research, for example, in understanding the impact of constituencies and communities in the development of technical ideas (Sharp et al., 2000), and in studying the culture of agile methods in software development (Robinson and Sharp, 2004). Using such techniques has contributed to our understanding of software engineering and how it is practiced. We intend to continue this work, and are currently focusing on the use of metaphor as a complementary analysis tool.