Process and progress of requirement formalization in Software Engineering

Abstract

Since the middle of the last century was initiated the research in formal methods and was presented proposals and methodologies to apply them in software development. The idea was overcome the diagnosed software crisis through the materialization of the life cycle of this product development. In this article is presented the results of a revision of the literature, about progress and develop the requirement formalization. The conclusion is that both are slow: there is not enough interest in the industry, the academy does not train in formal methods, and there is no sponsorship for this research field, professionals fear mathematics and traditional methodologies of software engineering are still the most used in development teams. Due to the quality efficiency, software security and reliability, it is necessary to reactivate the research and experimentation with all the formal methods, because the hope is that mathematics will be the toll with which the crisis promulgated in the 60s is overcome.

Validation of an Instrument to Assess Deductive Reasoning in Solving Types of Problems

“…In the present study, in order to solve a mathematical problem, students must not only perform the necessary mathematical operations but also bring into play knowledge that promotes argumentation. Therefore, it was Validation an Instrument to Assess Deductive Reasoning in Solving Types of Problems assumed that one of the shortcomings of engineering students is related to the lack of activities in their curricular training that involve reasoning and abstraction skills, agreeing in this regard with several authors [41], [3][4].…”

“…The real evidence of the absence of certain types of arguments has been revealed in research on engineering education, which indicates that they do not make use of logical arguments despite being trained in them as part of mathematical reasoning, which may lead them to make wrong decisions in the future as engineering graduates [41]. Instead of learning broad content knowledge in individual subjects, students should be equipped with more general thinking skills to manage information [42].…”

Validación y verificación de requisitos de software en proyectos basados en desarrollo continuo usando técnicas de PLN

“…Para (Bruel et al, 2021) es claro en que los mecanismos que se utilicen deben permitir la interacción de expertos de domino, que no son expertos en requisitos, con el desarrollador. Según (Serna M. & Serna A., 2020) uno de los problemas de mayor importancia radica en que la escritura de los requisitos en lenguaje natural no son insumos para la verificación y la validación de técnicas automatizadas.…”

“…El objetivo de este trabajo está direccionado hacia la búsqueda del enriquecimiento de las técnicas estadísticas en el PLN a través de un sistema de reglas de dominio que se convierta en la base de un lenguaje común que describa las interrelaciones del proyecto pero que sea ajustado a la semántica de un lenguaje específico de dominio; de esta manera se permite conservar los atributos de la formulación de los requisitos, minimizando las ambigüedades del lenguaje natural pero además se propone la automatización a través de la creación de artefactos que permitan hacer el rastreo del requisito en todas las etapas del desarrollo desde su levantamiento hasta el testeo aportando de esta manera a una posible solución en el tratamiento de estos en la práctica de la Ingeniería de Software. (Shankar et al, 2020) establece como crítica la actividad de levantamiento de los requisitos dado que de ahí deriva no solo el diseño sino las funcionalidades y las características que se desean encontrar en el producto terminado; asimismo, este diseño debe contar con objetivos y restricciones, pues toda esta información se documentará como soporte a las especificaciones del software (Serna M. & Serna A., 2020).…”

Semiotics: An Approach to Model Security Scenarios for IoT-Based Agriculture Software

“…Requirements engineering involves collaboration between clients and development teams in order to incorporate the right features into the finished product [4]. Inconsistencies between initial requirements and the final product could lead to reengineering processes, increasing the project's scope and cost of the project [5]. Requirements engineering works with two types of knowledge: explicit and tacit [6].…”