Start on. Show related SlideShares at end. WordPress Shortcode. Share Email. Top clipped slide. Download Now Download Download to read offline. Quality and productivity factors Oct. Quality and productivity factors PPT.
Associative memory. Memory hierarchy. Asynchronous data transfer. Software maintenance. Programming team structure. Related Books Free with a 30 day trial from Scribd. Second Edition James Paul Gee. Blog, Inc. Related Audiobooks Free with a 30 day trial from Scribd.
Who Owns the Future? Jaron Lanier. Quality and productivity factors 1. Quality and Productivity Factors Mrs. Nancy Beaulah MCA. Vanniaperumal College for Women Virudhunagar 2. Individual Ability 2. Team Communication 3. Product Complexity 4. Appropriate Notations 5. Systematic Approaches 6. Change Control 7. Level of Technology 8. Level of Reliability 9. Problem Understanding Available Time Required Skills Facilities and Resources Adequacy of Training Management Skills Appropriate Goals Camaraderie means a social and friendly atmosphere where team members socialize but also help each other.
The second factor in this category consists of clear goals that are necessary so that all team members work toward the same objective. Most general is the factor communication that includes the degree as well as the efficiency of information flow inside the team. In general, what is surprising in the studies is that communication effort is positive for productivity. In discussions, we often hear that communication should be reduced to decrease unnecessary work.
However, the actual problems seems to be the increase of communication effort when putting more and more people on a project. Yet, a high fraction of effort on communication seems like a good investment. Psychological safety is similar to camaraderie but more specifically refers to an atmosphere where individual developers can take risks and share personal information, but know that teammates will handle these risks with respect and kindness.
This is a factor that more recently came into productivity discussions in the context of software projects because of a large study at Google [ 14 ]. Also similar but aiming in a different direction is the sense of eliteness of the team. If the team believes that they are the best engineers always building the highest-quality software, they are more likely to go the extra mile to actually achieve this.
Also related to psychological safety is support for innovation. This contains to some degree safety for taking risks, but it also means that the team members are open to bring in innovations and also change the way they work.
Yet another view on this is team cohesion. Team cohesion describes how well all team members are willing to work together. This does not necessarily include a social and friendly atmosphere but a professional approach to working together.
A common team identity also seems to support productivity, probably by influencing other factors such as camaraderie or the sense of eliteness. Finally, the turnover in the team might be influenced by the factors mentioned so far. Team changes could also be ordered by management because of other influences. In any case, less turnover is better for productivity, and it is one of the few factors that we can easily measure. Therefore, we have factors for the analyst capability, the manager capability, and the programmer capability.
Each refers to the skills of the individuals in their respective roles. For each role, these skill sets will differ, but there is thus far no fixed set of skills necessary for the roles that came out of the studies. Experience does play a role but more in the sense of the experience with application domains and platforms. We have the three factors of application domain experience, manager application domain experience, and platform experience.
The first two refer to how long and with what intensity the developers and managers have worked on software in a specific application domain. Developer personality has been investigated in many empirical studies. Few measure personality according to the state of the art in personality psychology.
A more recent study [ 19 ] found only one personality trait—conscientiousness—impacted productivity positively. Similarly to the study of personalities, another important psychological area has recently been investigated: the emotions of developers. Several studies [ 16 — 18 ] looked at the relationship of happiness of developers and their productivity.
They found indeed that happy developers are more productive. You can find more details in Chapter This environmental factor describes the ratio of uninterrupted hours and body-present hours. The e-factor introduced by DeMarco and Lister in Peopleware [ 3 ] emphasizes that uninterrupted time for work is important for productivity.
Chapter 9 discusses this in more detail, and Chapter 23 shows an idea to improve the e-factor. Although we have not found studies focusing specifically on software engineering teams, there are several studies on office layout that should apply in our context. In software companies, we frequently see open-plan offices with the reasoning that interaction between team members is important.
A recent large study [ 22 ] found no evidence that this is actually the case. Instead, interruptions are much higher; hence, the e-factor becomes worse in open-plan offices. Distributed development of software, meaning software teams physically distributed over several locations in potentially several different time zones, is common today.
There is a considerable body of work on the potential problems with this working mode. It can have a negative effect on productivity.
Also, the workplace itself has an effect on productivity. There are studies investigating aspects such as if there are windows and natural light or the size of the room and space on a desk.
Time fragmentation is related to the e-factor but covers more the aspect of how many different projects and kinds of tasks you have to work on. This results in costly context switches that could be avoided if you could focus on a single project. Finally, proper telecommunication facilities are important so that you can work from home, work efficiently part-time, or interact efficiently with other team members who are in another physical location.
There are many studies looking into the relationship of team size and productivity. It is well established that larger teams lead to exponentially increasing communication efforts that, in turn, lead to lower productivity. Newer, agile software development processes therefore often recommend team sizes of about seven. Also, the requirements stability over a project has been the subject of several studies. Highly unstable requirements lead to time, effort, and budget overruns; overall demotivation; decreased efficiency; and the need for post-implementation [ 20 ].
Again, agile development processes focus on this problem by reducing development cycles to a few weeks. Finally, the planned project schedule needs to fit the actual work to be done. Several studies show that schedules that are too tight in effect reduce the productivity. Our taxonomy of factors influencing software development productivity is extremely diverse. The technical factors range from detailed product factors, such as execution time constraints, to general environment factors such as the use of software tools.
The soft factors have been investigated on the corporate, team, project, and individual levels. For specific contexts, it will be necessary for practitioners to look into each of these factors in more detail.
We hope that this chapter can be used as a starting point and checklist for productivity improvement in practice. The major factors influencing software development productivity can be summarized in a checklist for developers and managers. We are grateful to Melanie Ruhe for previous discussions on productivity and productivity factors. This chapter is not meant to be a full-fledged academic literature review. Instead, we used our prior literature review [ 1 ] as a start and updated it with a search on Google Scholar.
In contrast to the old review, however, we looked at only the first 30 results from to in Google Scholar. Of those results, we extracted any new relevant productivity factors from empirical studies. We did not use studies that only validated factors already on the list to keep this article concise. We also noted that while most of the factors come from academic papers investigating these factors in more detail, the old literature review [ 1 ] also included the books by Boehm [ 6 ] and Jones [ 7 ] as a baseline.
They do not investigate single factors but use a set of factors to discuss productivity. Finally, the extracted academic studies have limitations, such as some of them use lines of code per person-hour as a productivity measure. This is easy to measure but has significant problems because more code is not necessarily good.
We decided to not exclude these studies, however, as the identified factors still might be interesting. Wagner, Stefan and Ruhe, Melanie.
DeMarco, T. Productive Projects and Teams. Cataldo, Marcelo, James D. Herbsleb, and Kathleen M. ACM, Boehm, C. Abts, A. Brown, S. Chulani, B. Clark, E. Horowitz, R. Madachy, D. Reifer, and B. Prentice-Hall, Software Assessments, Benchmarks, and Best Practices. Addison-Wesley, Identifying factors affecting software development cost and productivity.
Software Qual J Tsunoda, M. Inf Technol Manag Cataldo, Marcelo, and James D. Cardozo, Elisa SF, et al. Tan, Thomas, et al. Duhigg, Charles. Lemberg, Per, Feldt, Robert. Graziotin, D. Do feelings matter? On the correlation of affects and the self-assessed productivity in software engineering.
Journal of Software: Evolution and Process. How do you feel, developer? An explanatory theory of the impact of affects on programming performance. PeerJ Computer Science. What happens when software developers are un happy.
Journal of Systems and Software, , Wagner, M. Kalinowski, M. Felderer, P. Mafra, A. Conte, M. Christiansson, D. Greer, C. Lassenius, T. Nayabi, M. Oivo, B. Penzenstadler, D. Pfahl, R. Prikladnicki, G. Ruhe, A. Schekelmann, S.
Sen, R. Spinola, A. Tuzcu, J. Wieringa, Naming the pain in requirements engineering: Contemporary problems, causes, and effects in practice, Empirical Software Engineering 22 5 —, Ray, B. A large scale study of programming languages and code quality in github. You do not have permission under this license to share adapted material derived from this chapter or parts of it.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material.
0コメント