5 research outputs found

    Ver枚ffentlichungen und Vortr盲ge 2003 der Mitgleider der Fakult盲t f眉r Informatik

    Get PDF

    Medidas de productividad en los proyectos de desarrollo de software: una aproximaci贸n por puestos de trabajo

    Get PDF
    La productividad es una medida, principalmente econ贸mica, creada a finales del siglo XVIII. Desde entonces, numerosas modificaciones se han realizado sobre la definici贸n inicial y se han incorporando a diversas 谩reas de conocimiento. Dentro de la Ingenier铆a del Software (IS), la productividad comenz贸 a ser objeto de estudio a finales de los a帽os 70, casi de forma paralela a la concepci贸n de la misma y al inicio del estudio de conceptos relacionados, tales como la estimaci贸n de esfuerzo. La medici贸n de la productividad en IS ha sido ampliamente analizada a nivel de proyecto y organizaci贸n, sin embargo a nivel de puesto de trabajo no ha sido tan investigada. En estos escasos estudios, las medidas utilizadas suelen ser las mismas medidas que las empleadas en niveles superiores de medici贸n. En concreto, las medidas empleadas suelen ser ratios entre una medida de tama帽o de producto (p. ej., l铆neas de c贸digo o puntos funci贸n) y una medida de esfuerzo o tiempo (p. ej., horas-hombre u horas). Este tipo de medidas son muy espec铆ficas y no reflejan la realidad del trabajo desempe帽ado en todo el proceso de desarrollo, ya que no tienen en cuenta las caracter铆sticas inherentes a cada puesto de trabajo. As铆 pues, la eficacia de estas medidas, en este nivel de medici贸n, parece estar en entredicho y la realizaci贸n de estudios que aporten nuevas medidas de productividad en IS a nivel de puesto de trabajo cobra sentido. En la presente tesis doctoral se ha analizado la situaci贸n actual de la medici贸n de la productividad en IS a nivel de puesto de trabajo con el objetivo de crear nuevas medidas. Para conseguir este objetivo se ha realizado un estudio del estado de la cuesti贸n utilizando una metodolog铆a cl谩sica de revisi贸n de referencias junto con una revisi贸n sistem谩tica de la literatura. Una vez analizado el estado de la cuesti贸n se ha planteado un conjunto de hip贸tesis relacionadas con la construcci贸n de nuevas medidas de productividad: Hip贸tesis 1. En los puestos de trabajo involucrados en la ejecuci贸n de proyectos de desarrollo de software se emplean otras entradas, adem谩s del tiempo y el esfuerzo. Hip贸tesis 2. Las entradas utilizadas son distintas para cada puesto de trabajo involucrado en la ejecuci贸n de proyectos de desarrollo de software. Hip贸tesis 3. En los puestos de trabajo involucrados en la ejecuci贸n de proyectos de desarrollo de software se producen otras salidas, adem谩s de l铆neas de c贸digo y funcionalidad. Hip贸tesis 4. Las salidas producidas son distintas para cada puesto de trabajo involucrado en la ejecuci贸n de proyectos de desarrollo de software. Hip贸tesis 5. Las medidas de productividad m谩s utilizadas a nivel de puesto de trabajo en los proyectos de desarrollo de software tienen una eficacia limitada para medir la productividad real de los trabajadores. Hip贸tesis 6. Es posible medir de forma m谩s eficaz la productividad de los puestos de trabajo en los proyectos de desarrollo de software con nuevas medidas que combinen varios elementos: entradas, salidas y factores. Tras el an谩lisis del estado de la cuesti贸n, se ha realizado una fase de investigaci贸n cualitativa mediante el empleo de entrevistas a trabajadores de IS y un posterior an谩lisis de contenido, con el fin de obtener informaci贸n suficiente para: (1) contrastar las cuatro primeras hip贸tesis con informaci贸n cualitativa, y (2) construir el medio de recogida de informaci贸n para la siguiente fase de la investigaci贸n. Con respecto al primer objetivo, ha sido posible contrastar dos hip贸tesis (H1 y H3). En la segunda fase, mediante una metodolog铆a cuantitativa, se han contrastado las cuatro primeras hip贸tesis planteadas. Para la recogida de informaci贸n se ha utilizado un formulario construido a partir de los resultados de la fase cualitativa. Los resultados de esta fase indican que en los puestos de trabajo analizados (programador, analista, consultor, y jefe de proyecto): se utilizan otros recursos adem谩s del tiempo, se producen otras salidas adem谩s del c贸digo fuente y la funcionalidad entregada al cliente. Adem谩s, se han encontrado diferencias en el grado de uso de las entradas y en la producci贸n de las salidas, por lo que el uso de una misma medida de productividad para todos los puestos bajo estudio es, en principio, il贸gico. Para contrastar las dos, y 煤ltimas, hip贸tesis se han construido nuevas medidas de productividad, teniendo en cuenta los resultados previos. En concreto, se ha utilizado Data Envelopment Analysis (DEA) como metodolog铆a personalizable para medir la productividad; y se han realizado cuatro casos de estudio empleando dicha metodolog铆a. Los resultados tras los casos de estudio indican que mediante DEA es posible medir la productividad de los puestos de trabajo vinculados con los proyectos de desarrollo y mantenimiento de software de forma m谩s eficaz que con las medidas m谩s utilizadas. Adem谩s, esta metodolog铆a permite conocer los puntos de mejora para que los trabajadores menos productivos aumenten su productividad, lo que supone una gran ventaja frente a otras medidas de productividad si el objetivo de medir, como es l贸gico suponer, es mejorar la productividad, y no simplemente evaluarla. As铆 pues, se contrastan las dos 煤ltimas hip贸tesis y se insta, entre otras futuras l铆neas de investigaci贸n, a continuar con nuevos estudios que comparen el uso de DEA con otras medidas de productividad. Finalmente, se concluye que la medici贸n de la productividad en los puestos de trabajo vinculados con los proyectos de desarrollo y mantenimiento de software continua siendo un reto. Para reducir la dificultad de 茅ste, la presente tesis doctoral arroja luz aportando un marco de trabajo para analizar y plantear nuevas medidas de productividad, tanto en estos puestos de trabajo como en otros. ------------------------------Productivity is mainly an economic measure, created in the late eighteenth century. Since then, many changes have been made on its initial definition and have been incorporated into various areas of knowledge. Within Software Engineering (SE), productivity began to be studied in the late '70s. These efforts ran parallel to SE developments, such as effort estimation. Measuring productivity in SE has been extensively analyzed at the project and organization level; however job level has not been investigated with the same depth. In these few studies, the measures used are often the same ones than those used in higher levels of measurement. Specifically, the measures employed are usually ratios between a measure of product size (e.g., lines of code or function points) and a measure of effort or time (e.g., man-hours or hours). Such measures do not reflect the reality of the work performed throughout the development process because they do not take into account the inherent characteristics of each job. Thus, the effectiveness of these measures, in this measurement level, seems to be in question and studies that provide new measures of productivity at job level make sense. In this thesis we have analyzed the current state of productivity measurement at job level within SE with the goal of creating new measures. In order to achieve this objective a study of the state of the art has been carried out with a classical methodology along with a systematic review of the literature. After analyzing the state of the art, a number of hypotheses related to the construction of new productivity measures have been stated: Hypothesis 1. In the jobs involved in the implementation of software development projects other inputs are used in addition to time and effort. Hypothesis 2. The inputs used are different for every job involved in software development projects. Hypothesis 3. In the jobs involved in the implementation of software development projects other outputs are produced in addition to source code lines and functionality. Hypothesis 4. The outputs produced are different for every job involved in software development projects. Hypothesis 5. The most used productivity measures at job level in software development projects have limited effectiveness for measuring real productivity of workers. Hypothesis 6. It is possible to measure more effectively the productivity of jobs in software development projects with new measures that combine several elements: inputs, outputs and factors. After analyzing the state of the art, a qualitative phase has been performed using interviews with SE workers and a subsequent content analysis of them in order to obtain pertinent information: (1) to test the first four hypotheses with qualitative information, and (2) to build the information gathering instrument for the next phase of research. Regarding the first objective, it has been possible to test two hypotheses (H1 and H3). In the second phase, using a quantitative method, the first four hypotheses have been contrasted and accepted. For the information gathering a form constructed from the results of the qualitative phase has been used. The results of this phase indicate that the analyzed job positions (programmer, analyst, consultant, and project manager): use other resources in addition to time, and deliver other outputs in addition to source code and functionality delivered to the client. Also some differences in the degree of use of inputs and production of outputs have been found. Therefore, the use of the same measure of productivity for all positions under study is, in principle, illogical. To contrast the last two hypotheses new productivity measures have been built taking into account the previous results. Specifically, a customizable methodology for measuring productivity such as Data Envelopment Analysis (DEA) was used in four case studies. The results after these studies indicate that using DEA is a mean to measure the productivity of job level for job positions related to the development and maintenance of software projects in a more effectively way. Furthermore, this methodology allows knowing the points for improvement for the least productive workers in order to increase their productivity. This knowledge is a great advantage over other productivity measures if the goal of measuring, as is logical to assume, is to improve productivity, not simply to evaluate it. So the last two hypotheses has been supported. Consequently we call, among other future research, to continue with further studies comparing the use of DEA with other measures of productivity. Finally, it is concluded that the measurement of productivity in job positions related with software development and maintenance projects remains a challenge. To reduce this difficulty, this thesis sheds some light on the topic by providing a framework to analyze and propose new measures of productivity for SE job roles.Presidente: Mar铆a Bel茅n Ruiz Mezcua; Vocal: Rafael Valencia Garc铆a; Secretario: Edmundo Tovar Car

    A Discrete Simulation Model for Assessing Software Project Scheduling Policies

    No full text
    Good project scheduling is an essential, but extremely hard task in software management practice. In a software project, the time needed to complete some development activity is difficult to estimate. Often, the completion of activities is delayed due to unanticipated rework which is caused by feedback in the process. In this paper, we show how process simulation can be used to support managers in finding good schedules for their software projects. We present a novel, stochastic simulation model which is tailored to the special dynamics of software projects, and which explicitly takes a scheduling strategy as input. The model represents task assignments, staff skill levels, component coupling, and rework caused by design changes. The simulation model is implemented in the ModL language of the generalpurpose graphical simulation tool EXTEND. As an illustration of our simulation model, we study the performance of various list policies for a small sample project. The simulations quickly show the impact that the choice of the list policy will have on the progress and completion time of the sample project. To explain the performance difference between the list policies, we use the simulation traces to provide a detailed analysis of the task assignments which actually occur in the simulations
    corecore