Estimate size is the process of approximating the size for of the products and parts to be produced for the project. Is it important to estimate the size, especially for the software project? Does the PMBOK address this aspect?
The answer here has nuances. In general, yes, you need to have a basic sense of size - you would likely be making awful business decisions if you didn't know whether a project would need 1 developer for a month or 20 developers for a year.
However, it is not so simple as "How many lines of code do you think this would be?", because lines of code is loosely correlated, at best, with effort required and quality. For example, an elegantly refactored code base might cut down code by 10 % and improve performance or ease of future programming, but actually take MORE resources and effort to develop. Additionally, lines of code would be difficult to estimate at the outset of a project.
What you really need to know is an estimate of the level of effort required to get to the minimally viable product, and how many iterations you would need beyond that to really reach your vision for the product.
Unless one of your constraints is the size-on-disk of your source code, or the size of your source code repository, the lines of code for a project are at best a proxy metric. In addition, unless you're reusing code from another directly comparable project, an LOC estimate is likely to be pure fiction anyway.
If your real question is "How complex is this set of tasks?", measure and estimate that rather than a proxy metric like projected lines of code. Once you've decomposed all your projected tasks, the development team or a subject-matter expert should be able to provide initial estimates for those tasks that you can use in your project planning.
Yes, it's important to estimate size.
How else will you be able to determine approximate man-hours, budget/cost, duration, etc. of the project.
Unless your project has no deadline, and an unlimited budget (and no performance goals), then you need to estimate work required.
I think the answer to this question is another question: do lines of code AFFECT cost and time?
It is important to capture the inputs that move the cost and time variables. If you are painting a room, the size of the room is pretty evident that your cost and time variables will move. The color of paint is not likely to move cost and time very much with the exception of a popular color that may carry a higher price tag. How about paint quality? That could affect cost and time because of how well the paint covers and number of coats required.
The point is, there are no standard set of inputs required for the estimation process. It requires critical thought and it starts with that question above: what will affect my cost and time?
It is always important to estimate the size of the software project. It will help the organisation in many ways.
Sizing will help
PMBOK did not tell anything about project sizing. But it discuss about Earn Value Management, which more helpful tool to measure Scope, Time, Cost More info available here http://en.wikipedia.org/wiki/Earned_value_management about Earn Value Management
