19 research outputs found

    Calibrating Function Point Backfiring Conversion Ratios Using Neuro-Fuzzy Technique

    Get PDF
    Software estimation is an important aspect in software development projects because poor estimations can lead to late delivery, cost overruns, and possibly project failure. Backfiring is a popular technique for sizing and predicting the volume of source code by converting the function point metric into source lines of code mathematically using conversion ratios. While this technique is popular and useful, there is a high margin of error in backfiring. This research introduces a new method to reduce that margin of error. Neural networks and fuzzy logic in software prediction models have been demonstrated in the past to have improved performance over traditional techniques. For this reason, a neuro-fuzzy approach is introduced to the backfiring technique to calibrate the conversion ratios. This paper presents the neuro-fuzzy calibration solution and compares the calibrated model against the default conversion ratios currently used by software practitioners

    Applying Absolute Residuals as Evaluation Criterion for Estimating the Development Time of Software Projects by Means of a Neuro-Fuzzy Approach

    Get PDF
    In the software development field, software practitioners expend between 30% and 40% more effort than is predicted. Accordingly, researchers have proposed new models for estimating the development effort such that the estimations of these models are close to actual ones. In this study, an application based on a new neuro-fuzzy system (NFS) is analyzed. The NFS accuracy was compared to that of a statistical multiple linear regression (MLR) model. The criterion for evaluating the accuracy of estimation models has mainly been the Magnitude of Relative Error (MRE), however, it was recently found that MRE is asymmetric, and the use of Absolute Residuals (AR) has been proposed, therefore, in this study, the accuracy results of the NFS and MLR were based on AR. After a statistical paired t-test was performed, results showed that accuracy of the New-NFS is statistically better than that of the MLR at the 99% confidence level. It can be concluded that a new-NFS could be used for predicting the effort of software development projects when they have been individually developed on a disciplined process.In the software development field, software practitioners expend between 30% and 40% more effort than is predicted. Accordingly, researchers have proposed new models for estimating the development effort such that the estimations of these models are close to actual ones. In this study, an application based on a new neuro-fuzzy system (NFS) is analyzed. The NFS accuracy was compared to that of a statistical multiple linear regression (MLR) model. The criterion for evaluating the accuracy of estimation models has mainly been the Magnitude of Relative Error (MRE), however, it was recently found that MRE is asymmetric, and the use of Absolute Residuals (AR) has been proposed, therefore, in this study, the accuracy results of the NFS and MLR were based on AR. After a statistical paired t-test was performed, results showed that accuracy of the New-NFS is statistically better than that of the MLR at the 99% confidence level. It can be concluded that a new-NFS could be used for predicting the effort of software development projects when they have been individually developed on a disciplined process

    An empirical study into the causes of lateness of new product development projects

    Get PDF
    In this paper we investigate the causes of lateness of new product development projects. From literature, we have identified three possible causes of lateness: optimistic estimates of processing times, instability of project networks and the impact of due date nearness on engineer's performance. Over a time-span of 42 weeks, detailed empirical data were collected of two product development projects to verifY the occurrence of these three causes in real-life product development projects. The data reveal that indeed engineers produce optimistic estimates, but only for large work packages, that the project networks were highly unstable, and that the engineer's performance was highly affected by due date nearness. The data suggest that project lateness is mainly due to the combined effect of project network instability and the engineer performance being dependent on due date nearness. From the interpretation of the data implications are derived for the management ofnew product development projects

    Analysis of relationship between software metrics and process models

    Get PDF
    This thesis studies the correlation between software process models and software metrics. To support our studies we have defined a Process - Metric Evaluation Framework and derived an evaluation template from it. The template served as a basic tool in studding the relationships between various process models, artifacts and software metrics. We have evaluated a number of process models according to our template and have identified suitable software metrics. We have also recommended a root cause analysis approach at various points of the process models. The suggested software metrics can be derived from various product and process artifacts. They can be used to curb the risks generated at each phase of the development process, identify issues, and do better planning and project management. The evaluation template can also be used to evaluate other models and identify effective metrics

    Towards analysis-driven scientific software architecture: The case for abstract data type calculus

    Get PDF
    Abstract. This article approaches scientific software architecture from three analytical paths. Each path examines discrete time advancement of multiphysics phenomena governed by coupled differential equations. The new object-oriented Fortran 2003 constructs provide a formal syntax for an abstract data type (ADT) calculus. The first analysis uses traditional object-oriented software design metrics to demonstrate the high cohesion and low coupling associated with the calculus. A second analysis from the viewpoint of computational complexity theory demonstrates that a more representative bug search strategy than that considered by Rouson et al. (ACM Trans. Math. Soft. 3

    Estimación de costo de software: Una propuesta de aplicación pedagógica de COCOMO

    Get PDF
    The computer science curriculum and other related academic programs show a relevant gap on software cost estimation. Usually, curriculum models related to software development recommend the inclusion of software estimation topics without specifying any particular estimation model. In addition, software estimation models are difficult to understand and the existing examples are often vague, and this without considering actual contexts. In this paper we present a pedagogical proposal to teach COCOMO in its basic and intermediate modalities, oriented to the magnitude of the final product. The model includes six sections required for a proper pedagogical approach. First, the theoretical background is explained in a very simple way. Then, there is a presentation of an actual case study, several examples, a pedagogical approach, and the respective analysis. This work is important because it is now possible to teach the software cost estimation topic by using a practical model contextualized in an actual case.Los planes de estudio de ciencias de la computación y carreras afines evidencian una brecha importante en torno a la temática de estimación de costos de proyectos de software.  En general, en los modelos curriculares relacionados con el desarrollo de software, se recomienda la temática de la estimación en el desarrollo del software sin especificar ningún modelo de estimación en concreto.  En abono a lo anterior, dichos modelos tienen la particularidad de que son difíciles de entender y los ejemplos existentes en la bibliografía suelen ser muy vagos sin considerar contextos cercanos a la realidad.  En este artículo se presenta una propuesta de aplicación pedagógica del modelo de estimación de costos COCOMO en las modalidades básica e intermedia orientada a la magnitud del producto final.  El modelo incluye seis apartados necesarios para un adecuado abordaje pedagógico.  Lo primero que se define es su fundamento teórico esquematizado de forma resumida.  Además, se presenta un caso real de estudio, ejemplos resueltos, la propuesta pedagógica y el análisis respectivo.  La relevancia de este trabajo se fundamenta en el hecho de que se facilita la enseñanza del tema de estimación del costo del software, de forma práctica y contextualizada en un caso real

    Pelikehittäjän haasteet ja mahdollisuudet yksin ja yrityksessä

    Get PDF
    Tiivistelmä. Pelikehitys on noussut merkittäväksi osaksi ohjelmistokehityksen maailmaa ja yhä useampi valitsee urakseen pelikehityksen. Tämä uravalinta voi johtaa siihen, että pelikehittäjä on osa isompaa peliyritystä tai sitten hän valitsee olla niin sanottu indie-pelikehittäjä ja toimii siten yksin. Tässä tutkielmassa selvitetään kirjallisuuskatsauksen keinoin, millaisia mahdollisuuksia ja haasteita itsenäinen ja yrityksessä toimiva pelikehittäjä kohtaa urallaan. Suurimmat löydökset olivat, että yksin toimiva pelikehittäjä kokee suurimmat haasteensa näkyvyyden hankkimisessa, riittävän markkinoinnin parissa ja pelin laajuuden ja toimintojen hallinnoimisessa. Yksin toimiva pelikehittäjä saa kuitenkin mahdollisuutena suuren vapauden toteuttaa minkä pelin hän ikinä haluaakin ja pääsee toteuttamaan täysin artistista näkemystään. Tähän verrattuna pelikehittäjä yrityksessä kokee haasteita mahdollisesti eniten niin sanotun crunchin kanssa. Crunch on yleensä suurien peliyhtiöiden ilmiö, missä työntekijät useasti syyllistetään tekemään paikasta riippuen jopa kaksinkertaista työvuoroa pitkiä aikoja ennen isoa julkaisua. Ymmärrettävästi tämä polttaa työntekijöitä loppuun ja pelikehittäjät kokevatkin crunchin aikana terveyshaittoja. Mahdollisuuksia pelikehittäjällä yrityksessä on potentiaalisesti päästä käyttämään peliteollisuuden uusimpia ja parhaimpia työkaluja, joihin yksin toimivalla pelikehittäjällä ei välttämättä koskaan ole pääsyä tai mahdollisuutta. Pelikehittäjä yrityksessä voi myös kokea turhautumista ollessaan vain pieni osa koneistoa, mutta osa isompaa projektiryhmää tuo ystävyyssuhteita ja muita yhteyksiä ihmisiin. Osana virtuaalista organisaatiota pelikehittäjä kokee haasteita eristäytymisen ja vähäisen kanssakäymisen tunteita muiden projektiryhmän jäsenten kesken, luottamus projektiryhmäläisiin ja kommunikaatio-ongelmien kanssa. Muita mahdollisia ongelmia pelikehittäjällä ovat mahdolliset aikavyöhykkeiden eroavaisuudet ja kielimuuri. Kuitenkin mahdollisuuksia tuovat työskentely missä vain ja milloin vain kuten myös ajan ja rahan säästö työmatkojen suhteen. Muita mahdollisuuksia ovat avun ja tuen saaminen missä vain, kun mahdollisia ongelmia tulee. Ratkaisuna ongelmiin voi olla muun muassa projektitapaamisten pito kasvokkain välillä
    corecore