International Journal of Scientific & Engineering Research, Volume 6, Issue 2, February-2015 1333

ISSN 2229-5518

Software development productivity impact from an industrial perspective

Samer I. Mohamed

Abstract—Software development productivity is one of the major and vital aspects that impacts software industry and time to market of many software products. Although many studies have been conducted to improve the productivity measurements within software engineering research domain, productivity is still an issue in current software development industry because not all impacting factors and their relationships are known. This paper sheds a light on some of these factors and assesses their impacts as seen by random sample of industrial software SMEs. It also elaborates the main best practices that help in improve the software productivity based on real industrial projects. The resulting list of factors and best practices can be utilized to guide further productivity analysis and taken as basis for building improved and more optimized productivity models. Paper identifies the productivity measurements challenges and recommend set of metrics that can be utilized as basis for productivity estimation models

Index Terms— Software productivity, Volatility, Technical factors, non-technical factors, Best practices, SMEs, SMART requirements, software metric.


—————————— ——————————
oftware development industry nowadays becomes one of the main industries that contributes on the evolution of the computer-based systems. Many organizations currently investing huge amount of money to improve their productivi- ty and time to market to gain larger market share and increase their operational margin. Productivity in software develop- ment has been an important research area for several decades now where successful organizations focus their R&D to im-
There are many different measures for software productivity
within the literature. The most common and traditional ap-
proaches are the lines-of-code (LOC) and function points (FP),
i.e., the amount of LOC or FP produced per hour by a devel-
oper [11]. Based on this, there is a large amount of studies on
various aspects of productivity. The two mentioned measures
and several more dimensions have been analyzed and detailed
within the literature.
Our contribution through this paper, is the introduction of a
balanced and mixed approach for both the industrial and the-
oretical perspectives of those factors that impact the software
productivity. Although the software engineering literature in
that area often has a strong emphasis on mainly technical fac-
tors such as the software size or the product complexity. How-
ever, there are other non-technical factors that impact software
productivity as has been proved by Brodbeck [1] who has
shown that more than a third of the time a typical software
developer is not concerned with technical work.
A productivity measure commonly is understood as a ratio of
outputs produced to resources consumed. Experience shows that no single productivity measure applies in all situations for all purposes. Instead, organizations must craft productivity measures appropriate to their processes and information needs. In addition to the wide range of possible inputs and outputs to be measured, the interpretation of the resulting productivity measures may be affected by other factors such as requirements changes and quality at delivery.
There are different standards for productivity measurements like IEEE 1045 standard which describes the calculation of productivity in terms of effort combined with counts of lines of code or function points. Besides ISO/IEC 15939 standard which is the basis for the Measurement and Analysis Process Area of the Capability Maturity Model – Integration. Challenges around the productivity measurements arise be- cause productivity may vary across the organization itself due to changes and dynamics within project itself with respect to other running projects. Besides the factors that impacting the different projects are themselves different with different na- tures.
The paper is organized as follows: section II gives a back- ground for the early studies done on software productivity as a concept; section III introduces the case study targeted by this paper; where case study description, details, results, and rec- ommendations are detailed; section IV is the conclusion of this study.


Software development is a great expense for most organiza- tions, thus, software development productivity can have a significant impact on the organization’s ability to compete and survive. Currently, most software development organizations are not optimized. There is an increasing demand for software especially for embedded systems. However, without im- proved efficiency, it will be difficult to take advantage of these opportunities in a cost-effective manner.
Tools will not be the only facility to succeed; but a need for a process that ensures quality software can be produced consist- ently and efficiently has an important effect. Like the various automobile manufacturers, different development organiza- tions today typically have access to roughly the same produc-

IJSER © 2015

International Journal of Scientific & Engineering Research, Volume 6, Issue 2, February-2015 1334

ISSN 2229-5518

tion tools and technologies. The organizations that have a pro- cess for leveraging them most successfully are the ones with the highest productivity and the lowest production costs and the best one to compete.
There are extensive researches in the measurement of the de- velopment productivity. Humphrey and Singpurwalla [2] use the statistical techniques of time series analysis to predict the productivity of software development with reasonable accura- cy. Blackburn et al. [3] imparts a global survey of software de- velopers on improving speed and productivity of software development. The most famous model that involves produc- tivity is COCOMO by Boehm [4, 5]. It is a cost-estimation model in which the productivity of the developers obviously plays a decisive role. Lakhanpal [6] concentrated on character- istics of groups and their influence on productivity. Brodbeck describes in [7] that in a survey, the projects with a higher communication effort also were more successful.
Even the intensity of internal communication is positively cor- related with project success. This is in contrast to common software engineering belief that high communication effort hampers productivity. Wohlin and Ahlgren have described factors and their impact on time to market in [8]. They use 10 different factors in their study, mostly factors that are covered by the different publications. They also include product com- plexity, methods, tools and requirements stability that could be considered as technical factors.
Blackburn, Scudder, and VanWassenhove [9] studied the fac- tors and methods that improved productivity in Western Eu- ropean companies. They found project duration and team size to be significant. Chatzoglou and Macaulay [10] interviewed participants of over a hundred software projects about several factors and their influence on productivity. They found that experience, knowledge and persistence of the team members is considered important. Also the motivation of the users and their communication with the rest of the team play a role. Fi- nally, the available resources, tools and techniques used and the management style are important factors
These studies focus mainly on the measurement of the productivity, there are unfortunately very few investigations on the elements that influence the productivity. While the basic model for productivity measurement based on process that converts inputs into outputs consuming resources to do so. The input may be the requirements or cost invested for the software project and the product output may be another work product like documentation or value gain from the software product.


3.1 Metric design consideration

Designer of any productivity measure should consider the following items through defining a precise productivity met- rics:
• Scope of resources – which resources get counted?
• Scope of inputs (Efforts) – Which input efforts get counted?
• Scope of outputs (product) – which products get counted?
In the previous discussion we discussed couple of the basic sizing measures for the productivity output or numerator which are Function Point (FP) or functional input size measure and Source Line Of Code (SLOC) or physical output size measure. While there are factors impacting the efforts required to produce a given quantity of software (size) like smart tech- nologies, code generator tools, and other non-technical as- pects. Consequently the effects of these technologies must be considered in determining productivity either by weighting the size measures or defining multiple productivity measures for different development scenarios. More than one size measure may be needed to capture all of the information needed about the quantity of product delivered. That is soft- ware produced by different methods may need to be counted separately. Key through designing a metric to measure or judge about software productivity is to understand what the metric will size or measure and if the data required for that purpose is available and can be easily collected within the software organization. Each metric matters to specific team or someone based on value gained from the metric itself like governance or compliance requirements. For example size (SLOC, FP) and speed (Velocity, story points) metrics are im- portant to project managers through planning, while quality and reliability metrics are important to organization top man- agement and customers to maintain margin and revenue. It’s important to utilize the productivity metric through compari- sons either between teams or over different period of times for the same team to measure the improvements gained from some planned actions.
The software engineering industry is domain where stake- holders, clients and the end users influence inputs and out- puts, which produces a contribution to both the internal and external efficiency. Hence, a totally different approach to productivity has to be undertaken in order to obtain a global measure that establishes how well a software engineering or- ganization uses resources to create outputs with acceptable perceived quality and customer value [28]. Thus, inputs and outputs measurement should consider both quantity and qual- ity. This importance is reflected in the premises that Grönroos and Ojasalo established: “The better the perceived quality that is produced using a given amount of inputs (service provider ’s inputs and customers’ inputs), the better the external efficien- cy is, resulting in improved service productivity” and “The more efficiently the service organization uses its own re- sources as input into the processes and the better the organiza- tion can educate and guide customers to give process- supporting inputs to produce a given amount of output, the better the internal [28].

3.2 Metric design challenges

The challenge behind productivity metric is the multiple factors that impact the productivity outputs and inputs. One of the other main challenges with productivity metric design

IJSER © 2015

International Journal of Scientific & Engineering Research, Volume 6, Issue 2, February-2015 1335

ISSN 2229-5518

is the abstract level where the designed metric is applicable under different conditions and in different originations. This proved to be very challengeable especially when each organi- zation has its own structure, environment and process aspects that are in total impact their productivity measurements. Or- ganization maturity in measuring and collecting the metric data is one of the other factors that controls how the meas- urement process will be successful. Since software product development life cycle go through different phases starting from requirements elicitations towards delivery, you have to use different metrics to measure the productivity in each phase which adds more difficulty in tracking and data collec- tions. One of the main and important challenges that high- lighted within this paper is the impact of non-technical factors on the productivity measurements. Software engineering ac- tivities are capital intense, so the human factor has to be ana- lyzed in any management practice order to obtain a more ade- quate result. In the context of productivity measurement, it is well accepted that factors related to personnel such as (tech- nical, non-technical) capabilities and skills, and (programming language, project, process…) experience influence directly on
productivity results. In addition to these factors, and consider- ing the lack of literature related to this area, its recommended that other factors such as motivation, performance manage- ment practices, compensation and rewards systems, organiza- tional climate, and happiness could influence productivity results; but it is not clear how they influence and how to in- troduce them in productivity measurement. Thus, a wide range of research possibilities presents through the combina- tion of knowledge of human resources management and productivity management, which could lead to a transfer of cognition for a common research purpose [27]. Challenges related to designing metric for code reusability still under re- search on how it can be linked to productivity measurement. Besides the challenges related to unresolved links between code reuse and some other tasks in the software engineering cycle like requirements engineering and design phases make it hard to select Commercial of the Shelf (COTS). Another chal- lenge is the design of metric that could be applied in both new development and maintenance projects, considering the dif- ferences.

3.3 Productivity metric samples

Once the inputs, outputs, and factors influencing produc- tivity measurement are defined, a formulation of the measure can be established. Hence, specific metric can be defined and each organization may use one or several of them for measur- ing its productivity. In order to sum up the state of the art about inputs, outputs and metrics, the most used in each cate- gory are presented in Table 0. They are ordered according to the measurement difficulty, from easier to harder. The degree of representation scale of the production process itself is also represented: lower difficulty measures are less representative of the production process than harder measures.



Inputs Outputs Metric


4.1 Case description

The Case is based on an industrial survey performed among group of 50 software engineers and Subject Matter experts (SMEs) from different industrial domains within software de- velopment field. The selected sample of SMEs takes into con- sideration different diversity aspects within technology, indus- trial domain, SME job level, application domain, project types and software development models. This is basically to ensure unbiased outcomes and normal weight distribution of the dif- ferent factors that impact software productivity within soft- ware development spectrum.

4.2 Case details

The survey presented in this case study has different types of questions varies between multiple choice questions MCQ and open type questions where interviewee has to put his own answer. Although 95% of the questions are MCQ but the re- maining 5% was needed to assess interviewee judgments on some productivity factors and best practices.
The survey main objectives are basically:
• Gather basic information about interviewee and pro- jects types.
• Assess time wasted in non-productive tasks com- pared to other productive ones.
• Evaluate those factors that impact the total productiv- ity from interviewee perspective.
• Identify those best practices to improve the software productivity either adopted or proposed by the inter- viewee.

IJSER © 2015

International Journal of Scientific & Engineering Research, Volume 6, Issue 2, February-2015 1336

ISSN 2229-5518

• Measure the impact of external and non-technical fac- tors on productivity.
The design of the survey was done to assess ratio and impact of different factors impacting the productivity either technical or non-technical aspects.
Technical aspects like requirements volatility, tooling, tech- nical training, rework due to poor quality and bug fixes, inno- vation support, project duration, application complexity, tech- nical experience, status updates/admin impact, and modern programming practices has been assessed.
Non-technical aspects like appreciation and motivation, team cohesion, software size relative to application size (disecono- my of scale), turnover/attrition, work location, environmental effect like noise/lighting effect, defensive management, team size and roles and responsibilities clarity has been assessed and compared against technical aspects.
Each factor impact on productivity from the above listed ones has been assessed in range from low level to very high level.
Survey also has identified the best practices to improve the software productivity and the adoption methodology ranging from unknown level to standard level as follows:

• Desks away from loud employees like managers, support, sales that are always on the phone.

• Deal with SMART requirements.

• Improve estimation accuracy.

• Use short task schedule.

• Being part of small and well organized project team.

• Use prioritized task list.

• Less context switching between multiple projects, or because of changing specs.

• Make sure to allocate time for Refactoring and opti- mization before QA gets to it.

• Code reviews.
• Reusability.
• Technical training.
• Pairing between developers through development.
• Adopt minimal constrains validation.

• Improve communication between Business Side and developers.

• Eliminate scope creep.

• Co-operative work environment.

• Have a system for distributing tasks.
• Increasing code knowledge.
• Prevents customer-architect misunderstandings by supporting agile development processes with proto- typing, short iterations, and other practices that pro- mote early and frequent customer interaction.
Prevents architect-developer misunderstandings by enforcing policies such as requiring that a test case be written for every use case, forcing developers to think about each requirement from different perspectives.

4.3 Case results

In this section we will show the outcomes from the produc- tivity survey and how these outcomes related to previous ana- lytical studies in this field [16].
These outcomes will be classified into two main categories:
I) Impact of different factors on software development productivity either technical or non-technical as- pects.
II) Best practices adopted by developers either related to technical or process/project-related aspects.
Table 1. shows the impact of technical factors on software productivity. Each factor range between ‘Low’ and ‘High’ through ‘Average’ values.


Impact of technical aspects on software productivity






High (%)













Status updates








Project duration




App. complexity




Technical experi- ence




Modern pro-

gramming prac- tices




Data of table 1. are illustrated graphically in figure 1.

IJSER © 2015

International Journal of Scientific & Engineering Research, Volume 6, Issue 2, February-2015 1337

ISSN 2229-5518

Fig 2. Non-Technical factors effect on software development productivity

Fig 1. Technical factors effect on software development productivity

Table 2. shows the impact of non-technical factors on software productivity. Each factor range between ‘Low’ and ‘High’ through ‘Average’ values.


Impact of non-technical aspects on software productivity
Best practices adopted by software development also have impact on productivity as provided by the results/outcomes from the survey. These results are classified into main classes. The first class related to technical best practices while the se- cond one is related to the project/process best practices.
Table 3. shows the impact of adopting different types of tech- nical best practices on software productivity. Each practice range as detailed earlier between ‘Not available’ and, ‘Stand- ard’ where practice is used as standard use, ‘Training needed’ where practice is used but need more development to be ma- terialized, ‘Has major value’ where the practice has practical value on software productivity.


Technical best practices impact on software productivity
The data from table 2. Also presented graphically in figure 2.
The data from table 3. Are illustrated graphically in figure 3.

IJSER © 2015

International Journal of Scientific & Engineering Research, Volume 6, Issue 2, February-2015 1338

ISSN 2229-5518

Fig 3. Technical best practices effect on software development productivi- ty

Table 4. shows the impact of process/project best practices on software productivity. Each practice range as detailed earlier between ‘Not available’ and ‘Standard’.
The data from table 4. Also presented graphically in figure 4.


Impact of process/project practices on software productivity

Fig 4. Process/project practices effect on software development productivi- ty

4.4 Case results analysis

Analyzing the results of this case study/survey, we conclude the following points as follows [21]:
With respect to technical factors, here are the analytical out- comes:
• Requirements volatility has major negative impact on productivity especially through the system design and development.
• Use state of the art tooling on different process, pro- ject, technical or technological levels will highly affect positively the software productivity through automa- tion.
• Technical training is vital for productivity improve- ment and has high impact to improve the productivi- ty.
• Rework due to poor quality or bug fixes impact productivity negatively but with lower weight/impact.
• Spending much more time on doing status updates/or admin work impacts productively negatively with average weight.
• Innovation support from the upper management has high positive impact on improving the software productivity.
• Project duration has average impact on the software productivity if it’s within allowable limits (1 to 2 years). Productivity for those project with duration more than 2 years decay with time as developer ’s in- terest and motivation reach a saturation levels.

IJSER © 2015

International Journal of Scientific & Engineering Research, Volume 6, Issue 2, February-2015 1339

ISSN 2229-5518

• Application complexity is directly correlated with the software productivity, but most of the interviewees see this has average impact only because the impact will be high at project start then decay with learning curve improvement along with project lifetime.
• Having business and technical experience with the application domain/field will help indeed to improve the development productivity and increasing code knowledge.
• Adopting modern programming methodologies have very high positive impact on improving software productivity [23].
With respect to non-technical factors, here are the analytical outcomes [26]:
• Appreciation and saying THANK YOU has the magi- cal impact on the developer ’s spirit and motivation level, the thing that improves the software productivi-
ty [15].
• Team cohesion and healthy work environment have very high positive impact on software development productivity.
• Software size has neutral impact on the software productivity especially with adopting the latest state of the art methodologies and modern programming practices and tooling.
• Turnover/attrition has high negative impact on the software productivity because it’s directly correlated to the productivity of the team in general and devel- oper ’s spirit in particular.
• Having work location nearby home has a major im- pact on the developer productivity, the nearer the work location the more productivity outcomes and vice versa because of time/efforts waste due to lengthy transportation.
• Work environment conditions (Noise, lighting, seat- ing, fresh air, others) have average impact on the productivity.
• Relationship between management and employees has high impact on the employee productivity, defen- sive management is negatively impacting resultant productivity and vice versa for supportive manage- ment.
• Working in a team or small groups indeed has major impact on productivity as explained in the team cohe- sion factor, but the team size also has an average im- pact on the productivity depending on the team size itself. If the team size up to five, then healthy com- munication and controllable/manageable deliverables can be maintained. Increasing the team above five
will drastically impact communication in between developers and accordingly the resultant software productivity [13].
• Having clear roles and responsibilities for all stake- holders within the project will maintain healthy communication and clarify the boundaries between interacting roles, the thing that minimize the root cause for any conflicts or major escalations. This will definitely will improve the net productivity
With respect to technical best practices, here are the analytical outcomes [17]:
• Deal with SMART requirements through the full de- velopment life cycle starting from elicitations towards
testing through design and development has vital role to ensure a match between what is requested by the client and what is implemented by the development team. Although most of the interviewees see that adopting this practice is not available in many pro- jects due to variations in maturity levels of the differ- ent stakeholders, but still acknowledge its vital value [19].
• Code refactoring/reusability is one of the other im- portant aspects in modern programming practices to best reuse/re-structure the exiting code core without changing the external interface with the integrated systems. Survey shows that this practice has major value on improving the system perfor- mance/maintainability but not available for new de- velopment projects where time constrains exists [21].
• Code reviews is one of the important aspects in soft- ware development and adopted as standard by most of the interviewees through pairing approach. This ensures better quality and early bug detection which improves the rework cost and enhance net productivi- ty and accordingly the time to market [20].
• Agile development is one of the modern techniques for software development that adapts with the current market demand dynamics and fulfill the increase de- mand on new products with minimum time to market especially for mobile and small scale products. This practice is used as standard between most of the in- terviewees currently to adapt with market trends [21].
• Testing is one of the main components in the devel- opment life cycle. Incorporating the testing early in the design phase or even in the elicitation phase is very important to ensure every developed compo- nent/use case has its own test case. Adopting this as standard will lead to better quality, less rework costs, high productivity.

IJSER © 2015

International Journal of Scientific & Engineering Research, Volume 6, Issue 2, February-2015 1340

ISSN 2229-5518

• Technical training and ongoing courses that adapt with the latest state of the art technologies is of a great need between most of the interviewees because it keeps them with the technological rapid advances and keeps the momentum for improving the business and technical experience.
With respect to process/project best practices, here are the ana- lytical outcomes [19]
• Controlling the noise level in most of the organiza- tions is very hard although its importance to facilitate
a noise controlled climate for the software engineers. Most organizations currently balance between in- creasing number of meeting rooms versus the open space work locations depending on the development approach (ex. Agile development requires special ar- rangement for seating). Most of the interviewees see that 10-20% of their time almost wasted due to high noise level within the work place.
• Project management and alignment has an important role to facilitate structured and well organized climate for the development team to deliver starting from re- quirements specification towards project delivery, and to isolate any road blocks or management issues that waste their time. Switching between projects is mixed blessing as seen by most of the market leaders and management where it could motivates the engineers while impacting the net productivity because of addi- tional overhead to gain the knowhow and learning curve.
• Communication consumes basically considerable amount of anyone time, while it takes around 90% from the project managers, it also consumes between
10-30% of developer bandwidth. Thus improving the way of communication both internally between team members and externally with the project stakeholders has vital role and directly correlated with the team productivity in general and software engineer in spe- cific [14].
• Scope creep is one of the aspects that lead to project failures and client dissatisfaction. Thus eliminating the scope creep is one of the standards adopted by many organizations to ensure project successful de- livery.
• Improving the process and using more automation is vital to minimize the unnecessary overhead and ad- min work especially this related to estimation process and other progress/reporting tracking tools. Although it’s important for the PM to track the project progress and prioritize the task list for the team, S/he needs to
control the additional overhead that impacts produc- tivity via tooling and improved process.
• Working in a team is much better compared with working individually if it’s performed within control- lable ranges. Groups of 3 to 5 engineers is the opti- mum within software development teams from com- munication, cooperation, controllability, and delivery perspectives [25].
With respect to %time wasted in non-productive tasks relative to other productive ones, here are the analytical outcomes
• Meeting/talks (Technical) consumes around 20-30%.
• Presentations (Business related) consumes 5%.
• Project management/organization consumes 5%.
• Application development consumes 50%
• Others (ex. Coffee, Lunch) consumes 10%
• Most of S/W engineers consumes around 75% of their annual leaves.
Only 25% of the S/W engineers spend overtime hours outside of their normal working hours.

4.5 Case recommendations/proposed actions

From the analytical outcomes detailed in earlier sections, we come up with list of recommendations and actions to better improve the software development productivity for any soft- ware development organization in general and software engi- neer in particular [24].
• Minimize the requirements volatility via adopting proper change/release management process, proper requirements management tools and modern/agile
development methodology.
• Increase automation and tooling that eliminate manu- al and unnecessary overhead. Open source tools spread over the web have vital value and provide quick solutions for many problems with min/no costs.
• Organizations need to invest in their teams via tech- nical training, R&D support, and innovation funds.
• Healthy relationship between the management and employees/engineers is the quick win for improving the net outcomes from the factory. This can be ex- pressed in many ways simply via THANK YOU.
• Facilitate nearby location to home with multiple sites and WFH (Work From Home) facility will help in first minimize transportation time/efforts and improve the productivity.
• Organizations need to balance between the work from office and WFH days to maintain healthy communica- tion and minimize the wasted times/efforts.

IJSER © 2015

International Journal of Scientific & Engineering Research, Volume 6, Issue 2, February-2015 1341

ISSN 2229-5518

• Clear R&R is vital for the whole deliverables of any organization in general and software engineers in specific, where boundaries and interface with external world identified. This will enable the engineer to un- derstand clearly what to do and what to avoid lead to better outcomes and minimal issues/escalations.
• Using modern programing practices like code refac- toring/reusability, reviews, SMART requirements, ag- ile development, pairing, and minimal constrains val- idation are important form the technical perspective to improve the quality, controllability and productivi- ty.
• Adopting better process and project management pol- icies like eliminate scope creep, facilitate cooperative environment, short task schedule, small project teams, prioritized list of tasks, distribution task tools, and desk away from noise sources will help in minimize the overhead and eliminate any sources of distrac- tions.
Organizations need to consider with same weights both the technical and non-technical aspects/sides of the factors impact- ing the productivity as they have almost if not exactly similar, matching effect on the productivity.


In software development literature, productivity is a com- plex concept that needs to be tackled depending on the soft- ware project factors. There are technical and non-technical factors which has a considerable effect on the software productivity. This papers shed a light on the main factors both technical and non-technical that impact software productivity. It also explores the different best practices adopted by soft- ware engineers and shows its effect as seen by the industrial software engineers in different domains. List of recommenda- tions and corrective actions has been provided as way for con- tinual improvement. Finally, software productivity measure- ment is a learning activity and therefore, history information related to factors and measures is required. Hence, in order to learn and keep improving software engineering processes, organizations may continuously record and accumulate di- verse metrics of their project. However, establishing this rec- ord process is not enough; organizations should achieve a bal- ance in the investment of recording the required data and its future in order to accomplish improved goals. In this direc- tion, there have been some national and international research organizations responsible of the creation of specific projects for establishing data banks of productivity measures along with many measurement factors, but generally these projects


The authors wish to thank HP organization for supporting this
research study through survey sessions with software devel- opment team in different domains and industry areas.


[1] F. C. Brodbeck and M. Frese, editors. Produktivit¨at und Qualit¨at in

Software-Projekten. R. Oldenbourg Verlag, 1994.

[2] W. S. Humphrey and N. D. Singpurwalla, N.D. 1991. “Predicting (individual) software productivity,” IEEE Trans. Software Engineer- ing,, vol. 17, pp. 196 – 207, Feb.1991.

[3] J. D. Blackburn, G. D. Scudder, and L. N. Van Wassenhove. Improv- ing speed and productivity of software development: A global sur- vey of software developers. IEEE Transactions on Software 1996.

[4] B. W. Boehm and P. N. Papaccio. Understanding and controlling software costs. IEEE Trans. Softw. Eng., 14(10):1462–1477, 1988

[5] B. W. Boehm, C. Abts, A. W. Brown, S. Chulani, B. K Clark, E. Horo- witz, R. Madachy, D. Reifer, and B. Steece Software Cost Estimation with COCOMO II. Prentice-Hall,2000.

[6] B. Lakhanpal. Understanding the factors influencing the performance of software development groups: An exploratory group-level analy- sis. Inform. Software Tech., 35(8):468–473, 1993.

[7] F. C. Brodbeck. Software-Entwicklung: Ein T¨atigkeitsspektrum mit vielf¨altigen Kommunikationsund Lernanforderungen. In Brodbeck and Frese [8], pages 13–34.

[8] C. Wohlin and M. Ahlgren. Soft factors and their impact on time to market. Software Qual. J., 4(3):189–205, 1995

[9] K. Maxwell, L. VanWassenhove, and S. Dutta. Software development productivity of european space, military and industrial applications. IEEE Trans. Softw. Eng., 22(10):706–718, 1996

[10] P. D. Chatzoglou and L. A. Macaulay. The importance of human factors in planning the requirements capture stage of a project. Int. J. Proj. Manag., 15(1):39–53, 1997

[11] A. J. Albrecht. Measuring application development productivity In Proc. Joint SHARE/GUIDE/IBM Application Development Symposi- um, pages 83–92, 1979

[12] C. Jones. Programming Productivity: Steps Toward a Sci- ence.McGraw-Hill, 1986.

[13] T. K. Abdel-Hamid. The dynamics of software project staffing: A system dynamics based simulation approach. IEEE Transactions on Software Engineering, 15(2):109–119, 1989

[14] S. Alper, D. Tjosvold, and K. S. Law. Conflict management, efficacy, and performance in organizational teams. Personnel Psychology,

53:625–642, 2000

[15] R. Berntsson-Svensson and A. Aurum. Successful software project and products: An empirical investigation. In Proc. 2006 ACM/IEEE International Symposium on Empirical Software Engineering (ISESE

’06), pages 144–153. ACM Press, 2006

[16] J. D. Blackburn, G. D. Scudder, and L. N. Van Wassenhove Improv- ing speed and productivity of software development: A global sur- vey of software developers. IEEE Transactions on Software Engineer- ing, 22(12).1996.

[17] R. P. Cerveny and D. A. Joseph. A study of the effects of three com- monly used software engineering strategies on productivity software enhancement Information & Management, 14(5):243–251, 1988

IJSER © 2015

International Journal of Scientific & Engineering Research, Volume 6, Issue 2, February-2015 1342

ISSN 2229-5518

[18] P. D. Chatzoglou and L. A. Macaulay. The importance of human factors in of Project Management, planning the requirements capture stage of a project. International Journal 15(1):39–53, 1997

[19] G. R. Finnie, G. E. Wittig, and D. I. Petkov. Prioritizing software de- velopment productivity factors using the analytic hierarchy process. Journal of Systems and Software, 22(2):129–139, 1993.

[20] Z. Jiang, P. Naud´e, and C. Comstock. An investigation on the varia- tion of software development productivity. International Journal of Computer and Information Science and Engineering, 1(2):72–81, 2007

[21] C. Jones. Software Assessments, Benchmarks, and Best Practices.

Addison-Wesley Information Technology Series. Addison-Wesley,


[22] P. Mohagheghi and R. Conradi. Quality, productivity and economic benefits of software reuse: a review of industrial studies. Empirical Software Engineering, 12(5):471–516, 2007.

[23] D. Port and M. McArthur. A study of productivity and efficiency for object-oriented methods and languages. In Proc. Sixth Asia-Pacific Software Engineering Conference (APSEC ’99), pages 128–135. IEEE Computer Society, 1999.

[24] J. Turcotte and L. W. Rennison. The link between technology use, human capital, productivity and wages: Firm-level evidence. Interna- tional Productivity Monitor, 9:25–36, 2004

[25] R. H. Rasch. An investigation of factors that impact behavioral out- comes of software engineers. In Proc. SIGCPR. ACM Press, 1991

[26] C. Wohlin and M. Ahlgren. Soft factors and their impact on time to market. Software Qual. J., 4(3):189–205, 1995

[27] Koskinen, K. U. (2008). Boundary brokering as a promoting factor in competence sharing in a project work context. International Journal of Project Organisation and Management, 1(1), 119-132.

[28] Grönroos, C., & Ojasalo, K. (2004). Service productivity: Towards a conceptualization of the transformation of inputs into economic results in services. Journal of Business Research, 57(4), 414-423

[29] Boehm, B. W. (1987). Improving Software Productivity. Computer,

20(9), 43-57.

[30] Boehm, B. W. (2006). A view of 20th and 21st century software engineering. Paper presented at the Proceedings of the 28th international conference on Software engineering.

[31] Boehm, B. W., Abts, C., & Chulani, S. (2000). Software development

cost estimation approaches - A survey. Annals of Software Engineering,

10(1), 177-205.

[32] Colomo-Palacios, R., Tovar-Caro, E., García-Crespo, Á., & Gómez- Berbís, J. (2010). Identifying Technical Competences of IT Professionals: The Case of Software Engineers. International Journal of Human Capital and Information Technology Professionals 1(1), 31-43.

[33] Cusumano, M., MacCormack, A., Kemerer, C. F., & Crandall, B. (2003). Software Development Worldwide: The State of the Practice. IEEE Softw., 20(6), 28-34.

[34] Dalcher, D. (2006). Supporting software development: enhancing productivity, management and control. Software Process: Improvement and Practice, 11(6), 557-559.

[35] Fitzgerald, L., & Moon, P. (1996). Performance measurement in service industries: making it work. London: Cima.

[36] Foulds, L. R., Quaddus, M., & West, M. (2007). Structural Equation Modelling of Large-scale Information System Application Development Productivity: the Hong Kong Experience. Paper presented at the 6th IEEE/ACIS International Conference on Computer and Information Science, 2007. ICIS 2007.

[37] Gaffney, J. (1989). Software reuse--key to enhanced productivity:

some quantitative models. Information and Software Technology, 31(5),


[38] Kitchenham, B., & Mendes, E. (2004). Software Productivity Measurement Using Multiple Size Measures. IEEE Transactions on Software Engineering, 30(12), 1023-1035.

[39] Koskinen, K. U. (2008). Boundary brokering as a promoting factor in competence sharing in a project work context. International Journal of Project Organisation and Management, 1(1), 119-132.

[40] Krishnan, M. S., Kriebel, C. H., Kekre, S., & Mukhopadhyay, T. (2000).

An Empirical Analysis of Productivity and Quality in Software

Products. Management Science, 46(6), 745-759.

IJSER © 2015