The cloud paradigm: Are you tuned for the lyrics?

Major players, business angels and opinion-makers are broadcasting beguiled lyrics on the most recent IT hype: your software should ascend to the clouds. There are many clouds and the stake is high. Distractedly, many of us became assiduous users of the cloud, but perhaps due to the legacy systems and legacy knowledge, IT professionals, mainly those many that work in business information systems for the long tail, are not as much plunged into producing cloud-based systems for their clients. This keynote will delve into several aspects of this cloud paradigm, from more generic concerns regarding security and value for money, to more specific worries that reach software engineers in general. Do we need a different software development process? Are development techniques and tools mature enough? What about the role of open-source in the cloud? How do we assess the quality in cloud-based development? Please stay tuned for more!Comment: Position paper to introduce a keynote, proceedings of WAMPS'2011 - VI Annual MPS.BR Workshop, pp. 20-25, Campinas, Brazil, October 201

Quantitative Methods in Object-Oriented Software Engineering

This paper includes a brief description of the author’s doctoral research work in Quantitative Methods applied to the Object-Oriented Software Engineering field. Previous, current and future research work are outlined. An overview of related work is also included

Object-Oriented Software Design Metrics

The adoption of the Object-Oriented paradigm is expected to help produce better and cheaper software. The main concepts of this paradigm, namely, inheritance, encapsulation, information hiding or polymorphism, are the keys to foster reuse and achieve easier maintainability. However, the use of constructs that support those concepts can be more or less intensive, mainly depending on the designer ability. Advances in quality and productivity need to be correlated with the use of those constructs. Therefore, we need to evaluate them quantitatively to guide OO design. The availability of these metrics should allow comparison of different systems or different implementations of the same system, thus helping to derive some design heuristics that could/should be included in design tools. Those heuristics would at least be a valuable help to new staff members. "Blind" choice (or creation) is dangerous, so a set of common requirements for metrics and corresponding rationale was introduced, which includes the need for formal definition, language independence, dimensionlessness, ease of calculation and early obtainability. A suitable metrics set named MOOD was then proposed. We believe that these metrics can help in setting OO design standards at the organization level, helping OO practitioners to guide their development process and, hopefully, leaving them in a cheerful MOOD..

Software evolution prediction using seasonal time analysis: a comparative study

Prediction models of software change requests are useful for supporting rational and timely resource allocation to the evolution process. In this paper we use a time series forecasting model to predict software maintenance and evolution requests in an open source software project (Eclipse), as an example of projects with seasonal release cycles. We build an ARIMA model based on data collected from Eclipse’s change request tracking system since the project’s start. A change request may refer to defects found in the software, but also to suggested improvements in the system under scrutiny. Our model includes the identification of seasonal patterns and tendencies, and is validated through the forecast of the change requests evolution for the next 12 months. The usage of seasonal information significantly improves the estimation ability of this model, when compared to other ARIMA models found in the literature, and does so for a much longer estimation period. Being able to accurately forecast the change requests’ evolution over a fairly long time period is an important ability for enabling adequate process control in maintenance activities, and facilitates effort estimation and timely resources allocation. The approach presented in this paper is suitable for projects with a relatively long history, as the model building process relies on historic data

Evolution, survival and anomalies

Rio, A., & Abreu, F. B. E. (2023). PHP code smells in web apps: Evolution, survival and anomalies. Journal of Systems and Software, 200, 1-23. [111644]. https://doi.org/10.1016/j.jss.2023.111644Abstract Context: Code smells are symptoms of poor design, leading to future problems, such as reduced maintainability. Therefore, it becomes necessary to understand their evolution and how long they stay in code. This paper presents a longitudinal study on the evolution and survival of code smells (CS) for web apps built with PHP, the most widely used server-side programming language in web development and seldom studied. Objectives: We aimed to discover how CS evolve and what is their survival/lifespan in typical PHP web apps. Does CS survival depend on their scope or app life period? Are there sudden variations (anomalies) in the density of CS through the evolution of web apps? Method: We analyzed the evolution of 18 CS in 12 PHP web applications and compared it with changes in app and team size. We characterized the distribution of CS and used survival analysis techniques to study CS’ lifespan. We specialized the survival studies into localized (specific location) and scattered CS (spanning multiple classes/methods) categories. We further split the observations for each web app into two consecutive time frames. As for the CS evolution anomalies, we standardized their detection criteria. Results: The CS density trend along the evolution of PHP web apps is mostly stable, with variations, and correlates with the developer’s numbers. We identified the smells that survived the most. CS live an average of about 37% of the life of the applications, almost 4 years on average in our study; around 61% of CS introduced are removed. Most applications have different survival times for localized and scattered CS, and localized CS have a shorter life. The CS survival time is shorter and more CS are introduced and removed in the first half of the life of the applications. We found anomalies in the evolution of 5 apps and show how a graphical representation of sudden variations found in the evolution of CS unveils the story of a development project. Conclusion: CS stay a long time in code. The removal rate is low and did not change substantially in recent years. An effort should be made to avoid this bad behavior and change the CS density trend to decrease.publishersversionepub_ahead_of_prin

Model-Driven Service Level Management

Abstract. Service-level agreements (SLA) definition and monitoring are open issues within the IT Service Management (ITSM) domain. Our main goals are to propose a model-based approach to IT services SLA specification and compliance verification. The specification part will be accomplished by proposing a SLA language -a domain specific language (DSL) for defining quality attributes as non functional requirements (NFRs) in the context of ITSM. Its metamodel will be an extension of the meta-model of an adopted process modeling language for IT services. As such, it will be possible to ground SLA definition on the corresponding IT service model constructs. This will allow that SLA monitoring and compliance validation could occur at a level of abstraction that is understood by all the stakeholders involved in the service specification

From Objects to Components: a Quantitative Approach

Abstract. Component based software development (CBD) is increasingly becoming a de facto approach to software development. Most software professionals were originally trained to build software using another paradigm, such as the object orientation (OO) paradigm, or the structured programming one. To face the trend to CBD, software professionals are required to make a paradigm shift. Such a shift incurs in considerable costs. This paper describes an experiment where part of a legacy software application built with the OO paradigm was transformed into a software component, using three different technologies (Object Pascal, C++ and Java). In this experiment, we were concerned not only with the qualitative aspects of the problems dealt with by a software professional in this transformation, but mostly with some quantitative ones. In particular, we compared the effort required to make such transformations with each of the technologies. The subject performing the experiment was at ease with all the involved OO languages, but not with the component models supported by the used platforms