Sergey Povolyashko. Why does size matter? - report with SPMConf
We publish an article based on a report by Sergey Povolyashko (Kharkov, Ukraine) from the conference of project managers at IT Software Project Managment Conference.
Let's start with an analogy. You order new furniture, you want some cupboards, cabinets, shelves. Certain sizes, from certain materials, at a specific time, for a certain amount. And you don’t care how many people, what skills, with what tools and at what time of the day they will do it, right?
The result is important - the quantity, materials and sizes of all components.
Consider in my report the following points:
- what is the size of the software and why is it important;
- methods for its determination;
- when it makes sense to define and apply it;
- size model;
- what size is useful for;
We will not talk about scientific methods, since you can read about them without me, we’ll talk about practical application. I would like to conduct a report in an interactive format, so that we assess the situation together. So, let's begin.
To answer this question, you relate it to some basic value. For example, history, customer expectations, number of employees, criticality of bugs, application development stage. We will talk about them in more detail.
Here, pay attention to these pictures, what do you think is really important in these similar processes? The result is important to us , for a specific case it is measured in cubic meters. For example, you order the foundation for your cottage. Naturally, based on your resources, you will have one of two options, but, ultimately, it is important for you to dig a certain number of cubic meters. We get the first conclusion, in any work, startup, project, the result is important, therefore, the Result (the size of the result) is primary , andthe way to achieve the result is secondary .
Let's look at similar pictures again and find a number of important criteria and on them.
Having identified the following important criteria, let's take a look at the formula. It is rather arbitrary and necessary for understanding.
The worse we do, the more we fix it - a vivid example of this formula.
This is all a smooth prelude to talking about techniques and units in terms of size.
The first item is the oldest and most incorrect method - lines of code , it is clear to everyone why. Then comes the old technique - functional points , more scientific, and to be honest, until recently, I have not met a person who would use it. I will not go into details, only note that they are based on differences from the point of view of users of the system. In the end, I will provide a slide with links to more detailed information about the topics covered in the report.
The next item isuse case points . This is also a rather sophisticated technique, but, according to my feelings, it is closer to life, closer to reality. It is based on Usage diagrams . If a description of test cases is written in the specification, then I will transform the complexity of the test cases and, adding the complexity of the correction factor (there is even special software that allows this), you can also get case points, which also lead to man-hours. Story points are located below. Why? Because Story points can differ within the project and within the team, depending on the size of the project, to the mood of the team and the format of its work.
And actually, the last point -Specific units and techniques that meaningfully reflect the amount of work or its substantial part , about which I will have a description at the end of the presentation. Specific means that there is a certain kind of activity where there are standard typical operations that can be derived taking into account the size of the project, which I will talk about later.
Ok, now let's highlight why size is important ?
Without such a “weight” as criteria and metrics give, size itself does not matter either. Therefore, you need to understand in which cases the size is needed. You can briefly indicate on the slide.
Examples include regression testing, estimating the number of employees in a team, providing a project budget , etc. If we say that size is needed, then there are situations where size is not important. So, for justice, let's mark them.
Given the new knowledge, let's move on to the case from real life that the guys made in our Stratoplan , I want to express my gratitude to them in advance that they did it. What is the case? What is the job?
There is some product that has a kernel, such a nice nice kernel, there are end customers for this product who want to configure it. The product itself includes a highly configured kernel, on which you can write forms, fields, etc.
Each customer comes and asks that this core be configured for the specific needs of the business process. What do they mean by that? For example, additionally configure screen forms, business logic, reports, queries, etc. This core is obtained by some base, to which some configuration tools are applied and receive a certain product. Although it sounds complicated, it's pretty simple.
As a result, this configuration is deployed to this core. I repeat that the need for such a product arises when the activity is typical and often repeated, there is a discrete element. We thought, collected data, how many man-hours did this or that configured logic tool take, and what happened?
The result is a size model that is sufficient for a preliminary assessment. She completely conveys the whole idea.
The first line describes which discrete elementswe have: screen forms, reports, business objects, etc. This is the number of arbitrary units in the columns, “x2” and “x3” - this is how many times the time for such a discrete element will increase and, therefore, the number of cases. Depending on the specification, data is taken and counted, making up a net size. Then comes Calibration , where requirements are taken into account, where 1 is “good” and 3 is not. We consider whether there were past developments , then how high the level of the performer is . Then everything is multiplied and a calibrated size is obtained. And taking for example, 1 unit. in 2 person-hours, we get the final criterion, taking into account the features for several specifications. In real life, this model has more coefficients, but for clarity, these models are enough. The Size model is good when it allows you to urgently provide deadline data for the customer, for example.
As promised, useful links that could be useful for a deeper study of the topic:
Let's start with an analogy. You order new furniture, you want some cupboards, cabinets, shelves. Certain sizes, from certain materials, at a specific time, for a certain amount. And you don’t care how many people, what skills, with what tools and at what time of the day they will do it, right?
The result is important - the quantity, materials and sizes of all components.
Consider in my report the following points:
- what is the size of the software and why is it important;
- methods for its determination;
- when it makes sense to define and apply it;
- size model;
- what size is useful for;
We will not talk about scientific methods, since you can read about them without me, we’ll talk about practical application. I would like to conduct a report in an interactive format, so that we assess the situation together. So, let's begin.
To answer this question, you relate it to some basic value. For example, history, customer expectations, number of employees, criticality of bugs, application development stage. We will talk about them in more detail.
Here, pay attention to these pictures, what do you think is really important in these similar processes? The result is important to us , for a specific case it is measured in cubic meters. For example, you order the foundation for your cottage. Naturally, based on your resources, you will have one of two options, but, ultimately, it is important for you to dig a certain number of cubic meters. We get the first conclusion, in any work, startup, project, the result is important, therefore, the Result (the size of the result) is primary , andthe way to achieve the result is secondary .
Let's look at similar pictures again and find a number of important criteria and on them.
Having identified the following important criteria, let's take a look at the formula. It is rather arbitrary and necessary for understanding.
Quantity = (Productivity * Size) / Quality, where Size, I emphasize once again, a conventional unit of workload.
The worse we do, the more we fix it - a vivid example of this formula.
This is all a smooth prelude to talking about techniques and units in terms of size.
The first item is the oldest and most incorrect method - lines of code , it is clear to everyone why. Then comes the old technique - functional points , more scientific, and to be honest, until recently, I have not met a person who would use it. I will not go into details, only note that they are based on differences from the point of view of users of the system. In the end, I will provide a slide with links to more detailed information about the topics covered in the report.
The next item isuse case points . This is also a rather sophisticated technique, but, according to my feelings, it is closer to life, closer to reality. It is based on Usage diagrams . If a description of test cases is written in the specification, then I will transform the complexity of the test cases and, adding the complexity of the correction factor (there is even special software that allows this), you can also get case points, which also lead to man-hours. Story points are located below. Why? Because Story points can differ within the project and within the team, depending on the size of the project, to the mood of the team and the format of its work.
And actually, the last point -Specific units and techniques that meaningfully reflect the amount of work or its substantial part , about which I will have a description at the end of the presentation. Specific means that there is a certain kind of activity where there are standard typical operations that can be derived taking into account the size of the project, which I will talk about later.
Ok, now let's highlight why size is important ?
- Display of the real volume of work;
- Abstraction from the level of knowledge and experience of performers (all employees perform the task at different times);
- Use in metrics to evaluate performance (quality, quantity, SLA, KPI (you must take into account the size, it does not work without it));
- Setting and controlling expectations for “bestowal” (for example, everyone knows that once a week a test report is expected from the tacking team once a week);
- Subsequent calculation of labor costs, terms;
- Prediction of time, terms, quality;
- Use in the Size Model (all these function points, user case points, story points, etc., make up such size models)
Without such a “weight” as criteria and metrics give, size itself does not matter either. Therefore, you need to understand in which cases the size is needed. You can briefly indicate on the slide.
Examples include regression testing, estimating the number of employees in a team, providing a project budget , etc. If we say that size is needed, then there are situations where size is not important. So, for justice, let's mark them.
Given the new knowledge, let's move on to the case from real life that the guys made in our Stratoplan , I want to express my gratitude to them in advance that they did it. What is the case? What is the job?
There is some product that has a kernel, such a nice nice kernel, there are end customers for this product who want to configure it. The product itself includes a highly configured kernel, on which you can write forms, fields, etc.
Each customer comes and asks that this core be configured for the specific needs of the business process. What do they mean by that? For example, additionally configure screen forms, business logic, reports, queries, etc. This core is obtained by some base, to which some configuration tools are applied and receive a certain product. Although it sounds complicated, it's pretty simple.
As a result, this configuration is deployed to this core. I repeat that the need for such a product arises when the activity is typical and often repeated, there is a discrete element. We thought, collected data, how many man-hours did this or that configured logic tool take, and what happened?
The result is a size model that is sufficient for a preliminary assessment. She completely conveys the whole idea.
The first line describes which discrete elementswe have: screen forms, reports, business objects, etc. This is the number of arbitrary units in the columns, “x2” and “x3” - this is how many times the time for such a discrete element will increase and, therefore, the number of cases. Depending on the specification, data is taken and counted, making up a net size. Then comes Calibration , where requirements are taken into account, where 1 is “good” and 3 is not. We consider whether there were past developments , then how high the level of the performer is . Then everything is multiplied and a calibrated size is obtained. And taking for example, 1 unit. in 2 person-hours, we get the final criterion, taking into account the features for several specifications. In real life, this model has more coefficients, but for clarity, these models are enough. The Size model is good when it allows you to urgently provide deadline data for the customer, for example.
As promised, useful links that could be useful for a deeper study of the topic:
- A selection of materials on labor assessment approaches it-tuning.com/?p=1537
- Comparison of project cost estimation methods www.ntrlab.ru/publications/190
- International Function Point User Group - IFPUG (www.ifpug.org)
- csse.usc.edu/csse/research/COCOMOII/cocomo_main.html
- sunset.usc.edu/csse/research/COQUALMO
- Search FPA, UCP, COCOMO, Story Points