Object-oriented software development is widely believed to ... assumed that during the development the software ..... Projects,â Center for Communications and.
Development Productivity for Commercial Software Using Object-Oriented Methods Tom Potok Mladen Vouk
1.
better than that of "classical" or "procedural" software development.
Abstract
For example, Lewis et al. performed an experiment with undergraduate software engineering students where they studied four cases: use of procedural development without reuse, use of object-oriented development without reuse, use of procedural development with reuse, and use of object-oriented development with reuse [12]. From this experiment, Lewis et al. concluded that, through reuse, the object-oriented paradigm substantially improves productivity. Similarly, Melo et al. conducted an experiment with graduate students that tested the hypothesis that a high level of reuse resulted in a higher productivity rate [13]. They reported that there is a linear relationship between productivity, and reuse rates. This is based on seven projects ranging is size from 5000 - 25000 lines of code, all with varying rates of reuse. In another study, Boehm-Davis et al. report on a comparison of Jackson program design, object-oriented design, and functional decomposition [3]. Three groups of professional programmers, who were familiar with the methodologies, volunteered to develop designs for three experimental problems. Various metrics were recorded, and it was found that different methodologies produce different solutions to the same problems, and that a methodology may cause a reduction in design time, and complexity of a design.
Object-oriented software development is widely believed to improve programmer productivity, however, surprisingly little evidence of this has been published. This paper presents an initial analysis of the productivity measured for 19 software products developed at IBM Programming Laboratories. Half of the products were developed using object-oriented methods, while the other half were developed using traditional “procedural” methods. Our study indicates that first generation object-oriented projects achieve the same productivity rates as follow-on releases of procedural projects. There does not appear to be a productivity penalty for moving to object-oriented technology, but there is apparently no immediate productivity benefit either. Furthermore, for this data, productivity rates increase as project size increases. This runs against the "conventional wisdom" about large projects, and is more surprising given that smaller projects had proportionately larger development teams than larger projects. An initial study of this phenomenon indicates that scheduling effects, such as the Parkinson effect and the Deadline effect, may be responsible for this economy of scale.
2.
Introduction
There are many other studies concerned with the value of object-oriented approach, but very few focus on productivity for software developed in commercial environments by professional programmers who use object oriented methods. In fact, it would appear that most organizations that develop software may not measure software reuse, and the associated productivity [8], and may have only superficial and anecdotal
There are many who believe that object-oriented software approach is the next step in the evolution of software development. One of the reasons is that object-oriented development has great potential for increasing programmer productivity. However, there is little quantitative evidence that real-life productivity of object-oriented software development is indeed consistently 1
information about the effects object-oriented technology has in their environment.
among objects. An OOA model may be expressed informally in diagrams or text, or more formally in entity-relationship (ER) diagrams, data-flow diagrams, state-transition diagrams, Petri nets, or a variety of specialty representation currently available [10, 11, 14, 16].
In this paper we present initial results of a comparative evaluation of object-oriented and procedural development productivity in a commercial environment. In the next Section we give some background information. In Section 4 we present the empirical productivity data. In Section 5 we discuss our data in the context of a milestone-driven software process. The summary is in Section 6.
3.
The object-oriented design (OOD) phase is a transformation from the analysis model into design descriptions. The design phase may include decomposing the analysis level objects, evaluating the use of existing class libraries, and iteratively creating a hierarchy of the decomposed objects. The decomposition of the analysis model is ideally a step-wise refinement, yielding a strong mapping from the analysis model to the final system [5, 11, 14, 16, 17].
Background
A software product is a commercially available software system that includes the packaged software, documentation, and support. It is assumed that during the development the software product is properly analyzed, designed, implemented and tested, and its quality certified prior to release. The first version of a software product we call the first release (or initial release), subsequent versions are called follow-on releases. A software product schedule is the schedule that directs its development from the initial planning stages, through the final product shipment. The significant schedule dates are called milestones. We call a software process where progress is primarily driven by pre-set milestones (schedule-based, or based on some other criteria) a milestone-driven software process [7]. A total project team is a group of people who work closely together to create and deliver a successful software product. This team is made up of programmers, testers, managers, writers, planners, designers, human factors experts, or whatever skill is needed to create and deliver a successful product.
3.1
Object-oriented implementation is a refinement of the design model into executable software. The languages most often used are Smalltalk, and C++. Object-orientation may increase productivity because OOA and OOD, if done correctly, result in products that are cleaner, more understandable, and easier to implement and test, and because re-use, particularly in follow-on releases, may reduce the maintenance and enhancement effort.
3.2
Productivity
We define average productivity of a total software programming team by the following relationships [1, 2]: Team Productivity =
ProjectSize ProjectDuration
(1)
Let a team consist of N persons, let the project size be in thousands-of-lines-of-code (KLOC), and let the project duration be in months. The average personal productivity is the team productivity divided by N. Equation (1) can be rearranged to calculate the effort (in personmonths) expended on a project as follows:
Object-Orientation
There are three basic phases in developing software using object-oriented methods. The first is the analysis phase producing an analysis model, the next is the design phase producing a design model, and the final phase is implementation, producing executable software.
Effort =
ProjectSize PersonalProductivity
(2)
The above equation implies a linear relationship between the effort and the size of a project. However, a number of studies have shown that programmer productivity is not constant over the project and is a function of many factors including product size (see [2] and references therein). The following equation describes a general relationship between project effort, and size:
Object-oriented Analysis (OOA) is the process of defining a model that solves a given problem or meets a set of requirements. This model is in terms of a real world problem space. It consists of an object model, and may include a process model, or state model. OOA may include requirement's analysis, identification of real world objects, and the definition of the interaction
2
Person Months = α(KLOC)β
developed by IBM. Five were developed for mainframe use, and fourteen for workstation use. The products range in size from about 1 thousand (KLOC) to about 1 million lines-of-code. Some of the collected information is shown in Table 1. The presented information includes the size (KLOC) of the code developed in-house, project development duration (calendar months) and staffing level (average number of persons). This level represents the number of people on a total team, not just the programmers. For a small project it is not unusual for half the total team to be non-programmers. It must be stressed that the project size reflects only the code developed in-house, and that, for small projects, this code was often coupled with code developed elsewhere, but that the team size reflects the effort to procure, evaluate and integrate the two codes.
(3)
The common values for α and β found in the literature range from 0.7 to 28 person-months for α, and 0.9 to 1.8 for β. Of course, only certain combinations of α and β values occur and are dependent on the type of software, programmer experience, technology, etc. The COCOMO model is the one of the best know instantiations of this relationship [2]. The most common experience is that the larger the product, the lower the productivity on that project. The sub-linear form of the model (β
