Journal of Software Engineering Research and Development, 2021, 9:13, doi: 10.5753/jserd.2021.1942 This work is licensed under a Creative Commons Attribution 4.0 International License. Towards to Transfer the Directives of Communica- bility to Software Projects: Qualitative Studies Adriana Lopes Damian [ Federal University of Amazonas | adriana@icomp.ufam.edu.br] Edna Dias Canedo [ University of Brasília | ednacanedo@unb.br] Clarisse Sieckenius de Souza [ Pontifical Catholic University of Rio de Janeiro | clarisse@inf.puc-rio.br] Tayana Conte [ Federal University of Amazonas | tayana@icomp.ufam.edu.br] Abstract The software artifacts developed in the early stages of the development process describe the proposed solutions for the software. For this reason, these artifacts are commonly used to support communication among members of the development team. Miscommunication through software artifacts occurs because practitioners typically focus on their modeling, without reflecting on how other software development team members interpret them. In this context, we proposed the Directives of Communicability (DCs) to support practitioners analyzing characteristics that affect the artifact’s content on communication via artifact. We conducted preliminary studies in a controlled environment with our proposal. However, we noticed that new studies are necessary to evaluate the DCs concern- ing practitioners’ perceptions before transferring them to the industry. In this paper, we present two studies per- formed aiming to transfer the DCs to the software industry. In the first study, we evaluated the practitioners ’ perception about the DCs. In the second study, we evaluated the feasibility of the DCs in a software developmen t team. The studies’ results indicated that DCs have the potential to support improvements in artifacts’ content to reduce miscommunication via artifact. To facilitate the use of our proposal in the software industry, we created procedures that support the adoption of the DCs and checklists for the application of each directive in the software artifacts. We noticed positive perceptions of practitioners about the application of DCs in software artifacts. We hope that our contribution support software development teams that use artifacts in your projects. Keywords: Communication via Software Artifacts, Human‑Centered Computing, Semiotic Engineering 1 Introduction Artifa cts developed in the ea rly sta ges of the softwa re devel- opment process, such a s the different dia gra ms of the Unified Modeling La ngua ge (UML) (Freire et a l., 2 018; OMG, 2015), a ssist pra ctitioners in understa nding the problem for which softwa re wa s required. As proposed solutions for soft- wa re development a re in a rtifa cts, these a rtifa cts a lso support tea m communication (Petre, 2013). Communica tion is considered a n importa nt fa ctor in soft- wa re development, since miscommunica tion in software tea ms ca uses low productivity a nd softwa re fa ilures (Kä fer, 2017). Miscommunica tion via a rtifa ct occurs, for exa mple, when consumers (who ta ke the informa tion they see in the models for the development of a nother a rtifa ct) ha ve differ- ent interpreta tions from the ones intended by the producers (who conceive the modeling of the softwa re). As much as consumers know the modeling nota tion, the wa y the model- ing ha s been expressed by their producer ca n a ffect these pra ctitioners’ mutua l understa nding. In order to mitiga te miscommunica tion via a rtifa ct, we proposed the Directives of Communica bility 1 (DCs), pre- sented in Lopes et a l. (2019a ). The DCs ca n support reflec- tions to producers a bout how they ca n crea te a softwa re so- lution via a rtifa cts a imed to get a mutua l understa nding a mong development tea m members. 1 Communicability in this context refers to the artifact’s ability to convey to its consumers the solution conceived by its producers. Pra ctitioners ca n use our proposa l ma inly in the a rtifacts developed in the initia l sta ges of the development process, such a s UML dia gra ms, mockups a nd others. We conducted prelimina ry studies to eva lua te our proposa l to reduce mis- communica tion (Lopes et a l., 2019a ; Lopes et a l., 2019b). However, we noticed tha t new studies a re necessa ry to eva l- ua te the DCs concerning pra ctitioners’ perceptions before tra nsferring them to the industry. Given the context a bove, we conducted a n explora tory study (Lopes et a l., 2020) to eva lua te pra ctitioners’ percep- tions of the DCs. Fifteen pra ctitioners pa rticipa ted in this study by modeling UML use ca se (OMG, 2015) with the support of DCs. The results demonstra ted that the UML use ca ses developed, with the support of DCs, ha d few risks of miscommunica tion. Besides, pa rticipa nts’ perceptions a bout the DCs indica te tha t such directives ca n support bet- ter communica tion via a rtifa ct, contributing to software qua lity. However, it is a lso importa nt to eva lua te how soft- wa re engineers a pply the DCs in a rtifa cts used in software projects to identify their fea sibility. This pa per extends our previous work (Lopes et a l., 2020), presenting a study ca rried out to a na lyze communica tion via a rtifa cts in a softwa re development team. We conducted this study in a softwa re tea m with fourteen pra ctitioners that worked on a coopera tion project between the University of Bra silia (UnB) a nd the Bra zilia n Army. The results of this study showed the potentia l of the DCs to indica te improve- ments in the a rtifa ct’s content rega rds communica tion via Towards to Transfer the Directives of Communicability to Software Projects: Qualitative Studies Lopes et al. 2021 a rtifa cts. In a ddition, we present proposa ls tha t fa cilitate pra ctitioners to a dopt the DCs, such a s procedures tha t direct the a doption of the DCs in softwa re a rtifa cts a nd checklists tha t support the employ of ea ch directive in common sce- na rios of two specific a rtifa cts. Through both studies, we noticed the contribution of the DCs for: (i) few risks of miscommunica tion via a rtifa cts, a l- lowing better communica tion via a rtifa ct ; a nd (ii) improve- ments on the qua lity of a rtifa cts, since miscommunication ca used incorrect informa tion in softwa re a rtifa cts. We hope tha t our contribution helps softwa re development tea ms re- duce miscommunica tion via a rtifa cts. 2 Theoretical Foundations and Related Works This section begins by presenting both the Semiotic En- gineering theory (de Souza , 2005; de Souza et a l., 2016) and the Grice Coopera tion Principle (Grice, 1 975), which we used to understa nd communica tion via a rtifacts a nd to pro- pose the DCs. Additiona lly, we present rela ted works to this type of communica tion. 2.1 Theoretical Foundations Semiotic Engineering theory (de Souza , 2005; de Souza et a l., 2016) cha ra cterizes user-system intera ction a s a pa r- ticula r ca se of huma n-media ted systems communica tion. Systems a re considered metacommunication a rtifa cts in Se- miotic Engineering, i.e., a rtifa cts tha t communica te a mes- sa ge from the designer to users a bout h ow they ca n or should communica te with the system to do wha t they wa nt. The con- tent of the metacommunication messa ge, or metamessage, ca n be pa ra phrased in the following templa te: “Here is my understanding of who you are, what I’ve learned you want or need to do, in which preferred ways, and why. This is the system that I have therefore designed for you, and this is the way you can or should use it in order to fulfill a range of purposes that fall within this vision”. Semiotic Engineering uses the communica tion space model proposed by Ja kobson (1960), tha t is structured in terms of context, sender, receiver, messa ge, code, a nd cha n- nel, where: “A sender transmits a message to a receiver through a channel. The message is expressed in code and refers to a context”. Ba sed on the communica tion space model proposed by Ja kobson (1960), we ca n structure the communica tion elements via a rtifa ct in terms of the problem doma in (context), how the a rtifa ct is a va ila ble (cha nnel), in- forma tiona l a rtifact’s content (messa ge) composed of the a r- tifa ct’s nota tions (code) for the communica tion between the producer (sender) a nd consumer (receiver) of a n a rtifa ct, where: “A producer transmits the informational content of the artifact to a consumer through a channel. Informational content of the artifact is expressed by the artifact’s notations and refers to the problem domain ”. Figure 1 presents a cha r- a cteriza tion of these elements. Semiotic Engineering proposed eva lu a tion methods to support designer-user communica tion in order to understand how the user is being receives the meta messa ge. The princi- ple of ca tegoriza tion of communication failures presented by Semiotic Engineering is rela ted to three ca tegories: Figure 1. Communication space of Jakobson (1960). • Complete failures - when the intention of the commu- nication and its effect are inconsistent; • Partial failures - when part of the intended effect of the communication is not reached; and • Temporary failures - when in the intention of a com- municative act between user and system, the user has momentary difficulty to continue talking with the sys- tem. Semiotic Engineering extended its origina l perspective to a Huma n-Centered Computing perspective, a resea rch field tha t a ims to understa nd huma n beha vior by integra ting tech- nologies in socia l a nd cultura l contexts (Sebe, 2010). This contribution is rela ted to the set of conceptua l a nd methodo- logica l tools ca lled SigniFYI (Signs For Your Interpreta tion) (de Souza et a l., 2016). The SigniFYI Suite helps investiga te mea nings in softwa re during the development process and the communica tion between softwa re producers a nd con- sumers. Among them, the SigniFYI Messa ge tool (SFYI Messa ge) is the opera tiona l version of the meta communica- tion templa te. This opera tiona l version proposes tha t it can sta nd on its own a s a powerful eva lua tion resource to identify communica bility issues (which refers to the qua lity of the tra nsmission of the solution designed by producers to con- sumers). De Souza et a l. (2016) report the use of a principle of reciproca l coopera tion rela ted to effective a nd efficient com- munica tion, ca lled Grice’s Coopera tive Principle (Grice , 1975). This principle is expressed by four ma xims. Brea king one or more of these ma xims ma y lea d to a communication fa ilure. Grice’s four ma xims a re: Quality - try to ma ke your contribution a true one. Do not sa y wha t you believe to be fa lse a nd do not sa y something without a dequate evidence. In softwa re development, for ex- a mple, the softwa re engineer must communica te to the team only informa tion tha t is rela ted to the problem doma in. Quantity - Make your contribution as informative as is required. Do not make you contribution more informative than is required. Following the previous exa mple, when Towards to Transfer the Directives of Communicability to Software Projects: Qualitative Studies Lopes et al. 2021 communica ting to the tea m, the softwa re engineer must try to use only sufficient content to cla rify the informa tion they must develop. Relation – Be releva nt, tha t is, do not introduce points tha t do not come under discussion. In the ca se of systems developed in different cycles, ea ch cycle must conta in only informa tion releva nt to such development. Manner - be perspicuous, a voiding obscurity of exp res- sion a nd a mbiguity, be brief a nd be orderly . The software engineer must use descriptions tha t the tea m ea sily inter- prets, a voiding a mbiguity. 2.2 Related Works For the communica tion to be efficient, the sender must ca re- fully choose a n expression for th e content he wishes to com- munica te, using a code tha t the receiver is a ble to interpret (de Souza , 2005; de Souza et a l., 2016). In this sense, we identified works rela ted to a rtifa cts’ comprehensibility, which refers to the receiver’s interpreta tion of wha t the sender sa id in his communica tive a ct. On communica tion via a rtifa ct, Bordin a nd De Angeli (2016) point out tha t softwa re engineers sta ted tha t docu- menta tion keeps a softwa re development team a ligned, espe- cia lly in scena rios of distributed tea ms or with the introduc- tion of new members in the tea m. Schoonewille et a l. (2011) present a contribution rela ted to cognitive a spects in the understa nding of softwa re design documenta tion. They investiga ted, in one study, the pa rtici- pa nts' a bility to extra ct inf orma tion from dia gra ms a nd texts (gra mma tica lly a nd synta ctica lly correct). The a uthors no- ticed tha t self-a ssessment could be problema tic. They ob- served tha t developers were sa tisfied to “fill in” informa tion missing from the documenta tion without the sa me under- sta nding a s the documenta tion producers. This ca n ca use in- correct interpreta tions rega rding the softwa re. Na ka mura et a l. (2011) proposed three metrics rela ted to the comprehensibility of UML cla ss dia gra ms in the follow- ing a spects: (1) cla ss structure, (2) pa cka ge structure a nd (3) a ttributes a nd opera tions. The a uthors cla im tha t the metrics help in estima ting the cost of time for understa nding a cla ss dia gra m. Cruz-Lemus et a l. (2010) present a predictive model of comprehensibility for UML sta te ma chine dia gra ms, a na lyz- ing its structura l complexity. The a uthors’ goa l wa s to reduce the impa ct of understa nding this dia gra m. Tilley (2009) presents a work tha t summa rizes 15 years of resea rch on the use of gra phica l nota tion a s documentation for understa nding the system. According to the a uthor, the gra phica l nota tion ca n help to understa nd the system and support com munica tion. However, technica l ‘communica- tors’ a re not usua lly involved in this process. Still, a ccording to the a uthor, the result is tha t the engineers, who ha ve the best of intentions, do not ha ve the necessa ry ba ckground to explore the resources of the gra phic nota tion to support end users’ ta sks. Therefore, the a uthor reports a lesson lea rned: “we need to know how to ta lk”. Theref ore, this highlights the importa nce of the producer thinking a bout the consumers. La nge a nd Cha udron (2006) present a work tha t investi- ga ted the effects of defects in UML dia gra ms in rela tion to different interpreta tions. They conducted two controlled ex- periments with a la rge group of students a nd pra ctitioners. The two ma in contributions of this work a re investiga tions on defect detection a nd different interpreta tions ca used by undetected defects. The a uthors sta te that the results a re gen- era liza ble for modeling with UML dia gra ms. These works dea l with topics rela ted to communication with the support of a rtifa cts developed in the ea rly sta ges of softwa re development. Schoonewille et a l. (2011) a nd Tilley (2009) show the importa nce of a rtifa ct producers to reflect on consumers. Thus, it is importa nt to ha ve a proposa l for a rtifa cts producers to reflect on the consumers. The contri- butions of the DCs ca n help with this, a s their goa l is to sup- port communica tion via a rtifa ct. This ca n be a chieved when pra ctitioners ma ke improvements to the a rtifa cts to obtain a mutua l understa nding of tea m members. 3 Directives of Communicability For the DCs proposa l, we ha ve a ppropria ted the communi- ca tion spa ce of Ja kobson (1960) to communica tion via a rti- fa ct, a s follows: the a rtifa ct is ma de a vaila ble with the sup- port of a tool (the cha nnel) with informa tion from the prob- lem doma in (context) to support communica tion between ar- tifa cts producers (the emitters) a nd consumers (the receiv- ers). The producer, in his messa ge, must con sider how the content is expressed (the use of the code) in such a rtifa cts. Figure 2 shows such a ppropria tion . Figure 2. Appropriation of the communication space of Jakobson (1960) for communication via artifact. Besides, we ha ve a ppropria ted of Semiotic Engineering to define the following concepts rela ted to communication via a rtifa ct: • Communicability of software artifacts - refers to the a rtifa ct’s a bility to tra nsmit to its consumers the proposed solutions for softwa re development. • Communicability issues in software artifacts – refers to the expressions or fea tures of the a rtifa ct tha t can be directly a ssocia ted with a n incompa tibility between mea nings a ssocia ted to them by their producers and consumers. • Risks of miscommunication via artifacts – the Towards to Transfer the Directives of Communicability to Software Projects: Qualitative Studies Lopes et al. 2021 likelihood of a communica bility issue to ca use communica tion fa ilures between producers and consumers. • Miscommunication via artifacts – incompa tible interpreta tions by a rtifa cts consumers from the producer perspective for softwa re modeling. 3.1 Proposal of the DCs We ela bora ted the DCs ba sed on Semiotic Engineering (de Souza , 2005; de Souza et a l., 2016) a nd Grice’s Coopera tive Principle (Grice, 1975). We a da pted the origina l Semiotic Engineering metacommunication templa te a s follows: “Here is my understanding as a producer of the model, of who you are, as its consumer (to whom the producer is de- signing the model), what I have learned about what you need to do in system development (about what should be ad- dressed in the model). This is the solution of the system that I designed for you to carry out your activities”. Ba sed on this, we crea ted the following questions to help producers reflect on a rtifa cts consumers: (i) Can the consumer understand the artifacts’ cont ent? Can the consumer achieve its goals? – to support producers to reflect on whether everyone involved can understand the information in the model, such as developers and managers, or only developers; and (ii) What content should be addressed about the domain of the problem/solution of the system in the artifact? - In or- der to encourage the producer to reflect on the content that she wishes to be comprehended from the model, such as the tasks that a user can perform on the system. These questions are used before the use of the DCs. Rega rding the informa tion rela ted to models’ content, the DCs use the four ma xims of Grice’s Coopera tive Principle. The directives will a llow producers to reflect on the models’ content before they send it to the consumer, so tha t there is mutua l comprehension in softwa re development teams. With this, the DCs ca n improve the model’s a bility to convey to its consumers the solution conceived by its producers. Below we present ea ch DC, ba sed on Grice’s ma xims: “Say the truth!” - DC1: Use true informa tion. Do not use informa tion tha t a ffects the content qua lity in the model (ma xim of Qua lity). In the UML use ca se dia gra m, for in- sta nce, do not insert use ca ses tha t a re outside the problem doma in: “Say what is needed and no more than necessary” - DC2: Use the necessa ry content in the model. Do not use unnecessa ry content in the model (ma xim of Qua ntity). An- a lyze, for insta nce, the a mount of informa tion in the specifi- ca tion of a ll use ca ses; “Say it logically” - DC3: Orga nize the informa tion in the model consistently (ma xim of Rela tion). For exa mple, or- ga nize the use ca ses in the dia gra m so tha t they present a logica l sequence for the producers; “Say it clearly” - DC4: Orga nize the informa tion in the model clea rly (ma xim of Ma nner). Describe the na mes of the use ca ses so tha t they a re ea sily understood a nd differenti- a ted from ea ch other. 3.2 How can software engineers can apply the DCs? We designed the DCs to be employed by softwa re engineers in a rtifa cts tha t represent a spects of the softwa re developed from their perspectives, such a s UML dia gra ms, BPMN dia - gra ms, a nd prototypes. In the study presented in Subsection 4.2, a tea m a dopted UML use ca ses a nd prototypes to repre- sent their softwa re development decisions. The DCs ca n re- duce the risks of miscommunica tion via these a rtifa cts. Fig- ure 3 presents a schema tic of how softwa re engineers can a pply the DCs into UML use ca ses. Figure 3. Directives of Communicability for software artifacts. Towards to Transfer the Directives of Communicability to Software Projects: Qualitative Studies Lopes et al. 2021 In step 1 of Figure 3, the producer begins his process of reflection on the consumers of the a rtifa ct produced based on the proposed questions. In step 2 of Figure 3, the producer is a ble to obta in a better use of the directives in modeling, so tha t mutua l understa nding occurs. For exa mple, consider a pra ctitioner modeling a use ca se for a system tha t supports users in the use of medicines. By using DC2, ba sed on the pra ctitioner’s reflection, if the producer knows tha t the con- sumer ca n recognize the difference between the ‘reminders’ a nd ‘notices’ elements tha t will be used in the system, there is no need to deta il the difference between them. If the con- sumer does not know such a difference, it is importa nt that the producer describes this. DC2 will support this producer in producing use ca se specifica tions with the a mount of in- forma tion needed for those elements. Rega rding the use of the DCs, producers ca n use them in digita l forma t, a vaila ble in a technica l report (Lopes et a l., 2021), or print them to put on their worksta tions. We just empha size tha t it would be interesting for the producers had a ccess to directives during the development of the a rtifa cts. In Section 5, we present proposa ls tha t ca n help softwa re en- gineers a dopt the DCs in softwa re projects. About the users of our proposa l, we crea t ed the DCs to be used by both beginners a nd experienced softwa re engi- neers, since they know the modeling nota tion. We empha size tha t the DCs support producers reflect on the a rtifa ct’s con- tent to a chieve a mutua l understa nding a mong the members of a softwa re development tea m a nd not in modeling errors. 3.3 Preliminary studies with the DCs In Lopes et a l. (2019a ), two softwa re engineers, with the sa me level of experience in modeling, produced a rtifa cts. One of them used the DCs a nd the other did not. Then, 3 0 pa rticipa nts were invited to crea te mockups ba sed on the a r- tifa cts produced by the softwa re engineers. We divided the pa rticipa nts into two groups. The experimenta l group crea ted the mockups ba sed on the a rtifa cts produced with the DCs a nd the control group used the mockups ba sed on the a rti- fa cts developed without the DCs. We noticed tha t the exper- imenta l group ha d a lower number of miscommunica tion. In Lopes et a l. (2019b), the DCs were a lso a na lyzed to reduce the risk of miscommunica tion in softwa re a rtifa cts, such a s UML cla ss dia gra ms, BPMN (Business Process Modeling a nd Nota tion) dia gra ms (OMG, 2011) a nd IFML (Intera ction Flow Modeling La ngua ge) (Bra mbilla a nd Fra - terna li, 2014). We choose these dia gra ms for different com- munica tion purposes during softwa re development. Twenty- four pa rticipa nts, divided into two groups, ba sed on a mod- eling scena rio, produced such dia gra ms. The experimental group used the DCs a nd the control did not use the directives. The experimenta l group crea ted a rtifa cts with a lower num- ber of risks of miscommunica tion compared to the control group. In Lopes et a l. (2019a ) a nd Lopes et a l. (2019b), we pre- sented studies with qua ntita tive a na lyzes. However, it is im- porta nt to ca rry out qua lita tive studies on the DCs before tra nsferring them to the industry. For this rea son, we pla nned new studies tha t a im to a na lyze pra ctitioners’ perceptions a bout the directives. Figure 4 presents a timeline a bout the studies ca rried out a nd our pla nning rega rds the new studies, which to answer the resea rch questions (RQ) below. RQ1 - Do practitioners perceive the DCs as support in improving the quality of artifacts? RQ2 - Is the DC application by producers feasible in development teams? Figure 4. Timeline of preliminary studies with the DCs and planning of new studies in the software industry. Towards to Transfer the Directives of Communicability to Software Projects: Qualitative Studies Lopes et al. 2021 4 Experimental Studies This section presents the studies ca rried out with pra ctition- ers before tra nsferring the DCs to the industry. In the first study (Study 1), fifteen pra ctitioners pa rticipa ted. Th ey cre- a ted a UML use ca se with the support of the DCs. Our main goa l in this study wa s to a na lyze the communica tion inten- tion by a rtifa cts producers. After the study, the pa rticipa nts provided their perceptions a bout the DCs through a question- na ire. In the second study (Study 2), we ca rry out a study in the context of a softwa re project. We eva lua te if the DCs can provide supports to identify risks in softwa re a rtifa cts that ca used miscommunica tion. In a ddition, producers a nd con- sumers provide their perceptions a bout communica tion via a rtifa cts through interviews a nd a n online questionna ire. 4.1 Study 1: Evaluation of the DCs from the practitioners’ perception We conducted a first study tha t eva lua tes the pra ctition- ers’ perception of the DCs from 15 pra ctitioners rega rding their support during a rtifa cts development (Lopes et a l., 2020). In this study, the pa rticipa nts a pplied the DCs in UML use ca ses, tha t is, in the use ca se dia gra m a nd specifica tion. After that, we sent questionnaires to collect the practitioners’ perceptions. As in this study we evaluated the practitioners’ percep- tion of the DCs during the modeling of use cases. We did not investigate the communication between producers and con- sumers. Therefore, the researchers analyzed only the possi- bility of a risk of miscommunication in the use cases. In ad- dition, we analyzed the impact on the quality caused by the risks of miscommunication and qua lita tive da ta obta ined a bout the practitioners’ answers. 4.1.1 Study 1: Planning We selected 15 pra ctitioners to produce UML use ca ses with the support of the DCs. All pra ctitioners ha d a college degree a nd they were ta king the Funda mentals of Softwa re Engi- neering cla ss in Softwa re Engineering postgra dua te course a t Northern University Center (UNINORTE). Table 1 pre- sents a summary of the participants’ experience. Regarding the participants, most of them did not work creating artifacts in software projects related to our research. However, we consider practitioners who are consumers in software pro- jects able to participate in the study, because they can pro- vide their perception into our proposal to communication via artifacts. In this way, we planned training so that participants execute the study activities. We planned this study to take in a single day, du ring the morning and afternoon. In the morning, before we ca rried out the study, the pa rticipa nts received tra ining of a pproxi- ma tely two hours for exercising use ca se modeling. It is note- worthy tha t a ll pa rticipa nts ha d prior knowledge of UML use ca ses. In the a fternoon, we reserved a la bora tory for the ex- ecution of this study, which ha d notebooks for the pa rtici- pa nts to use. We pla nned to run this study in a pproximately three hours. Table 1: Participants’ experience in software industry EXPERIENCE IN THE INDUSTRY PARTICIPANTS 1 – 3 years P1 (Developer) P2 (Software Tester Developed) P3 (Software Analyst) P4 (Developer) P6 (Process Engineer) P7 (Developer) P10 (Developer) P12 (Developer) P13 (Developer) 4 – 8 years P8 (Software Tester Developed) P9 (Developer) P15 (Developer) more than 9 years P5 (Developer) P11 (Developer) P14 (Project Manager) In order to observe the pa rticipa nts’ discussion rega rding the development of use ca ses in different modeling scena r- ios, we ra ndomly defined four groups. Ea ch modeling sce- na rio ha d simple content, so tha t the pa rticipa nts complete the study a ctivities in the pla nned time. We present the de- scription of the modeling scena rios for ea ch group below: Group 1 scenario – To support students who want pri- vate lessons in basic classes such as Mathematics, a system must be developed. The system should provide teachers with private lessons. Additionally, evaluations of these teachers by students/other teachers should be displayed. The system should allow managing the teachers’ agendas on the classes, so that students can enroll in them. Thus, it is possible to include and cancel classes. Group 2 scenario – To support the small events, a sys- tem must be developed. In this system, the organizers will be able to create their accounts and, from th is, register events such as birthday parties, guest lists, and gift lists. They will also be able to send invitations via e-mail, control expenses, and generate reports for both guests and expenses. The sys- tem provides communication among organizers and gu ests. Guests may or may not confirm their presence at the event and consult the gift list. Group 3 scenario – To support sales professionals in their orders, such as delivery control, customer management (retailers and wholesalers), a system must be developed. The system will support professionals who want to computerize and innovate the service, minimizing errors and constraints from the lack of systematic control. The system should allow users to register their customers and to manage the stock of their products. After the payment record, the order is sent to the customer with the delivery invoice. Group 4 scenario – To support residents of the state of Amazonas in Brazil, who have difficulty accessing the infor- mation on river routes for purchasing tickets, a system must be developed. The system will support passengers of differ- ent vessels, embarking/disembarking times, the vessels’ ca- pacity, number of available spaces, price, and information on river routes. Concerning vessels’ owners, they will be able Towards to Transfer the Directives of Communicability to Software Projects: Qualitative Studies Lopes et al. 2021 to register the number of employees availabl e for passenger assistance. Before the execution of the study, we planned training with the DCs to be applied in use case modeling. Rega rding the study a ctivities pla nned a nd Figure 5 summa rizes them. Figure 5. Study 1 activities planned. To analyze the defects related to the risks of miscommu- nication, we used the types of defects presented by Granda et al. (2015). Table 2 shows these defects. Table 2. Types of defects (adapted from Granda et al. (2015)) TYPE DESCRIPTION Omission The required information has been omitted. Incorrect Fact Some information in the model contradicts the list of requirements or general knowledge of the system domain. Inconsistency Information in one part of the model is incon- sistent with information in other parts in the model. Ambiguity The information in the model is ambiguous. This can lead to different interpretations of in- formation. Extraneous In- formation The information that is provided is not requi- red in the model. Redundant Information is repeated in the model. 4.1.2 Study 1: Execution We asked the participants to position themselves according to the groups defined to carry out the study activity. The par- ticipants were in the same laboratory, but the groups were far from each other. After that, we delivered to the groups the modeling scenarios and the printed DCs. The main researcher, the participants to draw up the use case diagram together, discussing relevant aspects of the sys- tem. After that, the researcher requested each participant to specify only one use case. The participants created the use cases from the modeling scenarios. Regarding the use of the DCs, the participants should, for example, create use cases in the context of the problem domain (use of DC1) and ana- lyze the amount of information to understand these use cases correctly (use of DC2). During the study, a researcher a re- searcher took notes of the directives most used by the partic- ipants. 2 https://a stah.net/ The participants used the Astah21tool to model use cases. Table 3 presents the four groups defined with the participants and the objective of each system in the modeling scenarios. Table 3. Groups defined in this study GROUPS PARTICIPANTS Group 1 P4, P5, P6 e P7 Group 2 P8, P9, P10 e P11 Group 3 P12, P13, P14 e P15 Group 4 P1, P2 e P3 Regarding the use of the DCs, the main researcher in- formed the participants the directives can be applied accord- ing to the most appropriate for them, such as by using the directives during the modeling or after the participants made a modeling proposal. The main researcher noticed that all groups made a modeling proposal and then applied the DCs. At the end of the study, all participants answered a post - study questionnaire to provide their perceptions about the DCs, including each participants’ experience in the industry. Regarding the duration of the study, it was completed ahead of our planning. 4.1.3 Study 1: Results We analyzed the use cases produced by the groups regarding the risks of miscommunication, which were discussed with the other authors of this paper. The risks of miscommunica- tion identified in the use cases of each group are shown in Table 4, including their total number of occurrences and the description of each risk. Table 4: Risks of miscommunication in the use cases developed by the groups GROUPS DESCRIPTION OF THE RISKS OF MIS- COMMUNICATION Group 1 - Lack of relationship in the use case diagram (1) - Different standards in the organization of the use case specification (3) - Lack of information in business rules (5) Group 2 - Use case specification inconsistent with the use case diagram (1) - Lack of relationship in the use case diagram (1) - Lack of information in business rules (4) Group 3 - Lack of information in business rules (2) - Lack of steps in the main flow of the use case specification (2) Group 4 - Lack of steps in the main flow of the use case specification (2) - Lack of information in business rules (5) In this analysis, for example, we noticed that the partici- pants in Group 1 did not provide all the necessary infor- mation in the business rules, such as the fields in the system for a student to evaluate the teachers. The evaluation of the Towards to Transfer the Directives of Communicability to Software Projects: Qualitative Studies Lopes et al. 2021 artifacts produced by the groups showed few risks of mis- communication compared to the number of risks of miscom- munication identified in other software artifacts in a prelim- inary study (Lopes et al., 2019b). However, such risks can cause possible miscommunication. Regarding the application of the DCs by the participants, based on the researcher’s notes during the study, the majority of them used the following directives: DC2 to evaluate the amount of information that should be represented, and DC3 for the organization of information logically in use cases. Analysis of software defects related to risks of com- munication failure. We grouped the risks of miscommuni- ca tion in Ta ble 5, which a re rela ted to the groups. Defects rela ted to risks ha ve a lso been described in this ta ble. Rega rding the risks of miscommunica tion, we noticed a la ck of informa tion for the business rules in the four model- ing groups. Besides, there wa s a la ck of informa tion for the rela tionship between use ca ses in the dia gra ms produced by the two groups. There wa s a la ck of specifica tion of steps in the ma in flow of use ca ses of two groups. These risks would be mitiga ted if the pa rticipa nts ha d reflected better on the a mount of information, rela ted to DC2. Rega rding the risks rela ted to the la ck of sta ndardiza tion of use ca se specification itself a nd inconsistency between the use ca se specifica tions a nd the use ca se dia gra m, this would be mitiga ted with DC4 a nd DC1, respectively. Table 5. Defects related to the risks of miscommunication in the use cases developed by the groups GROUPS DESCRIPTION OF THE RISKS DEFECTS Group 1 Group 2 Lack of relationship in the use case diagram Omission Group 1 Different standards in the or- ganization of the use case specification Ambiguity Group 1 Group 2 Group 3 Group 4 Lack of information in busi- ness rules Omission Group 2 Use case specification incon- sistent with the use case dia- gram Inconsistency Group 3 Group 4 Lack of steps in the main flow of the use case specification Omission Rega rding the risks rela ted to the la ck of informa tion in: (i) the business rules, (ii) ma in flow steps in the use case specifica tion, a nd (iii) rela tionships between use ca ses in the dia gra m we considered them to be a n ‘Omission’ defect. Dif- ferent sta nda rds in the specifica tion of use ca ses ma y a llow different interpreta tions by consumers, which we considered a n ‘Ambiguity’ defect. Fina lly, we considered inconsistent informa tion between the use ca se dia gra m a nd the use case specifica tion to be a n ‘Inconsistency’ defect. Analysis of the Participants’ Perception. Rega rding the post-study questionna ire, the pa rticipa nts a nswered the fol- lowing question: “Wha t is your perception of the directives of communica bility?” We defined this question in a genera l wa y to collect different opinions of the pa rticipa nts on the DCs. To a na lyze the qua lita tive da ta obta ined in the study a c- cording to Stra uss a nd Corbin (1998), resea rchers ca n use coding procedures to a chieve their resea rch objectives. We used open coding to understa nd pa rticipa nts’ perceptions. With tha t, we observed the following codes: DCs contribute to the quality of software artifacts "The directives help to reflect on what should be developed, avoiding inconsistencies" (P5) "The directives help to understand the system, support to identify possible errors" (P8) "Facilitates the identification of problems in modeling" (P13) DCs promote the organization of information in artifacts "The directives helps to organize and improve the infor- mation required to create a system" (P3) "DCs assist in organizing ideas together with the develop- ment team" (P10) "The directives help to organize thoughts when designing the system" (P2) DCs support the understanding of the system "DCs assist to obtain relevant information for the project" (P4) "The directives provide great support for the production of the software" (P7) "Helps to considerably improve the general understanding of a system" (P15) DCs can promote effective communication via artifact "DCs are a type of roadmap for organizing ideas in commu- nication through a logical way" (P11) "They help to think about how to communicate with col- leagues" (P6) "Help in communicating correctly in software development" (P12) DCs promote the reduction of different interpretations "The directives help reduce the multiple interpretations of the same idea, as the ideas must be conveyed so that every- one understands" (P14) Difficulties with the use of the DCs "It is not easy to understand the directives; it required more of my mental effort" (P2) "It is not easy to apply the directives; I believe it depends on the user's experience" (P5) "Directives demand time for understanding" (P6) Through the participants’ perceptions, we observed that the DCs contribute to the improvement of the quality of the Towards to Transfer the Directives of Communicability to Software Projects: Qualitative Studies Lopes et al. 2021 artifacts. Such perceptions are represented by the co des ‘DCs contribute to the quality of software artifacts’ and ‘DCs pro- mote the organization of information in artifacts’. Most of the participants’ responses showed that they perceived the purpose of the DCs, as we noticed the codes ‘DCs can pro- mote effective communication via artifact’ and ‘DCs pro- mote the reduction of different interpretations’. Some participants also reported ‘Difficulties with the use of the DCs’, which may be related to their reflection on whether or not they are correctly applying the main concept of each directive for what each producer wants to communi- cate. However, this is part of the reflection process by pro- ducers regarding their communication through artifacts. Analysis of acceptance. We applied the Technology Ac- ceptance Model (TAM) to analyze the participants’ percep- tion of the DCs in the post-study questionnaire (Venkatesh and Bala, 2008). TAM is one of the most adopted models for collecting information about the decision to accept or reject technologies (Marangunić et al., 2013). This model is basi- cally based on two constructs: Perceived Ease of Use: degree to which a user believes to use a specific technology with little effort. Perceived Usefulness: the degree to which a user believes tha t using a specific technology would improve their perfor- ma nce a t work. The user’s beha viora l intention to use a technology, the Intention to Use, is determined by the perceived ea se of use a nd perceived usefulness. The sta tements conta ined in the post-study questionna ire to a ssess the constructs of ea se of use, usefulness, a nd intention to use the DCs, a da pted from [25], a re presented below: PERCEIVED EASE OF USE E1. My interaction with the Directives of Communicability is clear and understandable. E2. Interacting with the Directives of Communicability does not require a lot of my mental effort. E3. I find the Directives of Communicability easy to use. E4. I find it easy to get the Directives of Communicability to do what I want it to do. PERCEIVED USEFULNESS U1. Using the Directives of Communicability improves my performance better for understanding aspects of the software. U2. Using the Directives of Communicability in my job has improved my productivity, since I will not have to correct information that is not understood by colleagues. U3. Using the Directives of Communicability enhances my effectiveness on communication with the team based on the artifacts. U4. I consider the Directives of Communicability useful for software design. INTENTION TO USE I1. Assuming I had enough time to design software, I intend to use the Directives of Communicability. I2. Considering that if I could choose any tool, I predict that I would use the Directives of Communicability. I3. I plan to use the Directives of Communicability in my next project. Rega rding the a da pted TAM sta tements, pa rticipa nts provided their a nswers on a seven-point Likert sca le (Likert, 1932). The possible a nswers were “Tota lly Agree, Strongly Agree, Pa rtia lly Agree, Neutra l, Pa rtia lly Disa gree, Strongly Disa gree, a nd Tota lly Disa gree”. The pa rticipa nts a nswered their degree of a greement on the usefulness, ea se of use, and intention to use the DCs in the production of a rtifa cts. Figure 6 summa rizes the pa rticipa nts’ a nswers. Figure 6. Degree of participants’ acceptance regarding the use of the DCs in the production of artifacts Rega rding the disa greements rela ted to E2, E3 a nd E4 for ea se of use, a s shown in Figure 6, we noticed five pa rtici- pa nts a nswered tha t, including P2, P5 a nd P6 tha t cited it’s not ea sy to employ DCs, represented by the ‘Difficultie s with the use of the DCs’ code in Subsection 5.2. The other pa rticipa nts did not provide a nswers to expla in why they dis- a greed with E2. In summa ry, such a nswers ma y indica te that it is importa nt to provide ma teria l tha t helps in the producer's reflection ba sed on the DCs. About the disa greement a nd neutra l a nswers with the sta tements tha t measure usefulness, we noticed tha t P3, P6, a nd P11 a nswered this. However, a ll pa rticipa nts who con- sume informa tion from a rtifa cts, i.e. developers, a gree that our proposa l is useful to communica tion via artifa ct. Overa ll, most of the pa rticipa nts’ a nswers showed a greement rega rd- ing ea se of use, usefulness, a nd intention to use the DCs. With this resea rch (Lopes et a l., 2020), we observed that the DCs promoted the pa rticipa nts’ reflection on their com- munica tion to the others involved in the development of a softwa re. The DCs a lso ma de it possible to reduce the intro- duction of defects, beca use we perceived consistent ma pping between the risks of miscommunica tion a nd softwa re de- fects. Additiona lly, most of the pa rticipa nts’ a nswers to the DCs were positive a bout their use. With this, it is possible to infer tha t the softwa re industry considered the directives use- ful. Ba sed on the results obta ined in this study, we decided to ca rry out a fea sibility study in a softwa re development team. This study ma y increa se the indica tions on the tra nsfer of the DCs to the industry. Towards to Transfer the Directives of Communicability to Software Projects: Qualitative Studies Lopes et al. 2021 4.1.4 Threats to Validity of Study 1 In all experimental studies, there are threats that can affect the validity of the results. The threats related to this study are discussed below with the classification of threats to validity presented by Wohlin et al. (2012): Internal validity. Tra ining effect - it would be interesting if there wa s no need for tra ining. However, the short tra ining time a llowed the DCs to be used by pra ctitioners during the production of UML use ca ses. In a ddition, tra ining on use ca se modeling a lso ena bled pa rticipa nts to execute the study a ctivities, a s most of them did not work crea ting a rtifa cts that represent softwa re decisions in projects. Time used for the study - despite the time considered long for the use case modeling, a ll pa rticipa nts completed the study a ctivities be- fore the expected tim e. External validity. Validity of the artifacts – we carried out only modeling of UML use cases in this study. It is not possible to claim that UML use cases represent all the arti- facts that support communication. Besides, the use cases were modeled for four software projects. It is not possible to claim that this artifact represents all types of software. Construct validity. Indicators for miscommunication - The measures adopted to analyze miscommunication were based on the Semiotic Engineering theory (de Souza, 2005; de Souza et al., 2016), which has different methods to assess communication during the development process. Conclusion validity. There is a limitation in the repre- sentativeness of the results, a known problem in experi- mental studies of Software Engineering (Fernandez et al., 2012). The results obtained in this study may not be repro- duced in other software artifacts that support the und erstand- ing of members of a team. Analysis of Artifacts – about the risks of miscommunication in use cases, there is a threat re- garding the researcher who carried out such analysis. To mit- igate this threat, we added another researcher to discuss this analysis. 4.2 Study 2: Feasibility Study In study 1, a lthough we perceived positive a nswers a bout the DCs, we did not ca rry out the study in the context of a softwa re project. We ca rried out a nother study, our second study, in a softwa re development tea m. We investiga ted the use of the DCs in the a rtifa cts used by the tea m to identify risks tha t ca used miscommunica tion in the development of the Bulletin System (SISBOL). SISBOL is a Web System, with client-server a rchitec- ture, following the sta nda rd Representa tional Sta te Tra nsfer (REST) [1], with the purpose of a utomating the process of genera ting newsletters (officia l) a nd ma naging the members' persona l historica l (cha nges of the milita ry) of the Bra zilia n Army (EB). A bulletin represents a n instrument by which the comma nder, chief or director of the EB dissemina tes the or- ders of the higher a uthorities a nd the fa cts tha t must be known by the Milita ry Orga niza tions in which the members pa rticipa te. SISBOL is composed of entities a ssocia ted with milita ry, such a s qua lifica tion, gra dua tion, subunit/divi- sion/section, milita ry orga niza tion, function a nd a ltera tion, a ssocia ted with the bulletin structure (type of bulletin, sec- tion, pa rt, genera l subject, specific subject, note) a nd a ssoci- a ted with system users. Notes a re documents proposed by a competent a uthority to be a pproved by the commander, chief or director, for publica tion in its bulletin. The system has a certa in degree of configura bility, a llowing the a pprova l pro- cessing workflows for notes a nd bulletins to be customized for ea ch milita ry orga niza tion. 4.2.1 Study 2: Planning We initia lly designed the study to a na lyze how the team conducted its a ctivities a nd how softwa re a rtifa cts support communica tion. Then, we pla nned the a na lysis of the a rti- fa cts with the support of the DCs to identify opportu nities for improvement to a better communica tion. Fina lly, we pla nned a collection of the tea m members’ perception of the support of the a rtifa cts. The tea m selected for the study wa s composed of 14 pra ctitioners who developed the SISBOL. Ta ble 6 shows the cha ra cteriza tion of the tea m. Table 6. Characterization of the team TEAM EXPERIENCE Systems Analyst (Product Owner- PO) 20 years Designer 9 years Developer 1 7 years Developer 2 20 years Developer 3 5 years Developer 4 16 years Developer 5 4 years Developer 6 4 years Developer 7 19 years Developer 8 12 years Developer 9 12 years Developer 10 3 years Developer 11 10 years Developer 12 3 years The scope of the new SISBOL involves 30 functiona li- ties, which were divided into Lega cy Fea tures (23) a nd New Fea tures (07). The tea m used the a gile development method- ology. The development tea m used the a gile Scrum method- ology. The a rtifa cts ela bora tion process wa s colla bora tive a nd involved different project sta keholders. The tea m used UML use ca ses a nd prototypes a s a rtifacts tha t conta in the solution designed for softwa re development. Rega rding the tea m selected, the pra ctitioners did not create a doma in model, just the use ca ses a nd mockups. About the experience of the producers, the system a na lyst ha d twenty yea rs of experience with UML a nd the designer ha d nine yea rs of experience with prototypes in projects. Rega rding the system developed by the tea m, it wa s a lrea dy in its fina l pha se, a s the tea m wa s only ma king corrections to some fea- tures. 4.2.2 Study 2: Execution We ca rried out the following steps in this study: Towards to Transfer the Directives of Communicability to Software Projects: Qualitative Studies Lopes et al. 2021 (i) a meeting between the PO a nd the ma in resea rcher in order to obta in a n overview of the a ctivities and the a rtifa cts used a s a mea n of communica tion; (ii) meeting a mong the ma in resea rcher with the tea ms’ producers to a na lyze the a rtifa cts’ content ba sed on the DCs; (iii) a fter tha t, we prepa red a n electronic questionna ire for producers to a nswer their perceptions of the a r- tifa cts a s a support for communica tion; (iv) a meeting of the ma in resea rcher with a n a rtifa cts consumer to understa nd how they used the a rtifa cts; (v) we a lso sent a n electronic questionna ire for consum- ers to a nswer their perceptions of the a rtifa cts with questions ba sed on the DCs. Due to the una va ila bil- ity of some pa rticipa nts to pa rticipa te in individua l meetings, this questionna ire fa cilita ted the collec- tion of tea m members’ perceptions. In rela tion to step 2, the ma in resea rcher should be pre- sent to support the producers a nd to collect their perception a bout the a rtifa cts ba sed on the DCs. The ma teria l used in these steps is a va ila ble in a technica l report (Lop es et a l., 2021). Rega rding step 3, the pa rticipa nts a nswered the fol- lowing questions on the electronic questionna ire: 1. What is your perception about this artifact as a means of communication? 2. Tell us about your perception regarding the communi- cation via artifact. About the step 5, we used the following questions to col- lect the consumer’s perceptions a bout the softwa re a rtifa cts: 1. During the software development, did you notice any inconsistent information regards the team knowledge about the software? – based on DC1; 2. About the quantity of information, is there the lack of information or excessive information? - based on DC2; 3. Is all information in the artifacts relevant to software development? Please, tell us your perception – based on DC3; 4. It was difficult to understand any information in the artifacts? – based on DC4; With the execution of these steps, the DCs ca n help pra c- titioners to understa nd a spects that need improvements in the informa tiona l content of the a rtifa cts. These improvements ca n lea d a better communica tion via a rtifa cts. 4.2.3 Study 2: Results Firstly, the producers a na lyzed the a rtifa cts with the support of the DCs a nd we a na lyzed the types of defects rela ted to risks identified. After this, a na lyzed the pa rticipa nts’ a n- swers. Analysis of Software Defects Related to Risks of Commu- nication Failure. The ma in risks of miscommunica tion are in the use ca ses. Such risks a re rela ted to the la ck of upda ting of some informa tion, identified with the support of DC1, and the excess of informa tion, identified with DC2. Figure 7 pre- sents a cha ra cteriza tion of the identified risks. Figure 7. Analysis of artifacts based on DCs Rega rding defects rela ted to the risks of miscommunica- tion, we ha ve identified: • lack of updating of some information in the use cases – Inconsistence defect: the la ck of upda ting led to inconsistent informa tion in the a rtifa ct; a nd Extraneous Information defect: informa tion not needed in the a rti- fa ct. • excess of information - Ambiguity defect: the ex- cess of informa tion promotes different interpreta tions. Analysis of Communication via Team Artifact. We used open coding (Stra uss a nd Corbin, 1998) to understa nd the tea m’s communication via a rtifact and how the DCs ca n sup- port the improvement of this type of communica tion. We a p- plied the coding ba sed on the a nswer of producers a n d con- sumers a bout the a rtifa cts’ content. When a na lyzing the tea m’s communica tion through the a rtifa cts, we identified cha ra cteristics in the informa tional content tha t a ffected the communica tion. We noted tha t con- sumers ha d a dopted mockups more to support their a ctivities compa red to use ca ses. The tea m PO, one of the producers of the a rtifa cts, a nd the consumers mentioned: “Perhaps I put more information in the mockups than necessary and it led the team to not consult the use cases (Systems Ana lyst)”. “There was an excess of information in the documenta- tion. So many details generated several differences in the documentation for implementation and other minimal de- tails that did not affect the system's functionality itself... With the use of the mockups, it was easier to understand the user's needs, and so the doubts that I had about the func- tioning of the system were resolved (Developer 11)”. Towards to Transfer the Directives of Communicability to Software Projects: Qualitative Studies Lopes et al. 2021 “With the mockups, half of the system's functionalities were well defined, with only the business rules missing, which could not be modeled visually (Developer 12)”. The DCs indica ted tha t consumers a dopted more mockups a s support in their a ctivities tha n the use ca ses due to the excess of informa tion in the use ca ses (with the support from DC2), a lso cited by Developer 11. Additiona lly, there wa s a n outdated use case (with the support from DC1), gen- era ting a nega tive impa ct on communica tion via a rtifact, as observed by one of the consumers: “Throughout the development, I believe that the artifacts have become outdated in relation to the needs of users and the implementation of the system (Developer 4)”. Rega rding the communica tion via this tea m's a rtifact, one of the producers reflected on their communica tion based on the DCs a nd he believes there wa s a la ck of a nother a rti- fa ct tha t supports the understa nding of the user’s intera ction with the system (DC 2): “The artifacts contain the necessary information that the team needs to understand the problem. However, there are some limitations and information that cannot be transmitted in the artifacts. For example, the 'disposable mockup' pre- sents only an idea of what the interface with the possible fields of the system will look like, but it does not present how it will be done, or even the user's interaction with the system (Designer)”. With the results of this study, we noticed miscommuni- ca tion via a rtifa ct identified with the support of the DCs. The DCs were a ble to support the producers to ma ke improve- ments in the a rtifa cts, ena bling better communica tion via a r- tifa ct. 4.2.4 Threats to Validity of Study 2 The threats related to this study are discussed below with the classification of threats to validity presented by Wohlin et al. (2012): Internal validity. The ma in threa t to interna l va lidity wa s the sha ring of developers' perceptions of the a rtifa cts. To mitiga te this threa t, we sent a n electronic questionna ire to ea ch pa rticipa nt to a nswer their perception individua lly. However, this does not elimina te the possibility of communica tion between the pa rticipa nts. External validity. Regarding the artifacts evaluated in this study, it is not possible to state that they represent all the artifacts that support communication. Additionally, these ar- tifacts were modeled for just one software project. Construct validity. We identified the threat of the partic- ipant providing answers that do not reflect reality but rather personal expectations regarding the artifacts. To mitigate this threat, we informed the participants that the experiment did not provide any kind of personal or project assessment but rather as an assessment of the use of artifacts in support of communication. Conclusion validity. There is a limitation in the repre- sentativeness of the results, this being a known problem in experimental studies of Software Engineering (Fernandez et al., 2012). The results obtained in this study may not be re- produced in other software artifacts that support the under- standing of those involved in the production of the systems. 4.3 Lessons Learned These studies helped us to understa nd different aspects of the DCs from the pra ctitioners’ perception. About study 1, we described our lessons lea rned below. • Disagreements about the ease of use of the DCs show the need to create material that supports application of each directive – a lthough most pa rticipa nts a gree that DCs a re ea sy to use, we noticed some disa greements a bout this. The DCs a re genera l instructions tha t sup- ports the ‘reflection’ of producers a bout their commu- nica tion via a rtifa ct a nd there a re no specific steps for tha t. However, to support producers employ the direc- tives, a ma teria l tha t indica tes some reflection points would be interesting. Such ma teria l ca n be crea ted ba sed on common scena rios noticed in both studies pre- sented in our pa per. • Perceived usefulness by practitioners who act as con- sumers indicate that our proposal can support the com- munication of the artifact –the usefulness perceived by pra ctitioners who work a s developers indica ted tha t our proposa l supports mutua l understa nding between pro- ducers a nd consumers, since such pa rticipa nts ma y had experienced such a scena rio. About Study 2, we noticed tha t DCs supported pra ctition- ers in the eva lua tion of a rtifa cts a lrea dy used by a software tea m. We ha d the following lessons lea rned from our pro- posa l in this study: • Consumers’ perceptions during evaluation of artifacts improve this type of communication – Rega rding the employ of DCs in the eva lua tion of a rtifa cts a lready used by softwa re tea ms, both producers a nd consumers ca n do tha t, providing a contra st a bout communication via a rtifa ct in a tea m. Such pra ctice supports continuous improvements in this type of communica tion. • Material that supports producers to adopt the DCs in software projects – we designed the initia l proposa l of the DCs to a pply them in the production of a rtifa cts, but we noticed the potentia l of the directives eva lua te a rti- fa cts a lrea dy used by tea ms. Aims to help softwa re en- gineers to a dopt the DCs in their projects, it would be interesting the development of procedures tha t indica te the ma in steps to a pply the DCs. The next section presents the proposa l of the ma terials prepa red to support softwa re engineers a dopt the DCs in their projects. We crea ted such proposa ls ba sed in our les- sons lea rning. Towards to Transfer the Directives of Communicability to Software Projects: Qualitative Studies Lopes et al. 2021 5 Proposal to Support the Application of the DCs in Software Projects Rega rding the DCs, ea ch directive a ims to provide a genera l indica tion of how a rtifa cts ca n be expressed by their producers a bout their communica tion, so the risks of miscommunica tion a re mitiga ted. Rega rding the a doption of the DCs to support improving the communica bility of a softwa re a rtifa ct, we observed two contexts in which a rtifa cts a re used: (1) when they a re a lrea dy being used by a tea m during the execution of a project , a nd (2) before being used by the tea m when the project is in its initia l st a ges. For the context a bove, we crea ted procedures to fa cilitate pra ctitioners who wish to a dopt the DCs in their projects. Figure 8 presents a procedure to be followed by pra ctitioners who wish to a dopt the DCs to identify opportunities for improvements in the a rtifa cts. This procedure is suggested for tea ms tha t ha ve sta rted crea ting a rtifa cts without the support of our proposa l, but they would like to a dopt it in the a rtifa cts, a s noted in the second study presented in this pa per, such a s: 1. Communication intent - pra ctitioners should reflect on their communica tion intent ba sed on the questions: “ Can the consumer understand the artifacts’ content? Can the consumer achieve its goals?”, like developers a nd testers, a nd “What content should be addressed about the domain of the problem/solution of the system in the artifact? ”, a s the ta sks tha t a user ca n perform in the system. 2. Use of the DCs in the artifacts’ content - use of the DCs to identify risks tha t ca used miscommunica tion. To fa cilita te the use of the DCs, we prepa red a checklist, presented la ter in the text. At this sta ge, producers and consumers ca n ca rry out the eva lua tion for a better understa nding of the necessa ry improvements. 3. Availability of artif acts - with the improvements ma de, producers ma ke the a rtifa cts a vaila ble to consumers, a s this a lso a ffects communication via a rtifa cts, such a s e - ma il or repository used by the tea m. Figure 8. Use of the DCs during execution of projects For the second context, Figure 9 shows the procedure that pra ctitioners ca n a dopt when using the DCs before the production of the a rtifa cts. Ea ch step to be followed in the procedure is described below. With the DCs a pplied to the a rtifa cts before their consumption, the risks tha t ca used miscommunica tion ca n be reduced. Figure 9. Adoption of the DCs in project planning 1. Modeling notation - it is importa nt for producers to reflect on the nota tion tha t will be a dopted when modeling the a rtifa cts to represent a spects of the softwa re. Additiona lly, it is importa nt for producers to reflect on whether such nota tion is known to consumers. This st ep wa s not considered in the first context beca use the tea m a lready ha s the a rtifa cts esta blished to represent the solutions modeled for the softwa re. 2. Communication intent - simila rly to the first context, pra ctitioners must reflect on their intention to communicate ba sed on the questions proposed to use with the DCs. 3. Use of the DCs in the artifacts’ content - Use of the DCs to reflect on producers' communica tion intent. The checklist a lso supports this reflection. 4. Availability of artifacts - producers should reflect on the best mea ns of communica tion tha t a rtifa cts should be ma de a vaila ble to consumers, a s it ca n a ffect communication via a rtifa cts, such a s e-ma il or repository. In a ddition to the procedures, we a lso developed checklists tha t ca n facilita te the a pplica tion of the DCs in the a rtifa cts investiga ted in our resea rch, such a s UML use case a nd mockups. Ta ble 7 presents the checklist for mockups a nd Ta ble 8 presents the checklist for UML use ca se. Table 7. Checklist based on DCs for Mockups DCs ITEM DESCRIPTION DC1 Is there information in the mockups that are outside the problem domain? If so, remove that information Is there outdated information in the mockups? If so, update them DC2 Are all requirements represented in the mockups? If not, design mockups with such information Are all alternative paths represented in the mockups? If not, enter this information in the mockups In general, is the amount of information in the mockups sufficient for the team to understand the system? If not, enter the required amount of information Is there an excess of information? If so, if this excess is unneces- sary for understanding the system, remove it from the mockups DC3 Is the order of the screens organized in such a way that the team better understands them? If not, arrange this sequence DC4 Are the screen names clear in relation to their purpose? If not, clar- ify the names of the screens In mockups, are there any terms that are unknown to consumers? If so, please clarify such terms In mockups, is there any ambiguous information? If so, please clarify this information Is information used to obtain implicit interpretation by the team? If so, reflect on whether such information should be expressed ex- plicitly to avoid multiple interpretations Towards to Transfer the Directives of Communicability to Software Projects: Qualitative Studies Lopes et al. 2021 Table 8. Checklist based on DCs for Use Cases DCs ITEM DESCRIPTION DC1 Is there information in the use cases that are outside the problem domain? If so, remove that information Is there outdated information in the use cases? If so, update this information DC2 Are all relationships between use cases represented in the dia- gram? If not, enter such relationships Are all use cases represented in the diagram? If not, insert such use cases In use cases specification, are all actors involved represented? If not, insert such actors When specifying a use case, are all flows represented? If not, enter the necessary flows When specifying a use case, are all business rules represented? If not, insert the necessary rules Is there an excess of information? If so, if this excess is unnec- essary for understanding the system, remove it from the mockups DC3 Are the use cases organized in the diagram logically? If not, or- ganize the use cases Are the actors organized concerning the use cases in the dia- gram? If not, organize the actors in the diagram Is the sequence of information in each use case specification logically organized? If not, organize this information DC4 Are the names of the use cases clear concerning their purpose? If not, clarify the names of the use cases Are the names of the actors clear concerning their purpose? If not, clarify the actors In the use case specification, are there any terms that are un- known to consumers? If so, please clarify such terms When specifying a use case, is there any ambiguous infor- mation? If so, please clarify this information These checklists conta in questions ba sed on co mmon a rtifa ct scena rios tha t ha ve risks of miscommunica tion. However, we empha size tha t DCs help pra ctitioners to reflect on the a rtifa cts a nd checklists support the identifica tion of specific risks. In this wa y, checklists should be used together with the DCs. 6 Discussion We ca rried out studies with the objective of tra nsferring the DCs to the softwa re industry. In the first study, con- ducted to a nswer RQ1 (Do practitioners perceive the DCs as support in improving the quality of artifacts? ), we noticed tha t the directives supported the pa rticipa nts' reflection on the communica tion via UML use ca ses. This a llowed reduc- ing possible inconsistencies in the development of the ex- plored a rtifa ct. It wa s possible to obta in evidence tha t t he DCs ca n contribute to improving the a rtifa cts’ qua lity, since the DCs supported reducing incorrect informa tion. This can reduce costs during softwa re development, a s defects dis- covered during the softwa re development process increa se costs due to the correction of such defects. The second study conducted a ims to understa nding the fea sibility of the DCs to support the improvements in the communica bility of softwa re a rtifa cts used by the tea m to a nswer RQ2 (Is the DC application by producers feasible in development teams?). The use of the DCs showed the main a spects tha t need improvements, since they nega tively a f- fected the communication between producers a nd consumers of these a rtifa cts. The results of this study demonstra ted the benefit of using the DCs, a s the problems identified in the informa tiona l content of the a rtifa cts ca n be fixed. Both studies showed evidence to tra nsfer the DCs to the industry. In a ddition, such studies help us to obta in insights for the development of proposa ls tha t fa cilita te the a doption of the DCs in softwa re projects. 7 Final Considerations This pa per presented resea rch ca rried out with the a im of tra nsferring the DCs to the softwa re industry. We explored the DCs concerning the pra ctitioners’ perception a bout the DCs a s supports in the reflexion of them a s producers, in a first study, a nd a specific softwa re development tea m about the risks in softwa re a rtifa cts tha t ca used miscommunication with supports of the DCs, in the second study. From the first study, the results showed tha t the DCs supported pa rticipa nts to reflect on the system, reducing possible inconsistencies in the development of the explored a rtifa ct, a UML use ca se. The DCs a lso promoted the pa rticipa nts’ reflection on their communica tion with the others involved in the softwa re development. The reduction of miscommunica tion a lso reduces the introduction of defects, a s a consistent ma pping between risks of miscommunica tion a nd softwa re defects has been perceived. In the second study, from the risks identified in the a rtifa cts used by the softwa re development tea m, producers ma de improvements in the a rtifa cts. With tha t, software development tea ms will be a ble to a dopt the DCs in their projects to improve communica tion via a rt ifa ct. Additiona lly, most of the pa rticipa nts’ perception a bout the DCs were positive. From the studies results, we noticed the need to define some a rtifa cts so tha t pra ctitioners ca n use our proposa l in their projects. We presented in this pa per two procedures that fa cilita te the use of the DCs in softwa re projects. Besides, for the better use of ea ch directiv e, we ha ve proposed checklists. We believe tha t pra ctitioners interested in a dopting our proposa l ca n use them. Rega rding the use of the DCs in these studies, it is possible to infer tha t they were considered fea sible for the softwa re industry. The new studies in the context of softwa re projects ca n provide more evidence on the a pplica tion of the DCs to support producers a bout their communica tion, a iming to reduce the risks of miscommunica tion. As future work, we intend to ca rry out a n observa tional study in different softwa re development tea ms using our proposa l. In this future study, the tea ms will use our a rtifa cts, process a nd checklists, proposed in this pa per, including the eva lua tion of a rtifa cts developed in the ea rly sta ges of the softwa re development process not explored in our studies. In a ddition, we intend to investiga te the softwa re engineers perceptions a bout to include the DCs a s pa rt of the compa ny’s culture rela ted to crea tion of a rtifa cts used a s mea ns of communica tion. Towards to Transfer the Directives of Communicability to Software Projects: Qualitative Studies Lopes et al. 2021 Acknowledgements We a re gra teful for the fina ncia l support from CAPES (fi- na ncing code 001), CNPq (311494/2017-0 e 204081/2018- 1/PDE) a nd FAPEAM (062.00150/2020). References Bra mbilla , M., & Fra terna li, P. (2014). Interaction flow modeling language: Model-driven UI engineering of web and mobile apps with IFML. Morga n Ka ufma nn. Bordin, S., & De Angeli, A. (2016). Foca l Points for a more User-Centered Agile Development. International Con- ference on Agile Software Development , 3-15. Corbin, J., & Stra uss, A. (2014). Basics of qualitative re- search: Techniques and procedures for developing grounded theory. Sa ge publica tions. De Souza , C. S. (2005). The semiotic engineering of hu- man-computer interaction. MIT press. De Souza , C. S., Cerqueira , R. D. G., Afonso, L. M., Bra ndã o, R. D. M., & Ferreira , J. S. J. (2016). Software De- velopers as Users. Cha m: Springer Interna tional Publishing. Freire, E. S. S., Oliveira , G. C., & de Sousa Gomes, M. E. (2018). Ana lysis of open-source CASE tools for support- ing softwa re modeling process with UML. In Proceedings of the 17th Brazilian Symposium on Software Quality, 51-60. Gra nda , M. F., Condori-Ferná ndez, N., Vos, T. E., & Pa stor, O. (2015). Wha t do we know a bout the defect types detected in conceptua l models? In 2015 IEEE 9th Interna- tional Conference on Research Challenges in Information Science (RCIS), 88-99. Grice, Herbert P. Logic a nd conversa tion. Speech acts. Brill, 1975. 41-58. Ja kobson, R. (1960). Linguistics a nd poetics. In Style in language. MA: MIT Press, 350-377. Kä fer, V. (2017). Summa rizing softwa re engineering communica tion a rtifacts from different sources. In Proceed- ings of the 2017 11th Joint Meeting on Foundations of Soft- ware Engineering, 1038-1041. Likert, R. (1932). A Technique for the Mea surement of Attitudes. Archives of Psychology, 144 (55), 7-10. Lopes, A., Oliveira , E., Conte, T., & de Souza , C. S. (2019a ). Directives of communica bility: towa rds better com- munica tion through softwa re models. In 2019 IEEE/ACM 12th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE), 45-48. Lopes, A., Conte, T., & de Souza , C. S. (2019 b). Reduc- ing the risks of communica tion fa ilures through software models. In Proceedings of the 18th Brazilian Symposium on Human Factors in Computing Systems, 1-10. Lopes, A., Conte, T., & de Souza , C. S. (2020). Explor- ing the Directives of Communica bility for Improving the Qua lity of Softwa re Artifa cts. In Proceedings of the XIX Brazilian Symposium on Software Quality (SBQS’20), 10 pa ges. Lopes, A., Conte, T., & de Souza , C. S. (2021). Direc- tives of Communica bility: Towa rds Softwa re Development Tea ms. USES Resea rch Group Technica l Report, TR -USES- 2021-01. https://doi.org/10.6084/m9.figsha re.15057984.v2 Ma ra ngunić, N., & Gra nić, A. (2015). Technology a c- cepta nce model: a litera ture review from 1986 to 2013. Uni- versal access in the information society, 14(1), 81-95. OMG. (2011). Business process model a nd nota tion (BPMN) version 2.0. Object Management Group, 1(4). OMG. (2015). Unified Modeling La ngua ge TM (UML) Version 2.5. Petre, M. (2013). UML in pra ctice. In Proceedings of the 2013 International Conference on Software Engineering (ICSE 2013), 722-731. Kha re, R., & Ta ylor, R. N. (2004). Extending the repre- senta tiona l sta te tra nsfer (rest) a rchitectura l style for decen- tra lized systems. In Proceedings of the 26th International Conference on Software Engineering , 428-437. Sebe, N. (2010). Huma n-centered computing. In Hand- book of ambient intelligence and smart environments, Springer, Boston, MA, 349-370. Schoonewille, H. H., Heijstek, W., Cha udron, M. R., & Kühne, T. (2011). A cognitive perspective on developer comprehension of softwa re design documentation. In Pro- ceedings of the 29th ACM international conference on De- sign of communication, 211-218. Tilley, S. (2009). Documenting softwa re systems with views VI: lessons lea rned from 15 yea rs of resea rch & pra c- tice. In Proceedings of the 27th ACM international confer- ence on Design of communication , 239-244. Venka tesh, V., & Ba la , H. (2008). Technology a c- cepta nce model 3 a nd a resea rch a genda on interven- tions. Decision sciences, 39(2), 273-315. Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Reg- nell, B., & Wesslén, A. (2012). Experimentation in software engineering. Springer Science & Business Media .