Towards understanding software: 15 years in the SEL

For 15 years, the Software Engineering Laboratory (SEL) at GSFC has been carrying out studies and experiments for the purpose of understanding, assessing, and improving software, and software processes within a production software environment. The SEL comprises three major organizations: (1) the GSFC Flight Dynamics Division; (2) the University of Maryland Computer Science Department; and (3) the Computer Sciences Corporation Flight Dynamics Technology Group. These organizations have jointly carried out several hundred software studies, producing hundreds of reports, papers, and documents: all describing some aspect of the software engineering technology that has undergone analysis in the flight dynamics environment. The studies range from small controlled experiments (such as analyzing the effectiveness of code reading versus functional testing) to large, multiple-project studies (such as assessing the impacts of Ada on a production environment). The key findings that NASA feels have laid the foundation for ongoing and future software development and research activities are summarized

18P. CMMI (SW, DEV, SVC) Compliance of SDLCs:

In this paper a high-level strategic conceptual assessment on the extent of compliance of the three main Software Development Lifecycles (SDLCs) - STD, RUP, and MSF-CMMI, with three of the main CMMI schemes (SW, DEV, and SVC) is reported. While that the SDLCs theme is a permanent and shared topic in information systems and software engineering research, however, the compliance of SDLCs with IT standards has been few explored. Our research goal is to establish an initial high-level strategic assessment on how the most usual SDLCs satisfy three of the main CMMI schemes. Compliance analysis is based on: (i) previous results reported in literature, (ii) a comparison of the CMMI specific goals of each process area versus the generic SDLCs core workflows descriptions, and (iii) joint academic and research expertise in SW standards from authors. This paper contributes an initial assessment which should be considered from a strategic view due to the coarse unit of analysis. A finer grain analysis in the level of SLDCs’ workflows and activities versus CMMI’s specific practices and typical work products is suggested

Assessing data analysis performance in research contexts: An experiment on accuracy, efficiency, productivity and researchers' satisfaction

[EN] Any knowledge generation process involves raw data comprehension, evaluation and inferential reasoning. These practices, common to different disciplines, are known as data analysis, and represent the most important set of activities in research contexts. Researchers use data analysis software methods and tools for generating new knowledge in their daily data analysis. In recent years, data analysis software has been incorporating explicit references in modelling of cognitive processes, in order to improve the assistance offered in data analysis tasks. However, data analysis software commercial suites are still resisting this inclusion, and there is little empirical work done in knowing more about how cognitive aspects inclusion in software helps researchers in analyzing data. In this paper, we evaluate the impact produced by the explicit inclusion of cognitive processes in the assistance logic of software tools design and development. We conducted an empirical experiment comparing data analysis performance using traditional software versus data analysis performance using software-assistance tools which incorporate cognitive processes in their design. The experiment is designed in terms of accuracy, efficiency, productivity and user satisfaction during the data analysis made by researchers. It allowed us to find some clear benefits of the cognitive inclusion in the software designed for research contexts, with statistically significant differences in terms of accuracy, productivity and researcher's satisfaction in support of this explicit inclusion, although some efficiency weaknesses are detected. We also discuss the implications of these results for the priority of cognitive inclusion in the software tools design for research contexts data analysis.This paper has the support of Generalitat Valenciana through project IDEO (PROMETEOII/2014/039) and Spanish Ministry of Science and Innovation through project DataME (ref: TIN2016-80811-P).Martín-Rodilla, P.; Panach Navarrete, JI.; González-Pérez, CA.; Pastor López, O. (2018). Assessing data analysis performance in research contexts: An experiment on accuracy, efficiency, productivity and researchers' satisfaction. Data & Knowledge Engineering. 116:177-204. https://doi.org/10.1016/j.datak.2018.06.003S17720411

The (mis)use of subjective process measures in software engineering

A variety of measures are used in software engineering research to develop an understanding of the software process and product. These measures fall into three broad categories: quantitative, characteristics, and subjective. Quantitative measures are those to which a numerical value can be assigned, for example effort or lines of code (LOC). Characteristics describe the software process or product; they might include programming language or the type of application. While such factors do not provide a quantitative measurement of a process or product, they do help characterize them. Subjective measures (as defined in this study) are those that are based on the opinion or opinions of individuals; they are somewhat unique and difficult to quantify. Capturing of subjective measure data typically involves development of some type of scale. For example, 'team experience' is one of the subjective measures that were collected and studied by the Software Engineering Laboratory (SEL). Certainly, team experience could have an impact on the software process or product; actually measuring a team's experience, however, is not a strictly mathematical exercise. Simply adding up each team member's years of experience appears inadequate. In fact, most researchers would agree that 'years' do not directly translate into 'experience.' Team experience must be defined subjectively and then a scale must be developed e.g., high experience versus low experience; or high, medium, low experience; or a different or more granular scale. Using this type of scale, a particular team's overall experience can be compared with that of other teams in the development environment. Defining, collecting, and scaling subjective measures is difficult. First, precise definitions of the measures must be established. Next, choices must be made about whose opinions will be solicited to constitute the data. Finally, care must be given to defining the right scale and level of granularity for measurement

The state of the art of PSP and the Software Industry

Medir el esfuerzo de las personas dedicadas al desarrollo de software ha sido visto muy poco en la ingeniería de software, el SEI propuso un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la productividad personal de los programadores o ingenieros de software en las tareas de desarrollo y mantenimiento de software, mediante el seguimiento del desempeño planeado frente al desempeño real, al que lo denomino Personal Software Process (PSP) (Humphrey, 2000) por Watts Humphrey en los años 90s. Las investigaciones que se revisaron muestran que a nivel mundial las habilidades con las que los ingenieros van a la industria de la ingeniería de software no cubren las expectativas de la industria, y como PSP es parte de este fortalecimiento de habilidades.The measurement of efforts made by people engaged in software development has been hardly done in software engineering. The SEI proposes a set of practices for time management and personal productivity improvement of programmers or software engineers for software development and maintenance tasks, by monitoring and comparing the planned performance versus actual performance, which Watts Humphrey in the 90s named the Personal Software Process (PSP). The research that were reviewed show that, at a global level, the skills of engineers who join the software industry do not satisfy software industry expectations, and how PSP contributes to skills enhancement

Understanding and improving requirements discovery in open source software development: an initial exploration

In proprietary or closed source software (CSS) development, there is a formal requirements engineering (RE) phase for discovering the requirements for an application. The requirements engineering process in CSS development is comprised of many formal practices (e.g., elicitation/generation). With the advent of the Internet and web-based tools and technologies, a new and different form of software development has emerged – globally distributed, typically volunteer driven, open source software (OSS) development. OSS development largely occurs in an informal, ad hoc manner and often lacks the formal developmental practices and processes of CSS development. The goal of this research is to gain a better understanding of the current state of RE in OSS, to identify potential directions for improving RE in OSS, and to empirically investigate the potential of some specific RE practices to improve OSS development. In pursuit of the research goal, in the initial phase of this research a web-based survey of practicing OSS developers was conducted to explore the current state of RE in OSS. Results supported the claims about informality of RE in OSS. as well as pointed towards potential directions for improvement. In the second phase of the research, a web-based experiment was conducted to investigate the actual benefits from a particular CSS development requirements generation practice – requirements reuse (operationalized as the availability of a library of reusable requirements within OSS development environment) – for OSS development. Analysis of the experimental data revealed that that the experimental treatment (availability of a library of reusable requirements) had a significant effect on the size of requirements message, requirements quantity and requirements completeness after controlling for covariates, indicating usefulness of the reusable library. The final phase of the research focused on OSS issue gathering approaches, a source of requirements for OSS. In this phase, a qualitative study of OSS developers explored how an OSS issue gathering approach, enforcing classification (versus free-form OSS issue gathering), may contribute to the misclassification problem (erroneous classification of OSS issues), and what can be done at the issue gathering interface level to mitigate the misclassification problem. Insights from the analysis of data from the final phase of the research shed light on the desirable characteristics that OSS issue gathering interfaces should possess for mitigating misclassification

Culture dimensions in software development industry: The effects of mentoring

Software development is a human centric and sociotechnical activity and like all human activities is influenced by cultural factors. However, software engineering is being further affected because of the globalization in software development. As a result, cultural diversity is influencing software development and its outcomes. The software engineering industry, a very intensive industry regarding human capital, is facing a new era in which software development personnel must adapt to multicultural work environments. Today, many organizations present a multicultural workforce which needs to be managed. This paper analyzes the influence of culture on mentoring relationships within the software engineering industry. Two interesting findings can be concluded from our study: (1) cultural differences affect both formal and informal mentoring, and (2) technical competences are not improved when implementing mentoring relationships

Software Sustainability: The Modern Tower of Babel

<p>The aim of this paper is to explore the emerging definitions of software sustainability from the field of software engineering in order to contribute to the question, what is software sustainability?</p