Software Size Research Articles

Small implementation of decision-making policy for the height task of the Acrobot

Since decision-making algorithms on high-performance computing yield large-size policies, compression methods are necessary for utilizing them on small robots or on robots that must store a number of policies for various tasks. A height task of the Acrobot, which is a well-known problem, is solved by value iteration and its decision-making policy is compressed to the utmost limit in this paper. From the result, we discuss the availability of brute force approach under severe limitations of memory available on robots. We have obtained a 7060 bit policy using vector quantization and run-length encoding from a policy on a 60,484,176 bit look-up table though the table is complicated by the chaotic nature of the Acrobot. Moreover, we have evaluated the size of software for using the compressed policy, and have created a 15,424 bit object code for an ARM processor. The total size 22,752 bit is in the same range with those of policies implemented as several if-then rules or equations coded by hand.

Bootstrap Correlation Analysis of Function Point Elements

This research work investigates the correlation of software function point elements using bootstrap simulation. The correlation of software function point elements plays an important role in understanding the software size; the correlation among function point elements suggests that they measure the same attribute of a software project. Bootstrapping is an effective method to study the statistical properties of correlation coefficients; bootstrap produces a histogram of the possible values of correlation coefficients, which helps to understand the range and spread of the correlation among different function point elements, rater then generating a single point estimate of the correlation.

Key Software Metrics and its Impact on each other for Software Development Projects

Every software development project is unique and different from repeatable manufacturing process. Each software project share different challenges related to technology, people and timelines. If every project is unique, how project manager can estimate project in a consistent way by applying his past experience. One of the major challenges faced by the project manager is to identify the key software metrics to control and monitor the project execution. Each software development project may be unique but share some common metric that can be used to control and monitor the project execution. These metrics are software size, effort, project duration and productivity. These metrics tells project manager about what to deliver (size), how it was delivered in past (productivity) and how long will it take to deliver with current team capability (time and effort). In this paper, we explain the relationship among these key metrics and how they statistically impact each other. These relationships have been derived based on the data published in book "Practical Software Estimation" by International Software Benchmarking Group. This paper also explains how these metrics can be used in predicting the total number of defects. Study suggests that out of the four key software metrics software size significantly impact the other three metrics (project effort, duration and productivity). Productivity does not significantly depend on the software size but it represents the nonlinear relationship with software size and maximum team size, hence, it is recommended not to have a very big team size as it might impact the overall productivity. Total project duration only depends on the software size and it does not depend on the maximum team size. It implies that we cannot reduce project duration by increasing the team size. This fact is contrary to the perception that we can reduce the project duration by increasing the project team size. We can conclude that software size is the important metrics and a significant effort must be put during project initiation phases to estimate the project size. As software size will help in estimating the project duration and project efforts so error in estimating the software size will have significant impact on the accuracy of project duration and effort. All these key metrics must be re-calibrated during the project development life cycle

Key Software Metrics and its Impact on each other for Software Development Projects

<p class="MsoNormal" style="margin: 0in 0in 10pt; text-align: justify;"><span style="line-height: 115%; font-size: 9pt; mso-bidi-font-size: 12.0pt;"><span style="font-family: Calibri;"><span style="mso-spacerun: yes;"><span style="font-size: small;"><span style="line-height: 115%; mso-bidi-font-size: 12.0pt;">Every software development project is unique and different from repeatable manufacturing process. Each software project share different challenges related to technology, people and timelines. If every project is unique, how project manager can estimate project in a consistent way by applying his past experience. One of the major challenges faced by the project manager is to identify the key software metrics to control and monitor the project execution. Each software development project may be unique but share some common metric that can be used to control and monitor the project execution. These metrics are software size, effort, project duration and productivity. These metrics tells project manager about what to deliver (size), how it was delivered in past (productivity) and how long will it take to deliver with current team capability (time and effort). In this paper, we explain the relationship among these key metrics and how they statistically impact each other. These relationships have been derived based on the data published in book “Practical Software Estimation” by International Software Benchmarking Group. This paper also explains how these metrics can be used in predicting the total number of defects. Study suggests that out of the four key software metrics software size significantly impact the other three metrics (project effort, duration and productivity). Productivity does not significantly depend on the software size but it represents the nonlinear relationship with software size and maximum team size, hence, it is recommended not to have a very big team size as it might impact the overall productivity. Total project duration only depends on the software size and it does not depend on the maximum team size. It implies that we cannot reduce project duration by increasing the team size. This fact is contrary to the perception that we can reduce the project duration by increasing the project team size. We can conclude that software size is the important metrics and a significant effort must be put during project initiation phases to estimate the project size. As software size will help in estimating the project duration and project efforts so error in estimating the software size will have significant impact on the accuracy of project duration and effort. All these key metrics must be re-calibrated during the project development life cycle. </span><strong style="mso-bidi-font-weight: normal;"></strong></span></span></span></span></p><p class="MsoNormal" style="margin: 0in 0in 10pt; text-align: justify;"> </p>

Automated COSMIC Function Point measurement using a requirements engineering ontology

ContextThere are two interrelated difficulties in requirements engineering processes. First, free-format modelling practices in requirements engineering activities may lead to low quality artefacts and productivity problems. Second, the COSMIC Function Point Method is not yet widespread in the software industry because applying measurement rules to imprecise and ambiguous textual requirements is difficult and requires additional human measurement effort. This challenge is common to all functional size measurement methods. ObjectiveIn this study, alternative solutions have been investigated to address these two difficulties. Information created during the requirements engineering process is formalized as an ontology that also becomes a convenient model for transforming requirements into COSMIC Function Point Method concepts. MethodA method is proposed to automatically measure the functional size of software by using the designed ontology. The proposed method has been implemented as a software application and verified with real projects conducted within the ICT department of a leading telecommunications provider in Turkey. ResultsWe demonstrated a novel method to measure the functional size of software in COSMIC FP automatically. It is based on a newly developed requirements engineering ontology. Our proposed method has several advantages over other methods explored in previous research. ConclusionManual and automated measurement results are in agreement, and the tool is promising for the company under study and for the industry at large.

Improving Efficiency of Fuzzy Models for Effort Estimation by Cascading & Clustering Techniques

The main challenge in software industry is the process of estimating the cost required for the development or maintenance of a project. Various models have been proposed for constructing a relationship between size of software and its development effort. Various algorithmic cost estimation models exists with their own pros and cons for estimation. Now a days, attention has turned towards Machine learning techniques as few of the problems associated with previous models are being addressed by the soft computing techniques. But, the need for accurate effort estimation in software project management is still a challenge. The literature shows the usage of Fuzzy Logic Controller for Software Effort Estimation, but the computational time is very high as the rulebase is large. The main aim is to reduce the rulebase and improve the efficiency by cascading of Fuzzy Logic Controllers. A case study on NASA 93 dataset is taken for this purpose. The Proposed work is carried out by cascading the Fuzzy Logic Controllers in a stage of two and six for Software Effort Estimation. By increasing the cascading of Fuzzy Logic Controllers, the efficiency has been improved with the minimized size in rulebase. The limitation to this process is to find out the correct number of cascaded Fuzzy Logic Controllers. To overcome this a Fuzzy Model using Subtractive Clustering has been proposed. The rulebase of the models developed by using Subtractive Clustering is further reduced. Considering the rule minimization and the various criteria for assessment, Fuzzy Models developed using Subtractive Clustering provides better software development effort estimates.

A case study for the software size estimation through MK II FPA and FP methods

Software size estimation is one of the most crucial and daunting tasks for a software project manager. It is very important for the accurate planning and calculation of the software project. The importance of software size estimation becomes critical at the beginning of the software life cycle. Software size estimation is a basic input for the software effort and cost estimation. There are many different approaches and various methods for software size estimation up to now such as the function points method, e.g., IFPUG FPA, Mk II FPA, COSMIC FFP. In this paper, the size of the software project was calculated through the function points method and Mark II FPA. The same software project was implemented by different software development teams. Early estimations were performed for the software project and the data obtained as a result of the teams' studies were compared.

COSMIC度量中持久存储器的识别方法

COSMIC方法是当前用于软件规模度量的一种全功能点估算方法。目前，该方法适用的项目很广泛，计数规则也比较简单，易于学习和掌握，已经被更多的软件组织所接受。运用COSMIC度量方法，其中有一项重要工作，就是识别持久存储器，为识别数据移动和计算功能点提供判定依据。但是，由于COSMIC度量手册中仅对识别持久存储器的一些原则和规则进行了规定和说明，有较大的模糊和不确定性，并且没有给出行之有效的操作方法，使得度量人员在实践度量中，存在较大的主观性，由此导致度量结果存在较大偏差。本文在遵循COSMIC度量手册原则和规则的基础上，结合实践度量实验，提出了一种可实施的识别持久存储器的方法步骤。 COSMIC method is a full function point counting method which is currently used for software size measurement. At present, this method’s applicable project is very wide and its counting rules are simple and easy to learn and master. It has been accepted by more and more software organizations. An important job of using the COSMIC measurement is to identify the persistent storage and to provide decision basis to identify the data movement and the calculation function point. However, the COSMIC Functional Size Measurement Method Version only regulates and explains some principles and rules to identify the persistent storage. So, it has lager fuzzy and uncertainty. It also doesn’t give an effective operation method, which makes the measurement personnel have a big subjectivity in the practical measurement. They lead to a great deviation in the measurement results. On the basis of the principles and rules of the COSMIC Functional Size Measurement Method Version, combined with the practical measurement experiment, this paper proposes procedures that can be carried out to identify the persistent storage.

Time series trends in software evolution

AbstractBackgroundThe laws of software evolution were formulated to describe time series trends in software over time.ObjectiveBuilding on econometrics, the paper relates the laws theoretically to the concept of stationarity. The theoretical argumentation builds on the fact that in a stationary time series, the mean and variance remain constant. The concept is further elaborated with different statistical types of time series trends. These provide the objective for the empirical experiment that evaluates whether software size measures in a typical software evolution dataset are stationary.MethodThe time series analysis is based on conventional statistical tests for the evaluation of stationarity.ResultsThe empirical dataset contains time series extracted from the version control systems used in Vaadin and Tomcat between circa 2006 and 2013. The results establish that the observed time series are neither stationary nor follow simple mathematical functions that would translate into stationarity.ConclusionThe testing framework presented in the paper allows evaluating the stationarity of software evolution time series. The results can be interpreted theoretically against the laws of software evolution. These methodological and theoretical contributions improve the foundations of predictive time series modeling of software evolution problems. Copyright © 2015 John Wiley & Sons, Ltd.

Improvements to the Function Point Analysis Method: A Systematic Literature Review

Function point analysis (FPA) is a standardized method to systematically measure the functional size of software. This method is proposed by an international organization and it is currently recommended by governments and organizations as a standard method to be adopted for this type of measurement. This paper presents a compilation of improvements, focused on increasing the accuracy of the FPA method, which have been proposed over the past 13 years. The methodology used was a systematic literature review (SLR), which was conducted with four research questions aligned with the objectives of this study. As a result of the SLR, of the 1600 results returned by the search engines, 454 primary studies were preselected according to the criteria established for the SLR. Among these studies, only 18 specifically referred to accuracy improvements for FPA, which was the goal of this study. The low number of studies that propose FPA improvements might demonstrate the maturity of the method in the current scenario of software metrics. Specifically in terms of found issues, it was found that the step for calculating the functional size exhibited the highest number of problems, indicating the need to revise FPA in order to encompass the possible improvements suggested by the researchers.

An approach to estimate the size of ERP package using package points

Enterprise Resource Planning (ERP) packages are information systems that automate the business processes of organizations thereby improving their operational efficiency substantially. ERP projects that involve customization are often affected by inaccurate estimation of efforts. Size of the software forms the basis for effort estimation. Methods used for effort estimation either employ function points (FP) or lines of code (LOC) to measure the size of customized ERP packages. Literature review reveals that the existing software size methods which are meant for custom-built software products may not be suitable for COTS products such as customized ERP packages. Hence, the effort estimation using conventional methods for customized ERP packages may not be accurate. This paper proposes a new approach to estimate the size of customized ERP packages using Package Points (PP). The proposed approach was validated with data collected from 14 ERP projects delivered by the same company. A positive correlation was observed between Package Points (PP) and the efforts of these projects. This result indicates the feasibility of our proposed approach as well as the positive climate for its utility by the project managers of future ERP projects. Lastly, we examine the implication of these results for practice and future research scope.

Molecular characterization and polymorphism detection in HSPB6 gene in Sahiwal cattle

The present study was undertaken with the objectives of molecular characterization and detection of genetic polymorphisms in the HSPB6 gene of Sahiwal cattle. A total of 100 Sahiwal cattle maintained at LRC, NDRI, Karnal (Haryana) were included in the study. HSPB6 gene has been mapped on Bos taurus autosome 18 (BTA 18) and spans nearly 2620 bp comprising 3 exons and 2 introns. Four sets of forward and reverse gene-specific oligonucleotide primers of HSPB6 gene were designed using Primer3 software and amplicon size of 529 bp, 460 bp, 670 bp and 502 bp were ascertained. On the basis of comparative sequence analysis, total three polymorphic loci (SNPs) were detected at locus G436A, A2152G and A2417T in HSPB6 gene as compare to Bos taurus (NCBI GenBank AC_000175.1). Out of these three SNPs, two (A2152G & A2417T) were found in 3′-UTR region and third one (G436A) was detected in intronic region 1. However, monomorphic pattern was found in exon 2 of HSPB6 gene in Sahiwal cattle. Further research need be directed to find out the association of allelic variants in major heat shock protein genes to establish markers for the future genetic improvement of livestock through marker assisted selection.

Cross-factor analysis of software engineering practices versus practitioner demographics: An exploratory study in Turkey

ContextUnderstanding the types of software engineering practices and techniques used in the industry is important. There is a wide spectrum in terms of the types and maturity of software engineering practices conducted in each software team and company. Furthermore, it is important to understand the cross-factor relationship of software engineering practices and practitioner demographics including their companies and projects, e.g., is it the case that practitioners developing software for sectors such as military would utilize software size measurement approaches more, or use different software development methodologies, compared to practitioners developing software for other sectors?, and what kinds of practices are conducted by practitioners in small versus large companies? ObjectiveOur objective is to get an understanding into the cross-factor correlation of various software engineering practices versus practitioner demographics including their companies and projects (e.g., target industry, size and work experience). Such an understanding will enable us to identify patterns and pinpoint special issues which should be studied and addressed in the context of each specific demographic (e.g., small versus large companies). Thus, we decided to conduct an exploratory study in this area and collected real industrial data in the context of Turkey which has a vibrant software industry. MethodTo achieve the above objective, we use the data from a recent Turkish-wide survey of software engineering practices which was systematically designed with 46 questions based on our past experience in the Canadian context and using the Software Engineering Body of Knowledge (SWEBOK). 202 practicing software engineers participated in the survey. We raise a set of 12 research questions about the cross-factor correlation of software engineering practices and practitioner demographics, and address them using statistical analysis. ResultsThe exploratory study results reveal important and interesting findings about cross-factor relationship of software engineering practices and practitioner demographics. Among some of the most interesting findings are the followings: (1) By analyzing the trends, we were first surprised to see that as a practitioner gets more years of work experience, against what one would expect, s/he experiences more challenges in Software Development Life-Cycle (SDLC) phases and SE tasks; (2) Almost 55% of participants measure software size; (3) Agile/lean development is used the least (16%) by the participants working in the companies serving the military and defense sector; (4) Usage of waterfall is low among participants employed by small-sized companies whereas Agile/lean development is relatively popular among this class of participants; and (5) As company size increases, usage of spiral development slightly increases, whereas usage of extreme programming practices decreases. ConclusionThe results of this exploratory study will be useful to software engineering professionals and researchers both in Turkey and world-wide by revealing the cross-factor relationship of software engineering practices versus practitioner demographics. The study raises several new research directions, e.g., (1) Why are not many practitioners using any size nor project estimation metrics and how these fundamental engineering approaches could be utilized more frequently?, (2) What are the best practices, success stories and challenging experiences in using SE tools?, and (3) Why is Agile/lean development is not popular in the military and defense sector and how these approaches could be utilized more frequently.

An Insight to Soft Computing based Defect Prediction Techniques in Software

Nowadays, the complexity and size of software systems is proliferating. These factors have various pros and cons. On one side where they lead to better performance and satisfactory results, on the other side they lead to high testing cost , wacky results , poor quality and non-reliability of the product. These problems have one root cause which is referred to as defects in the software systems Predicting these defects can not only rule out the cons but can also boost up the pros. Various techniques are present for the same which are reviewed in depth in this paper. Moreover, a comparison of these techniques is also done to throw a lime light on those which provide the best results.

Ensemble based point and confidence interval forecasting in software engineering

In this paper, we propose and use analytical and heuristic approaches for forecasting 95% confidence intervals (CIs) for software effort or size parameter. The analytical and heuristics forecasts are combined to create an ensemble to lower generalization error. Using ordinary least squares (OLS) and Bayesian regression models, we create three different ensembles. These three different ensembles are one maximizing maximum likelihood hypothesis (MLE), one maximizing maximum a posteriori hypothesis (MAP), a hybrid one maximizing both MLE and MAP hypotheses. Using two different performance metrics, we test the three different ensembles on real-world software engineering datasets. The results of our experiments indicated that the hybrid ensemble shows the worst performance while the MLE ensemble provides superior performance in most cases.

Software Size Estimation: Practical Models and their Applications in Various Phases of the SDLC

Estimating software size has been one of the highly researched topics over the past few decades. Due to the unpredictable nature of many factors associated with software development projects and ever-changing technological complexity, the topic still draws widespread attention within the software engineering domain. This paper briefly discusses few estimation models that can be practically applied to estimate software metrics such as size, effort, and time, without getting involved into mathematical complexity by a project manager. We also discuss the pros and cons of these models. We further map the applicability of these models in various phases of the software development life cycle. Finally, we implement two of these models to develop a user interface that can be used repeatedly or as necessary to estimate the software metrics during the major stages of its developmental life cycle, and adjust the schedule as necessary.

A new fuzzy rule based algorithm for estimating software faults in early phase of development

Estimation of reliability and the number of faults present in software in its early development phase, i.e., requirement analysis or design phase is very beneficial for developing reliable software with optimal cost. Software reliability prediction in early phase of development is highly desirable to the stake holders, software developers, managers and end users. Since, the failure data are unavailable in early phase of software development, different reliability relevant software metrics and similar project data are used to develop models for early software fault prediction. The proposed model uses the linguistic values of software metrics in fuzzy inference system to predict the total number of faults present in software in its requirement analysis phase. Considering specific target reliability, weightage of each input software metrics and size of software, an algorithm has been proposed here for developing general fuzzy rule base. For model validation of the proposed model, 20 real software project data have been used here. The linguistic values from four software metrics related to requirement analysis phase have been considered as model inputs. The performance of the proposed model has been compared with two existing early software fault prediction models.

A survey of software engineering practices in Turkey

Understanding the types of software engineering (SE) practices and techniques used in industry is important. There is a wide spectrum in terms of the types and maturity of SE practices conducted in industry. Turkey has a vibrant software industry and it is important to characterize and understand the state of its SE practices. Our objective is to characterize and grasp a high-level view on type of SE practices in the Turkish software industry. To achieve this objective, we systematically designed an online survey with 46 questions based on our past experience in the Canadian and Turkish contexts and using the Software Engineering Body of Knowledge (SWEBOK). Two hundred and two practicing software engineers from the Turkish software industry participated in the survey. The survey results reveal important and interesting findings about SE practices in Turkey and beyond. They also help track the profession of SE, and suggest areas for improved training, education and research. Among the findings are the followings: (1) The military and defense software sectors are quite prominent in Turkey, especially in the capital Ankara region, and many SE practitioners work for those companies. (2) 54% of the participants reported not using any software size measurement methods, while 33% mentioned that they have measured lines of code (LOC). (3) In terms of effort, after the development phase (on average, 31% of overall project effort), software testing, requirements, design and maintenance phases come next and have similar average values (14%, 12%, 12% and 11% respectively). (4) Respondents experience the most challenge in the requirements phase. (5) Waterfall, as a rather old but still widely used lifecycle model, is the model that more than half of the respondents (53%) use. The next most preferred lifecycle models are incremental and Agile/lean development models with usage rates of 38% and 34%, respectively. (6) The Waterfall and Agile methodologies have slight negative correlations, denoting that if one is used in a company, the other will less likely to be used. The results of our survey will be of interest to SE professionals both in Turkey and world-wide. It will also benefit researchers in observing the latest trends in SE industry identifying the areas of strength and weakness, which would then hopefully encourage further industry–academia collaborations in those areas.

Estimation of Testing and Rework Efforts for Software Development Projects

In the planning of a software development project, a major challenge faced by project managers is to predict the rework effort. (Rework effort is the effort required to fix the software defects identified during system testing). The project manager’s objective is to deliver the software within the time, cost and quality requirements given by the client. To ensure the quality of the software, many testing cycles will be conducted before it is finally delivered to the client for acceptance. Each testing cycle is a costly affair as it involves running all possible test scenarios in all possible environments, followed by defect fixing and re-verification of defects. On average, two to three testing cycles are conducted but this depends on the number of defects identified during testing. The number of defects will depend on the team expertise and whether they earlier worked on similar projects and technologies. Therefore, it becomes critical to predict the number of defects that will be identified during testing and it is a very challenging task as it requires a good model to predict the rework effort. In this paper, we describe the relationship among software size, number of software defects, productivity and efforts for software development projects. This relationship is established by using the multiple linear regression technique on the benchmarking data published by International Software Benchmarking Standard Group. There are 2 linear regression equation established one for web-based project and other for non-web-based projects. Results suggest that the web based projects are delivered faster, however, in web-based projects if we assume higher productivity higher number of defects will be found. Lower productivity will lead to fewer defects found and hence less testing and rework effort will be required therefor if we spend more development time to develop unit size than total number of defects will get reduced and will directly contribute in reducing the rework efforts. For non-web-based projects, results suggest that lower productivity will led to the more number of defects so non-web based project should be planned with much experience resources (higher productivity) so that we should have less defect and rework. Executing non-web based project with experience team require less time for development and most of the defect can be identified during unit testing and this will directly contribute in reducing the rework efforts. We infer from the relationship that software size has much significant impact on total number of defect in comparison to efforts. We also infer that while planning the software project we should use appropriate tools to reduce the margin of error in size estimation and we should also re-estimate the size, after every phase of the development life cycle to re-calibrate overall efforts and to minimize the impact on the project plan.

Impact of Size and Productivity on Testing and Rework Efforts for Web-based Development Projects

In the planning of a software development project, a major challenge faced by project managers is to predict the rework effort. (Rework effort is the effort required to fix the software defects identified during system testing). The project manager's objective is to deliver the software within the time, cost and quality requirements given by the client. To ensure the quality of the software, many testing cycles will be conducted before it is finally delivered to the client for acceptance. Each testing cycle is a costly affair as it involves running all possible test scenarios in all possible environments, followed by defect fixing and re-verification of defect fixes. On average, two to three testing cycles are conducted but this depends on the number of defects identified during testing. The number of defects will depend on the team expertise and whether they earlier worked on similar projects and technologies. Therefore, it becomes critical to predict the number of defects that will be identified during testing and it is a very challenging task as it requires a good model to predict the rework effort. In this paper, we describe the relationships among software size, number of software defects, productivity and efforts for web-based development projects. These relationships are established by using the multiple linear regression technique on the benchmarking data published by International Software Benchmarking Standard Group. Results suggest that in web-based projects the number of defects identified is directly proportional to the productivity, i.e. higher productivity will led to more defects found and lower productivity will lead to fewer defects found, therefore, less testing and rework effort will be required if project is planned with lower productivity because we can spend more time on development (i.e. time spend till construction phase) to reduce the number of defects found during testing and it will directly contribute in reducing the rework efforts. We infer from the relationship that software size has a significant impact on the total number of defect identified. We also infer that while planning a software project we should use appropriate tools to reduce the margin of error in size estimation and we should also re-estimate the size after every phase of the development life cycle to re-calibrate overall efforts and to minimize the impact on the project plan.