Come le startup selezionano i software di project management?

Il presente lavoro di tesi punta a cercare di capire quali funzionalità, le startup del settore IT ritengono più utili all’interno dei software di project management. L’approccio per rispondere alla domanda sarà quello di intervistare startup presenti in diversi incubatori italiani ed elaborare i dati raccolti. Le aziende dovranno essere operanti nel settore informatico ed avere massimo 7 anni. Nel primo periodo di ricerca ho analizzato le funzionalità descritte nella letteratura scientifica e ho trovato che quanto presente non fosse compatibile con le attuali necessità e caratteristiche delle startup. Per avvalorare quanto affermo, sottoporrò un questionario alle startup compatibili con i requisiti, in cui valuterò se concordano o smentiscono ciò che dichiaro. L’intervista sarà rivolta ai project manager delle aziende, verrà loro sottoposto un questionario online in cui dovranno esprimere una preferenza tra 2 elenchi di funzionalità e indicare qual è maggiormente compatibile con le loro esigenze. In base alla scelta che effettueranno gli verrà domandato quali funzionalità tra quelle elencate ritengono più utili per i loro bisogni aziendali. Al termine della ricerca verranno elaborate le informazioni osservando se hanno trovato più utile il nuovo elenco di funzionalità e quali funzionalità sono considerate maggiormente necessarie a soddisfare le esigenze aziendali.

Lean Thinking in Software Development : Impacts of Kanban on Projects

The history of software development in a somewhat systematical way has been performed for half a century. Despite this time period, serious failures in software development projects still occur. The pertinent mission of software project management is to continuously achieve more and more successful projects. The application of agile software methods and more recently the integration of Lean practices contribute to this trend of continuous improvement in the software industry. One such area warranting proper empirical evidence is the operational efficiency of projects. In the field of software development, Kanban as a process management method has gained momentum recently, mostly due to its linkages to Lean thinking. However, only a few empirical studies investigate the impacts of Kanban on projects in that particular area. The aim of this doctoral thesis is to improve the understanding of how Kanban impacts on software projects. The research is carried out in the area of Lean thinking, which contains a variety of concepts including Kanban. This article-type thesis conducts a set of case studies expanded with the research strategy of quasi-controlled experiment. The data-gathering techniques of interviews, questionnaires, and different types of observations are used to study the case projects, and thereby to understand the impacts of Kanban on software development projects. The research papers of the thesis are refereed, international journal and conference publications. The results highlight new findings regarding the application of Kanban in the software context. The key findings of the thesis suggest that Kanban is applicable to software development. Despite its several benefits reported in this thesis, the empirical evidence implies that Kanban is not all-encompassing but requires additional practices to keep development projects performing appropriately. Implications for research are given, as well. In addition to these findings, the thesis contributes in the area of plan-driven software development by suggesting implications both for research and practitioners. As a conclusion, Kanban can benefit software development projects but additional practices would increase its potential for the projects.

Lean Software Management: BBC Worldwide Case Study

This case study examines how the lean ideas behind the Toyota production system can be applied to software project management. It is a detailed investigation of the performance of a nine-person software development team employed by BBC Worldwide based in London. The data collected in 2009 involved direct observations of the development team, the kanban boards, the daily stand-up meetings, semistructured interviews with a wide variety of staff, and statistical analysis. The evidence shows that over the 12-month period, lead time to deliver software improved by 37%, consistency of delivery rose by 47%, and defects reported by customers fell 24%. The significance of this work is showing that the use of lean methods including visual management, team-based problem solving, smaller batch sizes, and statistical process control can improve software development. It also summarizes key differences between agile and lean approaches to software development. The conclusion is that the performance of the software development team was improved by adopting a lean approach. The faster delivery with a focus on creating the highest value to the customer also reduced both technical and market risks. The drawbacks are that it may not fit well with existing corporate standards.

Managing Software Requirements Changes Based On Negotiation-Style Revision

For any proposed software project, when the software requirements specification has been established, requirements changes may result in not only a modification of the requirements specification but also a series of modifications of all existing artifacts during the development. Then it is necessary to provide effective and flexible requirements changes management. In this paper, we present an approach to managing requirements changes based on Booth’s negotiation-style framework for belief revision. Informally, we consider the current requirements specification as a belief set about the system-to-be. The request of requirements change is viewed as new information about the same system-to-be. Then the process of executing the requirements change is a process of revising beliefs about the system-to-be. We design a family of belief negotiation models appropriate for different processes of requirements revision, including the setting of the request of requirements change being fully accepted, the setting of the current requirements specification being fully preserved, and that of the current specification and the request of requirements change reaching a compromise. In particular, the prioritization of requirements plays an important role in reaching an agreement in each belief negotiation model designed in this paper.

A taxonomy of dependencies in agile software development

Dependencies in a software project can contribute to unsatisfactory progress if they constrain or block the flow of work. Various studies highlight the importance of dependencies in the organisation of work; however dependencies in agile software development projects have not previously been a research focus. Drawing on three case studies of agile software projects, and the IS literature, this paper develops an initial taxonomy of agile software project dependencies. Three distinct categories of dependency are found: task, resource, and knowledge dependencies. This paper contributes to theory by providing a taxonomy of dependency types occurring in the area of agile software development. Practitioners can use this taxonomy as sensitising device to ensure they consider dependencies they might face that could hinder their projects, enabling them to take appropriate and timely mitigating action.

Characterization and prediction of issue-related risks in software projects

Identifying risks relevant to a software project and planning measures to deal with them are critical to the success of the project. Current practices in risk assessment mostly rely on high-level, generic guidance or the subjective judgements of experts. In this paper, we propose a novel approach to risk assessment using historical data associated with a software project. Specifically, our approach identifies patterns of past events that caused project delays, and uses this knowledge to identify risks in the current state of the project. A set of risk factors characterizing “risky” software tasks (in the form of issues) were extracted from five open source projects: Apache, Duraspace, JBoss, Moodle, and Spring. In addition, we performed feature selection using a sparse logistic regression model to select risk factors with good discriminative power. Based on these risk factors, we built predictive models to predict if an issue will cause a project delay. Our predictive models are able to predict both the risk impact (i.e. the extend of the delay) and the likelihood of a risk occurring. The evaluation results demonstrate the effectiveness of our predictive models, achieving on average 48%-81% precision, 23%-90% recall, 29%-71% F-measure, and 70%-92% Area Under the ROC Curve. Our predictive models also have low error rates: 0.39-0.75 for Macro-averaged Mean Cost-Error and 0.7-1.2 for Macro-averaged Mean Absolute Error.

Knowledge-based risk management: Survey on Brazilian software development enterprises

A risks management, carried on in an effective way, leads the software development to success and may influence on the organization. The knowledge takes part of such a process as a way to help taking decisions. This research aimed to analyze the use of Knowledge Management techniques to the Risk Management in software projects development and the possible influence on the enterprise revenue. It had, as its main studying subject, Brazilian incubated and graduated software developing enterprises. The chosen research method was the Survey type. Multivariate statistical methods were used for the treatment and analysis of the obtained results, this way identifying the most significant factors, that is, enterprise's achievement constraining factors and those outcome achievement ones. Among the latter we highlight the knowledge methodology, the time of existence of the enterprise, the amount of employees and the knowledge externalization. The results encourage contributing actions to the increasing of financial revenue. © 2013 Springer-Verlag.

Explaining Endogenous Control Change in Outsourced Software Projects

Given the centrality of control for achieving success in outsourced software projects, past research has identified key exogenous factors that determine the choice of controls. This view of exogenously driven control choice is based on a number of assumptions; particularly, clients and vendors are seen as separate cognitive entities that combat opportunistic threats under environmental uncertainty by one-off choices or infrequent revisions of controls. In this paper we complement this perspective by acknowledging that an outsourced software project may be characterized as a collective, evolving process faced with the challenge of coping with cognitive limitations of both client and vendor through a continuous process of learning. We argue that if viewed in this way, controls are less subject of a deliberate choice but rather are subject of endogenously driven change, i.e. controls evolve in close interaction with the evolving software project. Accordingly, we suggest a complementary model of endogenous control, where controls mediate individual and collective learning processes. Our research contributes to a better understanding of the dynamics in outsourced software projects. It also spells out methodological implications that may help improve cross-section control research.

A systematic mapping study on the open source software development process.

Abstract?Background: There is no globally accepted open source software development process to define how open source software is developed in practice. A process description is important for coordinating all the software development activities involving both people and technology. Aim: The research question that this study sets out to answer is: What activities do open source software process models contain? The activity groups on which it focuses are Concept Exploration, Software Requirements, Design, Maintenance and Evaluation. Method: We conduct a systematic mapping study (SMS). A SMS is a form of systematic literature review that aims to identify and classify available research papers concerning a particular issue. Results: We located a total of 29 primary studies, which we categorized by the open source software project that they examine and by activity types (Concept Exploration, Software Requirements, Design, Maintenance and Evaluation). The activities present in most of the open source software development processes were Execute Tests and Conduct Reviews, which belong to the Evaluation activities group. Maintenance is the only group that has primary studies addressing all the activities that it contains. Conclusions: The primary studies located by the SMS are the starting point for analyzing the open source software development process and proposing a process model for this community. The papers in our paper pool that describe a specific open source software project provide more regarding our research question than the papers that talk about open source software development without referring to a specific open source software project.

Are team personality and climate related to satisfaction and software quality? Aggregating results from a twice replicated experiment

Research into software engineering teams focuses on human and social team factors. Social psychology deals with the study of team formation and has found that personality factors and group processes such as team climate are related to team effectiveness. However, there are only a handful of empirical studies dealing with personality and team climate and their relationship to software development team effectiveness. Objective We present aggregate results of a twice replicated quasi-experiment that evaluates the relationships between personality, team climate, product quality and satisfaction in software development teams. Method Our experimental study measures the personalities of team members based on the Big Five personality traits (openness, conscientiousness, extraversion, agreeableness, neuroticism) and team climate factors (participative safety, support for innovation, team vision and task orientation) preferences and perceptions. We aggregate the results of the three studies through a meta-analysis of correlations. The study was conducted with students. Results The aggregation of results from the baseline experiment and two replications corroborates the following findings. There is a positive relationship between all four climate factors and satisfaction in software development teams. Teams whose members score highest for the agreeableness personality factor have the highest satisfaction levels. The results unveil a significant positive correlation between the extraversion personality factor and software product quality. High participative safety and task orientation climate perceptions are significantly related to quality. Conclusions First, more efficient software development teams can be formed heeding personality factors like agreeableness and extraversion. Second, the team climate generated in software development teams should be monitored for team member satisfaction. Finally, aspects like people feeling safe giving their opinions or encouraging team members to work hard at their job can have an impact on software quality. Software project managers can take advantage of these factors to promote developer satisfaction and improve the resulting product.

Análisis de la calidad y productividad en el desarrollo de un proyecto software en una microempresa con TSPi

Este artículo presenta el análisis de los resultados obtenidos al aplicar TSPi en el desarrollo de un proyecto software en una microempresa desde el punto de vista de la calidad y la productividad. La organización en estudio necesitaba mejorar la calidad de sus procesos pero no contaba con los recursos económicos que requieren modelos como CMMI-DEV. Por esta razón, se decidió utilizar un proceso adaptado a la organización basado en TSPi, observándose una reducción en la desviación de las estimaciones, un incremento en la productividad, y una mejora en la calidad.---ABSTRACT---This article shows the benefits of developing a software project using TSPi in a “Very Small Enterprise” based in quality and productivity measures. An adapted process from the current process based on the TSPi was defined and the team was trained in it. The workaround began by gathering historical data from previous projects in order to get a measurement repository, and then the project metrics were collected. Finally, the process, product and quality improvements were verified.

Configuración de un entorno de trabajo para el desarrollo de software ágil con integración continua

Hoy en día, existen numerosos sistemas (financieros, fabricación industrial, infraestructura de servicios básicos, etc.) que son dependientes del software. Según la definición de Ingeniería del Software realizada por I. Sommerville, “la Ingeniería del Software es una disciplina de la ingeniería que comprende todos los aspectos de la producción de software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después de que se utiliza.” “La ingeniería del software no sólo comprende los procesos técnicos del desarrollo de software, sino también actividades tales como la gestión de proyectos de software y el desarrollo de herramientas, métodos y teorías de apoyo a la producción de software.” Los modelos de proceso de desarrollo software determinan una serie de pautas para poder desarrollar con éxito un proyecto de desarrollo software. Desde que surgieran estos modelos de proceso, se investigado en nuevas maneras de poder gestionar un proyecto y producir software de calidad. En primer lugar surgieron las metodologías pesadas o tradicionales, pero con el avance del tiempo y la tecnología, surgieron unas nuevas llamadas metodologías ágiles. En el marco de las metodologías ágiles cabe destacar una determinada práctica, la integración continua. Esta práctica surgió de la mano de Martin Fowler, con el objetivo de facilitar el trabajo en grupo y automatizar las tareas de integración. La integración continua se basa en la construcción automática de proyectos con una frecuencia alta, promoviendo la detección de errores en un momento temprano para poder dar prioridad a corregir dichos errores. Sin embargo, una de las claves del éxito en el desarrollo de cualquier proyecto software consiste en utilizar un entorno de trabajo que facilite, sistematice y ayude a aplicar un proceso de desarrollo de una forma eficiente. Este Proyecto Fin de Grado (PFG) tiene por objetivo el análisis de distintas herramientas para configurar un entorno de trabajo que permita desarrollar proyectos aplicando metodologías ágiles e integración continua de una forma fácil y eficiente. Una vez analizadas dichas herramientas, se ha propuesto y configurado un entorno de trabajo para su puesta en marcha y uso. Una característica a destacar de este PFG es que las herramientas analizadas comparten una cualidad común y de alto valor, son herramientas open-source. El entorno de trabajo propuesto en este PFG presenta una arquitectura cliente-servidor, dado que la mayoría de proyectos software se desarrollan en equipo, de tal forma que el servidor proporciona a los distintos clientes/desarrolladores acceso al conjunto de herramientas que constituyen el entorno de trabajo. La parte servidora del entorno propuesto proporciona soporte a la integración continua mediante herramientas de control de versiones, de gestión de historias de usuario, de análisis de métricas de software, y de automatización de la construcción de software. La configuración del cliente únicamente requiere de un entorno de desarrollo integrado (IDE) que soporte el lenguaje de programación Java y conexión con el servidor. ABSTRACT Nowadays, numerous systems (financial, industrial production, basic services infrastructure, etc.) depend on software. According to the Software Engineering definition made by I.Sommerville, “Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use.” “Software engineering is not just concerned with the technical processes of software development. It also includes activities such as software project management and the development of tools, methods, and theories to support software production.” Software development process models determine a set of guidelines to successfully develop a software development project. Since these process models emerged, new ways of managing a project and producing software with quality have been investigated. First, the so-called heavy or traditional methodologies appeared, but with the time and the technological improvements, new methodologies emerged: the so-called agile methodologies. Agile methodologies promote, among other practices, continuous integration. This practice was coined by Martin Fowler and aims to make teamwork easier as well as automate integration tasks. Nevertheless, one of the keys to success in software projects is to use a framework that facilitates, systematize, and help to deploy a development process in an efficient way. This Final Degree Project (FDP) aims to analyze different tools to configure a framework that enables to develop projects by applying agile methodologies and continuous integration in an easy and efficient way. Once tools are analyzed, a framework has been proposed and configured. One of the main features of this FDP is that the tools under analysis share a common and high-valued characteristic: they are open-source. The proposed framework presents a client-server architecture, as most of the projects are developed by a team. In this way, the server provides access the clients/developers to the tools that comprise the framework. The server provides continuous integration through a set of tools for control management, user stories management, software quality management, and software construction automatization. The client configuration only requires a Java integrated development environment and network connection to the server.

Looking for the Holy Grail of Software Development

The history of Software Engineering has been marked by many famous project failures documented in papers, articles and books. This pattern of lack of success has prompted the creation of dozens of software analysis, requirements definition, and design methods, programming languages, software development environments and software development processes all promoted as solving ?the software problem.? What we hear less about are software projects that were successful. This article reports on the findings of an extensive analysis of successful software projects that have been reported in the literature. It discusses the different interpretations of success and extracts the characteristics that successful projects have in common. These characteristics provide Software Project Managers with an agenda of topics to be addressed that will help ensure, not guarantee, that their software project will be successful.