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.

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.