Page 105 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 5: Software Project Planning

Moreover, the work related to software development is typically multi-specialist in character, in Notes
the sense that it depends on dissimilar kinds of expert competencies being combined and aligned
in different phases. Thus, software development may be described as a knowledge-intensive
and combined practice that unfolds over time by way of complex processes of exploration,
negotiation, and decision-making. To monitor and control the software processes, planning is
significant. The estimation of work effort is a core task in this regard as it is used for purposes
such as budgeting, trade-off and risk analysis, project planning and control, and software
improvement investments analysis.
Software effort estimation, however, is a huge challenge, particularly as it is an area in which
miscalculations can result in delays, low quality software, or the loss of contracts. A review of
studies of software development projects shows that 70 to 80% of such projects overrun their
estimates and spend on average 30 to 40% more effort than estimated. Today, as in the early
days of computer programming, software projects whose plans and budgets are based on effort
estimates that are too low experience severe management and delivery problems. Thus, more
knowledge about the estimation practice of software professionals and the challenges faced in
such work is important for project management.

Most of estimation has been concerned with developing different kinds of formal estimation
models. However, judgment-based estimation is the most frequently applied estimation
approach in the software industry today. The work a team of software professionals does when
estimating the effort of a software project using a judgment-based approach. An effort estimate
is here understood as the most likely number of work hours necessary to complete a software
development project as assessed by the managers and developers responsible for delivery. In
this approach, the quantification step (i.e., “the step where an understanding of the software
development estimation problem is translated into a quantitative measure of the required effort”)
is based on a judgmental process as opposed to an algorithmic calculation. How this judgmental
process comes about and how it is collaboratively achieved has, however, proved difficult to
reveal. The aims to contribute to filling this gap by examining the work conducted to arrive at
an effort estimate as a social and communicative practice. To disclose the details of this Software
Effort Estimation as Collective Accomplishment practice we focus on the social interactions
through which the estimation tasks are collectively explored, negotiated, and accomplished.
A requirement specification describing the details of the project to be developed forms a point
of departure for the estimation process. Usually, this document outlines what the software
system should do in detail, including the services and functions the system should provide
and the constraints under which the system must operate. Here the constitutive elements of
the interactional process as the team’s way of approaching the information provided in the
requirement specification and the way of using this as a basis for collective exploration and
negotiation. We commence, however, by positioning our analysis within related strands of
research.

5.3 COCOMO Model

The model of COCOMO-I is also called COCOMO’81 is presented. The underlying software
lifecycle is a waterfall lifecycle. Detailed information about the ratings as well as the cost drivers
can be found in Boehm proposed three levels of the model: basic, intermediate, detailed.
• The basic COCOMO’81 model is a single-valued, static model that computes software
development effort (and cost) as a function of program size expressed in estimated thousand
delivered source instructions (KDSI).

• The intermediate COCOMO’81 model computes software development effort as a function
of program size and a set of fifteen “cost drivers” that include subjective assessments of
product, hardware, personnel, and project attributes.

LOVELY PROFESSIONAL UNIVERSITY 99