The impact of new technologies on business productivity and competitivity between the organization is considerable. That impact that in the beginning seemed to facilitate the development of several actions currently is present in every aspect of our lives and determine the way of working in the XXI century. Every type of organizations, from start-ups to big multinationals, are using new technologies as the differential element from the competence.
For that reason, the commercial strategies and politics, and different work organization are being conceived and apply a perspective of digital thinking. The increase in business productivity is not related to the impact of new technologies. The right use of those tools does not only allows a better production but also helps to improve the quality and fast delivery of the products and services.
The technology and the productivity have become two allies essentials to the success of any business project. All the companies that still operate with an obsolete system will not remain much more in the market.
Nowadays, the companies are obligated to adapt their production operations and processes to the new technologies, if they want to survive in the dynamic market. One of the clearest examples of new technology impact on the business productivity is the process automatization , especially in the e-commerce.
The new technologies have been integrated with all the action areas, from the development of new systems and processes to the market research and business development.
Although the new technologies imply improvement of the resource management and the working process, to increase the productivity, we should keep in mind that the real force of change, which determines the improvement, is the employee. Networking can also help you find the right employees to hire. When you hire good employees, you have a better chance of finding those who are more productive which in return affects the productivity of the company. Marketing allows companies to Improve products, monitor customer feedback, generate leads, and build awareness.
Using technology, such as content management systems , allows you to market and grow your company better. For example, you can expand your customer outreach by using social media. From responding to customer complaints and questions on social media to establishing your business by creating your own niche. Not only will you be able to expand your customer pool but you will be able to get your business out there but using online advertising. Online advertising is affordable and effective.
You can also target your ads to a specific group and add specific metrics to your adds to track and analyze what is going on. This will help you to know how your products are doing and what more you can do to grow your company. Productivity affects almost all aspects of business such as payroll, revenue, employee retention, customer satisfaction, company culture, work environment, employee experience, and company identity.
By using technology you are able to positively affect your company. Technology is also constantly evolving. New tools are being created all the time to increase productivity and growth. Your email address will not be published. Skip to content. Allows Remote Working When you get the opportunity to work remotely, you control when you allow distractions and communication with employers or employees in your day, which can leave more time for you to get into your zone.
Ability to Collaborate Technology allows for employees to come together and discuss ideas, find a solution to a problem and to create something new. Organization Technology can help to organize every task that you need to complete and improve productivity along the way.
Marketing Marketing allows companies to Improve products, monitor customer feedback, generate leads, and build awareness. She enjoys learning new skills and helping people. As such, what types of measures are appropriate for understanding software productivity? Productivity in most studies inside and out of the software world is usually expressed as a ratio of output units produced per unit of input effort.
This simple relation carries some important considerations: for example, that productivity measures are comparable when counting the same kind of outputs e. Likewise, that a software development effort with productivity 2X is twice as productive as another effort whose productivity is X.
Therefore, how outputs and inputs are defined are critical concerns if they are to be related as a ratio-type measure. As will become apparent through the survey that follows, other measure types - nominal, ordinal, and interval - are also appropriate indicators to characterize the variables that shape software productivity. In the next section, a survey of studies of software productivity measurement shows there is often a substantial amount of difference with respect to the degree of rigor and the use of accepted analytical methods.
But a number of confounding factors appear in Albrecht's results which undercut the validity of his reported productivity improvement claims. For example, his formula for computing function point values incorporate weighting multipliers which he reports produced reliable results. However, he does not discuss how these weights were determined, or how to determine them when other programming languages and software applications are to be measured.
He also indicates that as department manager, he instructed his program supervisors to collect this function point data. To some extent then, his supervisors were encouraged to have their programs developed in ways that would lead to more function points produced per unit of effort. However, it is unclear whether the function point technique works equally well on non-business application systems that do not rely on accessing large files, retrieving selected data, performing some computations on the data, and producing various reports.
Thus, it is unclear whether the 3 to 1 productivity improvement that Albrecht claims is due to a shifts in the choice of programming language to those that produce more favorable measures, b alternative program development techniques, c choice of multiplier weights, d management encouragement for collecting data that substantiates and rewards measured improvement.
Lawrence observed that source lines of code, number of statements, number of procedure invocations, number of functional units, and number of transfers of control are all highly correlated. Other researchers have substantiated this as well. As such, he chose to employ the number of procedural lines of code divided by the total time put into the programming job by the programmer from the receipt of program specifications to completion of program testing.
That is, Lawrence was interested in measuring the productivity of individual programmers who in turn were developing small programs lines of code. He found that programmer productivity increases with better turnaround, but decreases with online source code testing and interface to a database. In contrast to Albretch, Lawrence does not define what interface to a database means, nor whether the organizations he studied employed database management systems.
Thus, it is not possible to determine whether Albretch and Lawrence agree on the productivity impact of the use of database management systems. However, Lawrence also found that programming experience beyond the first year on the job, structured programming, and walkthroughs contribute little to productivity improvement.
Both Thadhani and Lambert assert that unexpected delay in response time to trivial computing tasks e. Such delays they argue cause a longer delay than the actual elapsed time.
Since LSS development efforts can entail thousands or more of such trivial task transactions, that cumulative time will represent a significant cost to the project. Essentially, they argue that response time has an impact on LSS development projects, so that ample processing resources are critical to enhancing software productivity.
Subsequently, this could be viewed as evidence in favor of providing individual programmers more processing resources such as through the adoption of powerful personal computing workstations as a way to improve software productivity.
That is, if programmers currently must share a small number of heavily loaded computer systems, then providing each programmer with a workstation should improve their collective productivity [43]. The authors focused on classifying productivity drivers according to the ability of a software project manager to control them. They identify two types of factors: product -related factors that are not usually controllable by a project manager, and production process -related factors that are controllable by managers and thus provide opportunity for productivity improvement.
In conclusion, the authors suggest that improving programming productivity requires much more than the isolated implementation of new technologies and policies. Key features of such a program are management commitment and an integrated approach' pp. Chrysler [16] sought to identify some basic determinants of programming productivity by examining programming activities in a single organization. He sought to identify 1 what characteristics of the time to complete a programming coding task can be objectively measured before the task is begun, and 2 what programmer skill attributes are related to time to complete the task.
Although he studied a sample of 36 COBOL programs, he does not describe their size, nor account for the number of programmers working on each. His results are similar in kind to those of Albrecht, finding that programming productivity can be estimated primarily from 1 programmer experience at the current computing facility, 2 number of input files, 3 number of input edits, 4 number of procedures and procedure calls, and 5 number of input fields. King and Schrems [34] provide the classic survey of problems encountered in applying cost-benefit analysis to system development and operation.
The authors observe that system development costs are usually underestimated and difficult to control, while productivity improvements are overestimated and difficult to achieve. Some of the problems they describe include a identifying and measuring costs and benefits, b comparing cost-benefit alternatives, c cost accounting dilemmas, d problems in determining benefits, e everyday organizational realities. For example, two cost accounting or measurement problems that arise are ommission of significant costs , and hidden costs.
Omitting significant costs occurs when certain costs are not measured, such as the time staff spend in design and review meetings, and the effort required to produce system design documents. Hidden costs arise in a number of ways, often as costs displaced either to others in the organization, or to a later time: for example, when a product marketing unit achieves the early release of a software system before the developers have thoroughly tested it that customers find partially defective or suspect.
If the developers try to accomodate to the marketing unit's demands, then system testing plans are undercut or compromised, and system integrity is put in question from the developers point of view. The developers might later become demoralized and their productivity decrease if they are viewed by others or senior management as delivering lower quality systems, especially when compared to other software development groups who do not have the same demands from their marketing units.
King and Schrems also note that conducting quality cost-benefits has direct costs as well. More typically, he observes, that most companies spend 1. Therefore, this article by King and Schrems can be recommended as background reading to those interested in conducting software cost vs. Mohanty [44] compared the application of 20 software cost estimation models in use by large system development organizations.
He entered data collected from a large software project, then entered this data into each of the 20 cost estimation models. He found that the range of costs estimated was nearly uniformly distributed, varying by an order of magnitude! This led him to conclude that almost no model can estimate the true cost of software with any degree of accuracy.
However, we could also conclude from his analysis that each cost estimation model might in fact be accurate within the organizational setting where it was created and used. Although two different models may differ in their estimate of software development costs by as much as a factor of 10, each model may reflect the cost accounting structure for the organization where they were created. This means that different cost estimation models, and by logical extension, productivity models, lead to differrent measured values which can show great variation when applied to software development projects.
However, Kemerer does go so far as to show how function points may be refined to improve their reliability as measures of program size and complexity [31,32], as well as tuned to produce the better cost estimates [30].
But again, function points depend solely upon program source code characteristics, and do not address production process or production setting variations, nor their contributing effects.
Romeu and Gloss-Soler [48] argue that most software productivity measurement studies employ inappropriate statistical analysis techniques. They argue that the type of productivity data usually reported is ordinal data rather than interval or ratio data.
The parametric statistical techniques employed by most software productivity analysts are inappropriate for ordinal data, whereas non-parametric techniques are appropriate. The use of parametric techniques on ordinal data results in apparently stronger relationships e. The consequence is that studies of productivity measurement claiming statistically substantiated relationships based on inappropriate analytical techniques are somewhat dubious, and the strength of the cited relationship may not be as strong as claimed.
Boehm [9] reported that productivity on a software development project is most keenly affected by who develops the system and how well they are organized and managed as a team. Following this, Scacchi [50] reviewed a number of published reports on the problems of managing large software engineering projects. He found, to no surprise, that when projects were poorly managed or poorly organized, productivity was substantially lower than otherwise possible.
Poor management can nullify the potential productivity enhancements attributable to improved development technologies. Scacchi identified a number of strategies for managing software projects that focus on improving the organization of software development work. These strategies identify conditions in the workplace, and the skills and interests of the developers as the basis for project-specific productivity drivers. For example, developers who have a strong commitment to a project and the people associated with it will be more productive, work harder, and produce higher quality software products.
This commitment comes from the value the developers expect to find in the products they produce. In contrast, if they do not value the products they are working on, then their commitment will be low and their productivity and quality of work will be lower.
So an appropriate strategy is to focus in organizing and managing the project to cultivate staff commitment to each other and to the project's objectives [cf. When developers are strongly committed to the project and to a team effort [38], they are more than willing to undertake the unplanned for system maintenance and articulation work tasks needed to sustain productive work conditions [6,7].
Scacchi concludes that strategies for managing software development work have been overlooked as a major contributor to software productivity improvement, and thus require further study and experimentation.
Boehm and associates at TRW [11] described the organization of a software project whose objective was to develop an environment to enhance software productivity by a factor of 2 in 5 years, and 4 in 10 years. The project began in , and the article describes their progress after four years in assembling a software development environment that should be able to support TRW development projects.
Surprisingly, their software environment contains many tools for managing project communications and development documentation.
0コメント