Project topics and materials
Get Complete Project Material File(s) Now! »
Developers Insight on Project Quality
To get a better point of view on the feelings of the project members about project failure and success root causes, we made a survey for developers, team managers, and architects of Worldline France. Everyday, they are confronting the same problems, loosing time trying to solve them, with or without success. If a generalization can be made, then solving the problem will be interesting for the company in terms of cost savings and wellbeing of the employees. As health of the project is still an essential factor for Worldline, we focused the survey on the factors that influence the health of the project we discovered previously.
Survey Description
The participation to the survey is on voluntary basis. To make project members of Worldline answering it, we sent mails to more than 1000 project members and posted on the company social network. We also sent a reminder on both media one month after the first sent and succeed to have 131 project members that anonymously answered to the poll. With 11 questions, the survey took 15-20 minutes to be filled. Questions have been first tried on several beta testers to be sure that they are correctly formulated and understandable, and, conclusions can be draw from the answer. In this survey of 11 questions, seven are focused on the health of the project (the items for each question can be found in the related Figure):
i. On a daily basis, on which criteria do you base yourself to assess the health of your project? (Figure 2.4)
ii. For you, what are the items that are contributing to project success? (Figure 2.5).
iii. Which actions should be taken to improve project health? (Figure 2.6).
iv. What items are contributing to project failure? (Figure 2.7).
v. What are you expecting of a tool that could help you to improve project health? (Figure 2.8).
vi. Which items block you from doing automated tests? (Figure 2.9).
vii. Regarding tests and software quality, which items can help you in the improvement of your project? (Figure 2.10).
The four others questions describe the respondents in the purpose to cross data: company department, responsibilities, years of experience, years of experience inside the company.
The first seven questions are based on a likert scale. For each of these questions, several affirmations are given and the respondents must answer his agreement or not in a scale to define his feeling. The scale specifies several answers to a given affirmation: e.g., strongly disagree, disagree, agree, strongly agree. Moreover, we choose likert scales with an even number of answers. It forces the respondents to have a distinct opinion and to make his mind on one side: agree or disagree. For each question, the respondents is able to answer “NA” if the question is “Not applicable » or if it does not want to give an answer (“No Answer”). Also, each question can be commented to give an other option or opinion.
On a Daily Basis, on Which Criteria do you Base Yourself to Assess the Health of a Project?
It seems that being ahead of time on the schedule is at least an important criteria to measure the health of a project for 93% of the respondents (see Figure 2.4). The relation with the client comes in second place with 86% that think it is an important criterion. In third position comes the software quality with 84%. Fourth is the number of bugs detected in customer acceptance with 81%. The bugs detected in customer acceptance are bugs that should be avoided by the developers. They give a low opinion of the project team to the client and can damage the relation between them. A high number of bugs in customer acceptance shows a lack of quality in the software. The interviews of our previous study concluded that a root cause of the failure of the project is the high number of bugs listed by the clients. This survey confirms this first intuition. While we are not able to manage the relation with the client in this study, reducing the number of bugs seems to be obtainable by helping the developers to check their application before releasing to the client.
For you, what are the Items Contributing to Project Success?
We want to understand what makes a project succeed. As first factor, understanding of the client specifications is essential for the respondents, 98% thinks that this influences project success (see Figure 2.5). As second factor, communication is important for the respondents, the communication in the project team and its cohesion (resp. 96% and 95%), and the expertise of the project leader (93%) have an influence on project success. As third factor comes tests before release and source quality (with resp. 87% and 81%). It is important to note that almost half of the respondents thinks that running tests before release has a high influence (whereas other figures are only about influence). However, 76% of the respondents think that having automated tests has an influence of the project success. Like the previous question, communication between the project entities and the definition of the specifications with the client is out of reach of our study. However, we can improve project quality and make sure that the tests are launched before releasing to the client.
Table of contents :
1 Introduction
1 Context
2 Problem
3 Our Approach in a Nutshell
4 Contributions
5 Structure of the Dissertation
6 List of Publications
2 Motivation
1 Predicting the Health of a Project
1.1 Systematic Literature Review
1.2 Data mining
1.3 Interviews
1.4 Conclusion
2 Developers Insight on Project Quality
2.1 Survey Description
2.2 Results
2.3 Conclusion
3 State of the Art
1 Test Selection Approaches
1.1 Control Flow Graph Approaches
1.2 Dynamic versus Static: Pros and Cons
1.3 Evaluation Criteria
1.4 Test Selection Approach
2 Tooling for Test Selection
2.1 Evaluation Criteria
2.2 Tooling
3 Testing Habits of Developers
3.1 Evaluation Criteria
3.2 Studies
4 Conclusion
4 Comparison of Approaches to Select Tests from Changes
1 Taxonomy of Issues
1.1 Proposed Classification of Issues
1.2 Third-Party Breaks
1.3 Multi-program Breaks
1.4 Dynamic Breaks
1.5 Polymorphism Breaks
2 Experimental Setup
2.1 Case Study Protocol
2.2 Projects
2.3 Dynamic and Static Approaches Tooling
2.4 Metrics
3 Results and Discussion
3.1 RQ1 – Third-Party Breaks Impact
3.2 RQ2 – Dynamic Breaks Impact
3.3 RQ3 – Polymorphism Breaks Impact
3.4 RQ4 – Impact of Combining Solutions
3.5 RQ5 – Weighting of Results with the Number of Commits
3.6 RQ6 – Aggregation of the Results by Commit
3.7 Overall Conclusions
4 Evaluation of Validity
4.1 Construct Validity
4.2 Internal Validity
4.3 External Validity
5 Comparison to Other Works
6 Conclusion
5 Study of Developers’ testing behavior in a Company
1 Experimental Setup
1.1 Research questions
1.2 Experimental protocol
1.3 Filtering and Massaging Data
1.4 Automatic Test Selection
1.5 Interviews with the Participants
2 Results and Discussion
2.1 Case Studies
2.2 RQ1: How and why developers run tests?
2.3 RQ2: How do developers react to test runs?
2.4 RQ3: How and why developers perform test selection?
3 Threats to Validity
3.1 Construct Validity
3.2 Internal Validity
3.3 External Validity
4 Conclusion
6 Impact of the Usage of the Test Selection Tool
1 Test Selection Plugin
1.1 General Overview
1.2 Architecture
2 Case Study
2.1 Data Analysis
2.2 Interviews Description
3 Results and Discussion
3.1 Global Results
3.2 Individual Results
4 Conclusion
7 Conclusion & Perspectives
1 Summary
2 Contributions
3 Future Work
3.1 Industrial
3.2 Academic
A Appendix
1 Analysis of Project Data
Bibliography
