26224ab4184a136f282-4b5b 20221231045023864 beie:beie director@blueeyesintelligence.org WEB-FORM International Journal of Recent Technology and Engineering (IJRTE) IJRTE 22773878 10.35940/ijrte.2277-3878 https://www.ijrte.org/ 01 30 2023 11 5 Information Technology, Institute of Public Enterprise, Survey No. 1266, Shamirpet (V&M), Medchal, Malkajgiri district, Hyderabad (Telangana), India. A. Rakesh Phanindra https://orcid.org/0000-0003-1712-3894 Dr. V. B. Narasimha Assistant Professor, Department of Computer Science and Engineering, University College of Engineering, Osmania University, Hyderabad (Telangana), India. It can be hard to guess how much data will need to be put into the data warehouse when the whole history of the transaction system is moved there. This is especially true when the transfer process could take weeks or even months. The ETL system's parts must be broken down into its three independent stages, nevertheless, when estimating a big starting load. Data extraction from source systems, Creating the dimensional model from data, Loading the data warehouse and timing estimates for the extraction process. Surprisingly, data extraction from the source system may take up the majority of the ETL procedure. Online transaction processing (OLTP) systems are simply not built to return those massive data sets from the data warehouse's historic load, which extracts a tremendous quantity of data in a single query. However, the daily incremental loads and the breath-of-life historic database loads are very different. In any case, fact-table filling requires data to be pulled in a different way than what transaction systems are able to do. ETL extraction procedures frequently call for time-consuming techniques like views, cursors, stored procedures, and correlated subqueries. It is essential to anticipate how long an extract will take to begin before it does. Calculating the extract time estimate is challenging. Due to the hardware mismatch between the test and production servers, estimates based on the execution of the ETL operations in the test environment may be greatly distorted. Sometimes working on certain projects where an extract task would run continuously and until it eventually failed, at which point it would be restarted and run once more until it failed. Without producing anything, days or even weeks passed. One must divide the extract process into two simpler steps in order to overcome the challenges of working with large amounts of data. Response time for queries. the interval between when the query is conducted and when the data starts to be returned. It is pertinent that effort arrival for ETL Operations for Data Marts and DWH projects in terms of Function Points which is a scientific way is essential. In the last paper, I have talked about general System Characteristics to arrive at Value Adjustment Factor. In this paper, I came up with results. I compared my findings with the conventional FPA on industrial projects in order to evaluate the Function Point Analysis’s suitability for Data Mart projects. I outline the strategy, implementation, and outcomes analysis of this validation in this section. 01 30 2023 53 57 CC BY-NC-ND 4.0 10.35940/BEIESP.CrossMarkPolicy www.ijrte.org true No, I did not receive. 10.35940/ijrte.E7357.0111523 https://www.ijrte.org/portfolio-item/E73570111523/ Assistant Professor, Department of Information Technology, Maturi Venkata Subba Rao (MVSR) Engineering College, Osmania University, Hyderabad (Telangana), India. Sowjanya Jindam https://orcid.org/0000-0001-6959-2110 Sai Teja Challa Student, Department of Information Technology, Maturi Venkata Subba Rao (MVSR) Engineering College, Osmania University, Hyderabad (Telangana), India. Sai Jahnavi Chada Student, Department of Information Technology, Maturi Venkata Subba Rao (MVSR) Engineering College, Osmania University, Hyderabad (Telangana), India. Navya Sree B, B Student, Department of Information Technology, Maturi Venkata Subba Rao (MVSR) Engineering College, Osmania University, Hyderabad (Telangana), India. Srinidhi Malgireddy Student, Department of Information Technology, Maturi Venkata Subba Rao (MVSR) Engineering College, Osmania University, Hyderabad (Telangana), India. During software development and maintenance, predicting software bugs becomes critical. Defect prediction early in the software development life cycle is an important aspect of the quality assurance process that has received a lot of attention in the previous two decades. Early detection of defective modules in software development can support the development team in efficiently and effectively utilizing available resources to provide high-quality software products in a short amount of time. The machine learning approach, which works by detecting hidden patterns among software features, is an excellent way to identify problematic modules. The software flaws in NASA datasets MC1, MW1, KC3, and PC4 are predicted using multiple machine learning classification algorithms in this work. A new model was developed based on altering the parameters of the previous XGBoost model, including N_estimator, learning rate, max depth, and subsample. The results were compared to those obtained by state-of-the-art models, and our model outperformed them across all datasets. 01 30 2023 58 65 CC BY-NC-ND 4.0 10.35940/BEIESP.CrossMarkPolicy www.ijrte.org true Not funding. No conflicts of interest are observed to the best of my knowledge. The article does not require ethical approval and consent to participate. Dataset that is used in this project is available at https://www. kaggle.com/datasets/aczy156/ nasa-software-defect-prediction All authors have equal participation in this article. 10.35940/ijrte.E7421.0111523 https://www.ijrte.org/portfolio-item/E74210111523/