1,029 research outputs found
Requirements engineering and continuous deployment
This article summarizes the RE in the Age of Continuous Deployment panel at the 25th IEEE International Requirements Engineering Conference. It highlights two synergistic points (user stories and linguistic tooling) and one challenge (nonfunctional requirements) in fast-paced, agile-like projects, and recommends how to carry on the dialogue.Peer ReviewedPostprint (author's final draft
Recommended from our members
A systematic review of software development cost estimation studies
This paper aims to provide a basis for the improvement of software estimation research through a systematic review of previous work. The review identifies 304 software cost estimation papers in 76 journals and classifies the papers according to research topic, estimation approach, research approach, study context and data set. A web-based library of these cost estimation papers is provided to ease the identification of relevant estimation research results. The review results combined with other knowledge provide support for recommendations for future software cost estimation research, including: 1) Increase the breadth of the search for relevant studies, 2) Search manually for relevant papers within a carefully selected set of journals when completeness is essential, 3) Conduct more studies on estimation methods commonly used by the software industry, and, 4) Increase the awareness of how properties of the data sets impact the results when evaluating estimation methods
Design science, engineering science and requirements engineering
For several decades there has been a debate in the computing sciences about the relative roles of design and empirical research, and about the contribution of design and research methodology to the relevance of research results. In this minitutorial we review this debate and compare it with evidence about the relation between design and research in the history of science and technology. Our review shows that research and design are separate but concurrent activities, and that relevance of research results depends on problem setting rather than on rigorous methods. We argue that rigorous scientific methods separate design from research, and we give simple model for how to do this in a problem-driven way
Recommended from our members
Integration, management and communication of heterogeneous design resources with WWW technologies
Recently, advanced information technologies have opened new pos-sibilities for collaborative designs. In this paper, a Web-based collaborative de-sign environment is proposed, where heterogeneous design applications can be integrated with a common interface, managed dynamically for publishing and searching, and communicated with each other for integrated multi-objective de-sign. The CORBA (Common Object Request Broker Architecture) is employed as an implementation tool to enable integration and communication of design application programs; and the XML (eXtensible Markup Language) is used as a common data descriptive language for data exchange between heterogeneous applications and for resource description and recording. This paper also intro-duces the implementation of the system and the encapsulating issues of existing legacy applications. At last, an example of gear design based on the system is il-lustrated to identify the methods and procedure developed by this research
Defect prediction with bad smells in code
Background: Defect prediction in software can be highly beneficial for
development projects, when prediction is highly effective and defect-prone
areas are predicted correctly. One of the key elements to gain effective
software defect prediction is proper selection of metrics used for dataset
preparation. Objective: The purpose of this research is to verify, whether code
smells metrics, collected using Microsoft CodeAnalysis tool, added to basic
metric set, can improve defect prediction in industrial software development
project. Results: We verified, if dataset extension by the code smells sourced
metrics, change the effectiveness of the defect prediction by comparing
prediction results for datasets with and without code smells-oriented metrics.
In a result, we observed only small improvement of effectiveness of defect
prediction when dataset extended with bad smells metrics was used: average
accuracy value increased by 0.0091 and stayed within the margin of error.
However, when only use of code smells based metrics were used for prediction
(without basic set of metrics), such process resulted with surprisingly high
accuracy (0.8249) and F-measure (0.8286) results. We also elaborated data
anomalies and problems we observed when two different metric sources were used
to prepare one, consistent set of data. Conclusion: Extending the dataset by
the code smells sourced metric does not significantly improve the prediction
effectiveness. Achieved result did not compensate effort needed to collect
additional metrics. However, we observed that defect prediction based on the
code smells only is still highly effective and can be used especially where
other metrics hardly be used.Comment: Chapter 10 in Software Engineering: Improving Practice through
Research (B. Hnatkowska and M. \'Smia{\l}ek, eds.), pp. 163-176, 201
ArchOptions: A Real Options-Based Model for Predicting the Stability of Software Architectures
Architectural stability refers to the extent an architecture is flexible to endure evolutionary changes in stakeholders\' requirements and the environment. We assume that the primary goal of software architecture is to guide the system\'s evolution. We contribute to a novel model that exploits options theory to predict architectural stability. The model is predictive: it provides \"insights\" on the evolution of the software system based on valuing the extent an architecture can endure a set of likely evolutionary changes. The model builds on Black and Scholes financial options theory (Noble Prize wining) to value such extent. We show how we have derived the model: the analogy and assumptions made to reach the model, its formulation, and possible interpretations. We refer to this model as ArchOptions
- …