Curricular design based in bodies of knowledge: engineering education for the innovation and the industry

Bodies of Knowledge (BOK), contain the relevant knowledge for a disciplines as example Software Engineering (SE), System Information (SI), Information Technology (IT), Computer Science (CS), Medicine, Economics, and others areas of knowledge. BOK describes relevant knowledge for a discipline, and will need show the consensus in the Knowledge Areas (KA), and related disciplines. The development of this consensus is a prerequisite to the adoption of coherent skills development in the education context, and continuing professional programs both in public and private organizations. In this context a systematic mapping study (SMS), it was performed to evaluate quantity and types of primary studies in an area of interest. SMS will be used as the research method within this research. The research method proposed will allow to sort and classify the information referent to the topics of this research. This paper is an attempt to analyze existing proposals on BOK contents, structure, and make a proposal what the kind of contents it should have, and how it should be structured so that this consensus among all parties can be described and best achieved. In the same way the relevance, and useful of the BOK in the curricular design for the innovation, and the industry context is present

Experiences in Using Practitioner’s Checklists to Evaluate the Relevance of Experiments Reported in Requirements Engineering

Background: Requirements Engineering (RE) researchers recognize that for RE methods to be adopted in industry, practitioners should be able to evaluate the relevance of a study to their practice. Kitchenham et al proposed a set of perspective-based checklists, which demonstrated to be a useful instrument for this purpose. Specifically, the checklist from the practitioner’s perspective seems to be a good candidate for evaluating the relevance of RE studies to RE practice. However, little is known about the applicability of the checklist to the area of RE. Moreover, this checklist also requires a greater analysis about its reliability. Aim: The aim of this report is to propose a perspective-based checklist to the RE community that allows evaluating the relevance of experimental studies in RE from the practitioner’s/consultant’s viewpoint. Method: Our research followed an iterative design-science based approach in which we first analyzed the problems with a previously published checklist and developed an operationalized proposal for a new checklist to counter these problems. We performed a reliability evaluation of this new checklist. The research was performed with two practitioners and 24 papers that report experimental results on comprehensibility of software requirements specifications. Results: This report gives first-hand experiences of practitioners in evaluating the relevance of primary studies in RE, by using a perspective-based checklist. With respect to the reliability of the adjusted checklist, 9 of out 19 questions show an acceptable proportion of agreement (between two practitioners). Conclusions: Based on our experience, the contextualization and operationalization of a perspective-based checklist helps to make it more useful for the practitioners. However, to increase the reliability of the checklist, more reviewers are required and more discussion cycles are necessary. Our plan is to involve at least two more practitioners in order to improve the reliability of the practitioner checklist proposed

Systematic reviews in requirements engineering: A tertiary study

© 2014 IEEE. There has been an increasing interest in conducting Systematic Literature Reviews (SLR) among Requirements Engineering (RE) researchers in recent years. However, so far there have been no tertiary studies conducted to provide a comprehensive overview of these published SLR in RE. In this paper we present a tertiary study of SLR that focus solely on RE related topics by following the guidelines of Evidence Based Software Engineering. We have conducted both automated search of major online sources and manual search of the RE and SLR related conferences and journals. Our tertiary study has identified 53 distinct systematic reviews published from 2006 to 2014 and reported in 64 publications. We have assessed the resulting SLR for their quality, and coverage of specific RE related topics thus identifying some gaps. We have observed that the quality of SLR in RE has been decreasing over the recent years. There is a strong need to replicate some of these SLR to increase the reliability of their results for future RE research

DREQUS: an approach for the Discovery of REQuirements Using Scenarios

ABSTRACT: Requirements engineering is recognized as a complex cognitive problem-solving process that takes place in an unstructured and poorly-understood problem context. Requirements elicitation is the activity generally regarded as the most crucial step in the requirements engineering process. The term “elicitation” is preferred to “capture”, to avoid the suggestion that requirements are out there to be collected. Information gathered during requirements elicitation often has to be interpreted, analyzed, modeled, and validated before the requirements engineer can feel confident that a complete set of requirements of a system have been obtained. Requirements elicitation comprises the set of activities that enable discovering, understanding, and documenting the goals and motives for building a proposed software system. It also involves identifying the requirements that the resulting system must satisfy in to achieve these goals. The requirements to be elicited may range from modifications to well-understood problems and systems (i.e. software upgrades), to hazy understandings of new problems being automated, to relatively unconstrained requirements that are open to innovation (e.g. mass-market software). Requirements elicitation remains problematic; missing or mistaken requirements still delay projects and cause cost overruns. No firm definition has matured for requirements elicitation in comparison to other areas of requirements engineering. This research is aimed to improve the results of the requirements elicitation process directly impacting the quality of the software products derived from them

Development of service-oriented architectures using model-driven development : a mapping study

Context: Model-Driven Development (MDD) and Service-Oriented Architecture (SOA) are two challenging research areas in software engineering. MDD is about improving software development whilst SOA is a service-based conceptual development style, therefore investigating the available proposals in the literature to use MDD when developing SOA may be insightful. However, no studies have been found with this purpose. Objective: This work aims at assessing the state of the art in MDD for SOA systems. It mainly focuses on: what are the characteristics of MDD approaches that support SOA; what types of SOA are supported; how do they handle non-functional requirements. Method: We conducted a mapping study following a rigorous protocol. We identified the representative set of venues that should be included in the study. We applied a search string over the set of selected venues. As result, 129 papers were selected and analysed (both frequency analysis and correlation analysis) with respect to the defined classification criteria derived from the research questions. Threats to validity were identified and mitigated whenever possible. Results: The analysis allows us to answer the research questions. We highlight: (1) predominance of papers from Europe and written by researchers only; (2) predominance of top-down transformation in software development activities; (3) inexistence of consolidated methods; (4) significant percentage of works without tool support; (5) SOA systems and service compositions more targeted than single services and SOA enterprise systems; (6) limited use of metamodels; (7) very limited use of NFRs; and (8) limited application in real cases. Conclusion: This mapping study does not just provide the state of the art in the topic, but also identifies several issues that deserve investigation in the future, for instance the need of methods for activities other than software development (e.g., migration) or the need of conducting more real case studies.Peer ReviewedPostprint (author's final draft