Productivity programing (also called software productivity or productivity development ) describes the level of ability of each programmer or development team to build and develop software systems. Productivity traditionally refers to the ratio between the quantity of software produced and the costs incurred for it. Here the delicacy lies in finding a reasonable way to determine the quantity of software.
Video Programming productivity
Terminology
Productivity is an important topic that is researched in various disciplines such as manufacturing, organizational psychology, industrial engineering, strategic management, finance, accounting, marketing and economics. The level of analysis includes individual, group, divisional, organizational and national levels [5]. Because of this diversity, there is no clear definition of productivity and its influence factors, although research has been conducted for over a century. As in software engineering, the lack of mutual agreement on what is actually productivity is considered to be a major obstacle to a strong discussion of productivity. The following definition describes the best consensus on terminology.
Productivity
Although there is no mutually agreed productivity definition, there appears to be agreement that productivity describes the ratio between output and input:
Productivity = Output/Input
However, in different disciplines, different ideas and, in particular, different measurement units for inputs and outputs can be found. The manufacturing industry typically uses a direct relationship between the number of units produced and the number of units consumed. Non-manufacturing industries usually use working hours or similar units to allow comparison of output and input.
A basic agreement is that the meaning of productivity and the means of measuring it varies depending on what context is being evaluated. In a manufacturing company, the possible contexts are:
- individual machine or manufacturing system;
- manufacturing functions, such as assembly;
- the manufacturing process for a single product or group of related products;
- factory; and
- factory-wide factory system
During the classical production process is considered a simple metric of productivity is simple: how many units of a product with a certain quality generated by the cost. For intellectual work, productivity is much more difficult. How do we measure the productivity of authors, scientists, or engineers? Because of the growing importance of knowledge work (as opposed to manual work), many researchers try to develop productivity measurement tools that can be applied in non-manufacturing contexts. It is commonly agreed that the nature of work is fundamentally different from manual work and, therefore, factors other than simple output/input ratios need to be taken into account, such as quality, timeliness, autonomy, project success, customer satisfaction and innovation. However, the research community in the discipline can not build a widely applicable and accepted means of measuring productivity. The same is true for more specific programming productivity areas.
Profitability
Profitability and performance are closely related and, in fact, often confusing. However, profitability is usually defined as the ratio between income and costs
Profitability = Revenue/Cost
It has a wider scope than performance, ie the number of factors affecting profitability is greater than the number of factors rather than the effect of productivity. Specifically, profitability can change without any change in productivity, e.g. because of external conditions such as cost or price inflation. In addition, the interdependence between productivity and profitability is usually delayed, ie profitability in productivity is rarely reflected in direct profitability profits that are more likely to manifest in the long run.
Performance
The term performance is even broader than productivity and profitability and includes a large number of factors that affect the company's success. Therefore, well-known performance control instruments such as the Balanced Scorecard do incorporate productivity as a central but not unique factor. Another relevant factor is eg. perceptions of customers or stakeholders of the company.
Efficiency and Effectiveness
Efficiency and effectiveness are terms that give further confusion because they themselves are often mixed up and, besides, efficiency is often confused with productivity. The difference between efficiency and effectiveness is usually explained informally because of the efficiency of doing the right thing and the effectiveness of doing the right thing. While there are many other definitions, there is a certain agreement that efficiency refers to the utilization of resources and especially affects the required input of productivity ratios. Effectiveness on the other hand mainly affects the output of the productivity ratio because it usually has immediate consequences for the customer. Effectiveness can be defined as "ability to achieve desired output".
Generally, it is assumed, that the efficiency can be quantified, ie. with the utilization rate, much easier than effectiveness.
Quality
Tangen states: "Improvements in quality, in addition to the fact that products without errors increase the level of output, should not be included in the concept of productivity." However, most of the classical literature in non-software disciplines, especially in manufacturing, does not explicitly address the role of output quality in productivity ratios. Recent works from non-manufacturing disciplines have a stronger focus on knowledge, office or white-collar work and hence are increasingly addressing the role of quality with respect to quality.
Drucker emphasizes the importance of quality for the evaluation of the productivity of knowledge workers: "The productivity of knowledge work must therefore aim first to obtain quality - and not the minimum quality but the optimal quality if not maximized. Only then can one ask:" What is the volume, quantity of work? ""
Saari captures the importance of quality with its broad formula for productivity:
Total productivity = (Quality and quantity of output)/(Quality and quantity of inputs)
However, it seems that attempts to incorporate quality in productivity determination do not lead to a concept that can be operationalized. Currently it is unclear how to measure unclear terms "Quality and quantity of output" and "Quality and quantity of inputs", let alone calculate the ratio.
Maps Programming productivity
Art-Condition in Productivity Programming
In terms of software development is more complicated than in the production of goods. Software development is an engineering process.
COCOMO II
Boehm was one of the first researchers to systematically approach the field of software productivity. The estimated cost model COCOMO - now COCOMO II - is a standard software engineering knowledge. In this model, he defines a set of factors that affect productivity such as the reliability required or the ability of the analyst. These factors have been widely reused in other similar productivity approaches. The rest of the model is based on function point and finally line of source code (LOC). The limitation of LOC as a measure of productivity is very well known.
Jones Software Productivity
Jones is the author of a series of books on software productivity. In addition to some theoretical considerations, the main contribution is the provision and systematic integration of a large number of relevant data for productivity analysis. At least in his two books, he gives a number of productivity factors but also shows that for each project, a series of different factors are very influential. These factors can form the basis for productivity assessment and for comparison with the industry average.
This is one such list:
20 factors whose quantitative impact on software projects has been determined from historical data are as follows:
- The programming language is used
- Program size
- Experience of programmers and design personnel
- New terms
- The complexity of the program and its data
- The use of structured programming methods
- Program classes or distribution methods
- Program type from the application area
- Tools and environmental conditions
- Upgrading existing programs or systems
- Maintain existing programs or systems
- Reusing existing standard and design modules
- Program generator
- Fourth generation languages ​​
- Geo location split of development location
- Potential flaws and removal methods
- (Available) Documentation
- Prototype before major development begins
- Project team and organizational structure
- Staff spirit and compensation
Function Points
The function point was proposed in 1977 by Albrecht as a better measure of size for software than the LOC. In this case it is based on software specification and thus aims to measure the size of its functionality rather than the code itself. The reason is that the size of the code depends not only on the size of the functionality but also the ability of the programmer: better programmers will generate less code for the same function. The function point has undergone several redesigns over the years mainly driven by the International Function Users Group (IFPUG). The group is large with over 1200 companies as members who show a rather strong reception of this size. However, in many domains still lack practical applications because it is often understood to only apply to business information systems.
Software Engineering Based Values ​​
Some researchers propose software engineering based on economics or value-based as an important paradigm in software engineering research in the future. Boehm and Huang point out that it is not only important to keep track of the costs in the software project but also the real value gained, that is the value for the customer. They explained that it is important to make the software business case and keep it up to date. In essence, value-based software engineering focuses on customer value, especially measured in monetary units.
Peopleware
The famous Peopleware Book: Projects and Productive Teams by de Marco and Lister bring the importance of people-related factors to attract the broader audience. They accumulate a wealth of software project experience with good and bad management practices that have an impact on team productivity. They and others point out that this is a decisive problem in software engineering but can only describe them anecdotally.
Factors affecting programming productivity
There may be a large number of factors affecting the productivity of individual and team programming. For example, the software development process used may affect the team's effectiveness and efficiency.
The personality of the software programmer influences the coding style used which, in turn, affects the productivity of the programmers.
References
Further reading
- The Cost Estimation of Software by Cocomo II , Barry W. Boehm et al. , Prentice Hall, 2000. ISBNÃ, 978-0-13-026692-7.
- Developing Products in Half Time: New Rules, New Tools , Preston G. Smith and Donald G. Reinertsen, Wiley, 1997. ISBNÃ, 978-0-471-29252-4
- Programming Productivity , Capers Jones, Mcgraw-Hill, 1986. ISBNÃ, 978-0-07-032811-2
- Estimating Software Costs , Capers Jones, McGraw-Hill, 2007. ISBNÃ, 978-0-07-148300-1
Source of the article : Wikipedia
0 Comments