 Hi, I'm Grzegorz and in this video we will talk about project estimation, analytical versus holistic. So far we have been talking about the analytical approach. We estimate the effort time and cost of a project from the bottom up sum of the project activities that make up the WBS. So the general idea is, okay, we do a deep dive in the WBS and then we will analyze each part of the WBS, then we get the estimation of the effort, then the duration, then the cost and from the duration we build the network activities and define the critical path and get the duration of the project. From the effort we analyze the cost of each activity, sum the cost of all activities plus the secondary cost and then we get the cost of the project. But we can do it differently. We can use it a holistic approach. What is an holistic approach is the estimation that can be done globally in the top-down approach using the same type of the methodologies as for the analytical approach by analogy, by static data, by delphi, or by algorithmic tools. So we in a holistic approach we estimate by analogy, by counting product features in using an algorithmic approach such as function point analysis. There are others, but in this course we will talk about function point analysis. Function point analysis is a method of measuring the size of software projects. It is based on the end user's vision of the functions required for the application regardless of the technology, tools, or programming language used. So to use the function point we classify these views in the following features, internal logical files, external interface files, external inputs, external outputs, and external interrogations. In this view for each view is given a different weight. For the internal logical files the weight factor is 10. For the external internal interface files the weight factor is 7. For the external inputs the weight factor is 4. For the external outputs is 5. And finally for the external interrogations is 4. What means that we identify the software requirements and we categorize into the one above categories, internal logical files, external interface files, external inputs, external outputs, and external interrogations. That will give us the idea of the dimension of the project. And from this and using the weight factors we calculate the UFPs and adjusted function points. Function points must become adjusted by the complexity. And to do so we will evaluate four general system characteristics which measure the requirements that affect the application as a whole. Each general characteristic of the system is rate on a scale ranging from 0 not present to 15. Strong influence. So the function point analysis and the functional vision we must rate data communication, distribute processing, performance, heavily used configuration, transaction rate, online data collection, and user efficiency, online update, complex processing, possibility of reuse, easy of installation, easy of preparation, and multiple installations. We must rate each one from 0 not present to 15 strongly present. And then we can calculate the technical complex effect which is done by this formula and .65 plus .01 times the degree of influence which is the degree of influence, the sum of the scores of the 15 order characteristics that we analyzed before. So just to recap we rate each of these items between 0 and 15. Then we sum all the points in the degree of influence and then we calculate the technical complex effect. Using the technical complex effect and the adjusted function points we can calculate the function points. Then using these function points we have tables that we can use to calculate the size of the project in person permits or in another time measure. Several studies have shown that the analysis of function points is quite consistent with reality. You can consult the tables to make the adjustment of the function points to the size of the project in the International Function Points User Group IFPUG and in this website. Just to note that despite the all these techniques to determine the size of the project, the cost of the project, we must take into account the following. If we don't have a huge experience on the technology and in the business area of the project, our estimation can be quite uncertain. This picture shows that you have four plus or four less uncertainty against your estimations and in the beginning in the discovery and analysis of the project you are too far from the dates and the size of the project and that of course with the time during the project you will approach for more defined and more precise calculation and estimation. However, if you have a lot of data and a lot of experience in the technology and the business area, of course, this uncertainty is reduced. But just keep in mind that it is better to estimate, even if you know that you have some error associated, then do not estimate at all.