Early effort estimation is both essential and challenging in software development projects. Accurate effort estimation mainly relies on accurate software sizing. COSMIC Function Point (CFP) is a means for measuring the functional size of software. It is a standardized method that can be applied to obtain size measurements based on early artifacts such as the software architecture design. In this paper, we present an industrial case study conducted to evaluate the correlation between CFP measurements performed at the architecture design phase and the actual development efforts. The study is performed in the context of a FinTech company that develops a system comprising a backend, a native iOS application, and a native Android application. We collect CFP calculations that are performed at the architecture design phase of the corresponding project. We also collect measurements regarding the actual effort for 12 months. Then, we investigate the correlation between CFP calculations and the measured effort. The actual effort can vary for some development tasks that are associated with the same CFP calculations. We analyze the relation of these variations with the level of developer experience and the type of target platform. Our results show that there is a significant correlation between size estimations made with CFP and the actual effort. The variance in effort per CFP among varying types of platforms is statistically significant. We also observe variance in effort per CFP among developers of varying expertise levels.

Abstract There have been success stories reported regarding the adoption of agile software development methods in the industry. There also exist observations on their limitations. One of these limitations is scalability since agile methods like Scrum were originally designed for small software teams. Scalable agile frameworks were introduced to address this limitation. We conducted an industrial case study on the adoption of such a framework, called Nexus. Our study involves quantitative and qualitative evaluation based on observations within a product development organization over a period of 12 months. Scrum is used for the development of a product during the first 6 months of this period. Nexus is used in the remaining 6 months. Data are collected throughout the whole period for measuring productivity, quality, and team member motivation. Results suggest a significant increase in productivity and product quality after switching to Nexus. Team motivation was slightly improved as well.

Architectural refactoring requires substantial effort. We introduce an approach and a tool to predict this effort prior to refactoring. We focus on PL/SQL programs that are developed as data access tiers of business software. There are two types of common refactoring needs for these programs. First, some of the modules might need to be migrated to a separate database. Second, some of the modules in the data tier might need to be migrated to the application tier. In both cases, the refactoring effort is proportional to the amount of coupling between the migrated modules and the rest of the modules in the database. Our tool can parse PL/SQL programs to reveal this coupling based on an analysis of SQL queries. Unlike prior studies, our tool can analyze queries that are created dynamically and that use multiple tables as well as PL/SQL-specific features. We evaluate our approach with an industrial PL/SQL program from the telecommunications domain. Our results are approved to be accurate by domain experts.