Software engineering (SE) teaching includes different strategies such as project-based learning, collaborative learning, simulations, and case methods, among others, seeking to balance theory and practice and encourage teamwork. However, although some repositories of teaching practices are identified, each SE teacher incorporates different strategies/practices either barely documented or subjectively represented. The latter hinders the transfer of knowledge among the software engineering education community. Therefore, in this paper we propose SETMAT (Software Engineering Teaching Methods and Theory), a descriptive theory of SE education offering a common conceptual framework for representing software engineering teaching practices, and we also describe a pilot with teachers from Colombia, Chile, and Mexico where they represented and socialized their SE teaching practices in SETMAT. This pilot proves the usage of SETMAT for representing teaching practices easies comparison, composition, and transferring such practices. This poses an input of interest for SE education.

Software architecture evaluation (SAE) is a key area in software architecture design. Some of its key challenges are describing and assessing the architecture itself, the architectural decisions, the business or mission goals, and the quality attributes; and further, the adoption itself of SAE practices. The lack of a standard representation for SAE endeavors hampers its adoption by development teams, its (semi-)automated support by tool providers, and its normative assessment by process specialists. In this paper we introduce SAEMET (Software Architecture Evaluation MEthod and Theory), an extension of the Essence standard proposed by SEMAT and adopted by OMG; The Essence kernel defines “things” (called Alphas) any software engineering endeavor should include, and provides an extensible representation to be used for assessing an endeavor progression. SAEMET includes five sub-alphas (Quality Attributes, Business Goals, Architecture Description, Architecture Decision, and Evaluation Adoption), and provides a complete description for each one, their progression levels, and the relationships among them. Our approach is useful for representing an already published architecture review, conducted using DCAR (Decision-Centric Architecture Review method), and assessing its suitability for actionable support of adoption, automated support, and normative assessment. Ongoing empirical evaluation of SAEMET is underway, and early results indicate it is usable and useful for guiding and auditing SAE endeavor, as well as planning courses to train teams for adopting SAE.

Abstract Requirements elicitation is a stakeholder-centered approach; therefore, natural language remains an effective way of documenting and validating requirements. As the scope of the software domain grows, software analysts process a higher number of requirements documents, generating delays and errors while characterizing the software domain. Natural language processing is key in such a process, allowing software analysts for speeding up the requirements elicitation process and mitigating the impact of the ambiguity and misinterpretations coming from natural-language-based requirements documents. However, natural-language-processing-based proposals for requirements elicitation are mainly focused on specific domains and still fail for understanding several requirements writing styles. In this paper, we present QUARE, a question-answering model for requirements elicitation. The QUARE model comprises a meta-ontology for requirements elicitation, easing the generation of requirements-elicitation-related questions and the initial structuration of any software domain. In addition, the QUARE model includes a named entity recognition and relation extraction system focused on requirements elicitation, allowing software analysts for processing several requirements writing styles. Although software analysts address a software domain at a time, they use the same kind of questions for identifying and characterizing requirements abstractions such as actors, concepts, and actions from a software domain. Such a process may be framed into the QUARE model workflow. We validate our proposal by using an experimental process including real-world requirements documents coming from several software domains and requirements writing styles. The QUARE model is a novel proposal aimed at supporting software analysts in the requirements elicitation process.

A state-of-the-art review about the SEMAT Essence standard includes some games and workshops in order to simulate and remember a small set of the elements of such a standard. Alphas and states are the most common elements. For this reason, in this paper we propose a board game to simulate most of the elements belonging to the SEMAT Essence standard. We also apply this game to university students and we summarize the results. Even though the game is a little complex, the players are satisfied with the results, since the game provides a good idea about the usage of the different elements of the SEMAT Essence standard.

This study is aimed to validate a text processing architecture for knowledge acquisition and analyze the performance of several populations under controlled validation studies by focusing on empirical methods. We report our experience by analyzing three case studies whose performance issues have been addressed by using a proposed natural-language-mapping model. We discuss the advantages and the disadvantages of an automated prototype for implementing such architectural model, compared with a by-hand one. We compare the cases running out on the prototype in order to identify the suitable features the software systems should have. The final goal of the validation process is describing an ongoing research work concerned with the definition of an approach to automate processes for knowledge extraction in requirements engineering. Some of achieved findings of the performance analysis are: (i) the approach can be applied to business-based technical documents regardless of the organizational process involved; (ii) the activities related to the domain understanding can be executed in a low-costs process; and (iii) empirical methods can be used in controlled validation studies for knowledge extraction approaches.

Interoperability is commonly referred as a software quality sub-characteristic. Some proposals for formalizing interoperability include sets of concepts linked to this phenomenon. Such concepts differ among the proposals, resulting in a different terminology for referring to the same thing. Non-unified terminology of interoperability concepts exhibits three main problems: homonymy, synonymy and missing concepts. Due to such problems, crucial aspects of the interoperability process could be either misunderstood or just omitted, resulting in an ambiguous and incomplete description of interoperability. To solve these problems, we propose a terminology unification of interoperability concepts. This unification is based on published studies about the interoperability formalization. Results lead us to recognize six main concepts useful to unify the interoperability vocabulary.

Requirements Elicitation (RE) is a complex process that involves seeking, uncovering, capturing, and elaborating requirements in the software development process. Background Reading (BR) is a scarcely used technique for capturing software requirements. BR is an analytical method which uses existing documents as a source for RE. Although the usage of technical documentation as a source for the requirements elicitation process is accepted, discussed, or even listed by several authors, they establish neither specific techniques nor detailed instructions for applying BR. In this sense, we propose a method as an initial approach for using the BR technique in the context of the RE process. In this method we describe how an analyst uses a document as a source for the requirements elicitation process, by extracting domain knowledge and business information. The proposal is based on a specific type of technical document (procedure manual), which is structured in a formal language.