Human Factors and Social Aspects in Software Engineering - Case Study Example

Human Factors and Social Aspects in Software Engineering al Affiliation: Contents Contents 2 Factors and Social Aspects inSoftware Engineering 3 A. Human Factors 3 1. Program comprehension 3 2. Trust 6 3. Knowledge management (KM) 6 4. Culture 7 B. Social Aspects 7 (i) Coordination and collaboration 7 (ii) Community-based 8 (iii) Social inclusion 8 References 10 Factors and Social Aspects in Software Engineering Evidently, the development and the subsequent advancement of technology have seen many of the daily tasks carried out by humans become quite easier. In simple terms, software engineering refers to the process of developing software with an aim of making them more efficient, reliable, affordable and easy to maintain while meeting the customers’ expectations. While one could view software engineering as an issue solely left for the engineers, surprisingly, the humans do influence how it is developed. In light of the definition offered, it is easier to see why humans play a pivotal role in the software engineering. Previously, some software experts have spent a considerable amount of time and resources in making software only for the customers to find them unhelpful. Besides the human factors, software engineering has to consider social aspects too in their work. Since it is not always easier for the engineers to clearly understand all these factors and social aspects, this paper will serve the onus of highlighting them accordingly. A. Human Factors 1. Program comprehension Often, humans are faced with an enormous challenge of comprehending the functioning, benefits and the limitations of the software. Consequently, other issues rise just because there lacked coordination between the engineers and the humans (Capretz, 2014). Obviously, not every human possesses software engineering savvy meaning even the most basic features may seem paradoxical to many people. Therefore, it would be critical that engineers consider the same while developing these applications. The following part will focus on other issues that could be catalyzed by lack of program comprehension. (a) Perspective Perhaps, human perspective could be listed as the top most human issue in the study of software engineering. At times, engineers have to grapple with the consumer perception of particular software especially if its original purpose is not achieved. According to Hazzan (2012), consumer perception is mostly influenced when the expectation is not met as was previously thought. For instance, if certain software were developed to help a client solve mathematical problems but suddenly fails, it could have adverse effects on the consumer’s confidence. Additionally, if another was designed to guarantee to provide security but is prone to easy manipulation from unauthorized users, consumers will start changing perceptions. It, therefore, goes back to the issue of program comprehension since one understands often shapes perceptions. (b) Security Normally, security is one of the reasons perception influences software engineering with dissatisfaction following suit. Capretz (2014) found out that if engineers fail first to understand the need software, it could end up becoming less helpful to many people. Capretz and Ahmed (2010) recommend that in order to ensure maximum security of software, it is advisable to look at it as vulnerable. That is to say despite having applied all tactics to ensure its security; other loopholes ought to be extensively addressed before it is launched to consumers. Upon this assessment, availing a disclaimer to the clients that the system is not impervious would help many people in understanding the software world. (c) Privacy At a time when hacking has hit a new level, one major concern of every software engineer is whether clients will feel safe using them. Clients want to know if anyone will have unauthorized access to their files and other documents. Recently, there have been a series of hacking whereby several individuals’ personal documents including photographs were exposed on the internet. Privacy is a major human factor in software engineering as it determines just how well the client will interact with. While the client may not simply do away with the software, the originally intended interaction will not exist where privacy is not assured. In such situations, it becomes very hard to convince these clients that their privacy is guaranteed (Capretz, 2014) (d) Personality Humans tend to have preferences, which normally cause a challenge to engineers since it is not possible to understand and meet each person’s. However, there seems to be a remedy as suggested by Capretz and Ahmed (2010) who stated that failure by engineers to employ a diversity has been detrimental in software engineering. Further, it is argued that since the society views issues differently, it is imperative to have different individuals undertaking various tasks during the process of software engineering. These two continue to assert that due to engineers’ continued assumption of diverse skills, the society at times tend to reject even a software which could have otherwise proved vital. Expert recommendation would go a long way in dealing with this issue since many are just influenced merely by their likes (Hazzan, 2012). In addition to these assertions, others hold the view that psychological approaches ought to be applied in this process by the engineers. Ergonomics has previously been used in trying to understand the various preferences of consumers in this sector. While it is conceded that it is obviously not possible to have all preferences incorporated, Hazzan (2012) recommends teamwork. In short, other individuals with differing preferences could be grouped together in a bid to come up with the best product. This way, there is a sense of social representation since many of the preferences are a direct result of temperamental attributes. Therefore, when different engineers work on a particular project, their views are imperative in creating socially acceptable product as opposed to using persons with similar views. 2. Trust Human factors concerning software engineering cannot be exhausted before trust is mentioned as another major one. In essence, this one implies that consumers must be able to trust the software in various aspects. One, the clients want to make sure the software can do exactly that which it was originally designed for without errors, limitations or inefficiencies. It is common knowledge that software are normally designed to interact with clients in easing their computer-related chores. Two, the client need an assurance that the software is not compromising their records to a third party or pretty prone to outside attacks (Capretz, & Ahmed, 2010). By understanding this, engineers are able to design products that will ensure client’s concerns are well addressed. 3. Knowledge management (KM) Engineers may at times develop applications that may be below standards or are not in full compliance of regulations. Others may be hard to upgrade and other challenges thus leaving the consumers with nothing but constant complaints. Whenever such happens, it is not only the credibility of the engineers that will be at risk but also the society may never have trust in any other program. Lenberg (2013) stated that KM could prove to be efficient by “increasing the re-use of development experience, products, and processes and creating a communication layer between developers and end-users” (p.189). 4. Culture So far, one thing, this paper has sought to cement, is that software engineering is a human-centered activity meaning whatever engineers come up with will have some impact on the former. Even though these experts do not necessarily need to make applications that could be described as culturally acceptable, these act as guidelines. (Capretz, 2014) found out that if engineers opt to overlook cultural impact of particular software there could be a misunderstanding that could ultimately see the specialists lose their many days of unfathomable labor. B. Social Aspects As stated earlier, human factors have to be considered in the software engineering study because there will be an interaction. Again, it was earlier stated that engineers might not necessarily meet consumer needs individually hence, the need to apply the social aspect approach. In order to do this, these specialists tend to analyze various areas that will be the focus of this section. (i) Coordination and collaboration Firstly, coordination and collaboration are vitally important in the development process. By ensuring all the relevant parties are adequately represented and consulted in this process, it makes the final product devoid of unnecessary criticism (De Souza, Sharp & Dittrich, 2009). Earlier in the human factors part, the findings indicated that some of these issues might end up rendering the entire project ineffective. However, that could be avoided if engineers focused on the social aspects especially collaboration. In essence, that is to mean consultation is imperative if there is any chance of success and avoidance of backlash. (ii) Community-based One grave mistake often made by some engineers is developing software focused more on individuals than the society as a whole. Consequently, there arises dissatisfaction and subsequent disconnect between the society and the engineers especially when the issue is widespread (Capretz, 2014). In order to alleviate this risk, engineers ought to appreciate the fact that software are designed solely for the purpose of offering support to humans in their activities. Moreover, software’s are used in solving collective social problems more than in individual cases hence the need to address the higher population. (iii) Social inclusion It is pretty obvious that there would be no need for software if humans did not need them thus the need to maintain a link between the two. To achieve this, the engineers ought to ensure that the above aspects and factors are considered. It is not possible to link a society with software if there is no understanding of its culture, preferences, perceptions and so forth (Lenberg, 2013). Sharing these sentiments is De Souza et al (2009) who stated that there would always be a gap between engineers’ arena and the society if the former fails devise ways to ensure inclusion. In summary, the human factors and the social aspects in software engineering are critical and have to be considered by the relevant stakeholders. Humans border engineers and their work meaning it is not possible to bypass this fact. Worth noting that engineers need not wear themselves out in trying to understand the individual preferences. Instead, focusing on these factors listed above will be helpful since it is not realistically possible to meet everyone’s needs. Generally, humans would want safe, reliable, effective and pleasant applications that greatly assist them in their tasks. Understanding this will help the specialists in creatively designing products with a number of varieties for people with different preferences to choose from. This can be easily achieved by applying the various aforementioned aspects including social inclusion and collaboration. That is to say, there ought to be communication when developing these programs. References Capretz, L., & Ahmed, F. (2010). Why do we need personality diversity in software engineering? ACM SIGSOFT Software Engineering Notes, 35(2), 1-5. Capretz, L. (2014). Bringing the Human Factor to Software Engineering. IEEE Software, 23(2), 104-104. Cherry, S., & Robillard, P. (2013). The social side of software engineering—A real ad hoc collaboration network. International Journal of Human-Computer Studies, 69(6), 405 De Souza, C., Sharp, H., & Dittrich, Y. (2009). Cooperative and human aspects of software engineering (CHASE 2009). IEEE Computer Society, 29(2), 234-236. Hazzan, O. (2012). Cognitive and social aspects of software engineering: A course framework. ACM SIGCSE Bulletin, 40(4), 201-201. Lenberg, P. (2013). Human factors in software development: On its underlying theories and the value of learning from related disciplines. Information and Software Technology, 28(7), 188-189 Read More