Sergey Povolyashko. Why does size matter? - report from SPMConf
We publish an article based on the report of Sergey Povolyashko (Kharkov, Ukraine) from the conference of project managers in the IT Software Project Managment Conference
Let's start with the analogy. You order a new furniture, you want to have some sort of bedside tables, cabinets, shelves. Certain sizes, from certain materials, in a certain period, for a certain amount. And you do not care how many people, what qualifications, what tools and what time of day it will do, right?
The result is important - the quantity, materials and dimensions of all components.
Consider the following points in my report:
- What is software size 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, because you can read about them without me, let's talk about practical application. I would like to make a report in an interactive format so that we can 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, do you think that in these similar processes is really important? The result is important for us, for a particular case it is measured in cubic meters. For example, you order the foundation for your villa. Naturally, based on your resources, you will have one of two options, but in the end, it is important for you that a certain number of cubic meters be dug. We get the first conclusion, in any work, startup, project, the result is important, therefore, the Result (the size of the result) is primary , and the 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 quite conditional and necessary for understanding.
The worse we do, the more we fix - a vivid example of this formula.
This is all a smooth prelude to talking about techniques and units in terms of size.
The first point is the most ancient and the most incorrect method - lines of code , it is clear to everyone why. Then there is also an 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, just to note that they are based on differences from the point of view of system users. At the end, I will provide a slide with links to more detailed information on the topics covered in the report.
The next item is use case points . This is also quite a sophisticated technique, but according to my feelings, it is closer to life, closer to reality. It is based on Usage diagrams . If the specification describes the description of test cases, then I transform the complexity of test cases and, by adding complexity to the correction factor (there is even a 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 may differ within the project and within the team, depending on the volume of the project to the mood of the team and the format of its work.
And actually, the last point - Specific units and methods, meaningfully reflecting the amount of work or a substantial part of it , 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.
Well, now let's select why size is important ?
Without such a “weight”, which is given by the criteria and metrics, the size itself does not matter either. Therefore, you need to understand in what cases the size is needed. Briefly can be specified 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, it means that there are situations when size is not important. So, for justice, let's mark them.
Taking into account the new knowledge, let's move on to the real-life case study that the guys in our Stratoplan did , I want to express my gratitude to them in advance that they did it. What is the case? What is work?
There is some product that has a kernel, such a nice good kernel, there are end customers for this product who want to configure it. By itself, the product includes a highly configured kernel, which you can write forms, fields, and so on.
Each customer comes in and asks that this core be configured for the specific needs of the business process. What do they understand by this? 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 get a certain product. Although it sounds complicated, it is quite simple.
As a result, this configuration unfolds on this core. I repeat that the need for such a product arises, when activity is typical and often repeated, there is a discrete element. We thought, collected data, how many man-hours does one or another tool of configured logic take and what happened?
The result is a model of size , which is sufficient for a preliminary assessment. It completely conveys the whole idea.
The first line describes which discrete elements we have: screen forms, reports, business objects, etc. This number of conventional units in the columns, "x2" and "x3", is how many times the time increases for such a discrete element and, therefore, the number of cases. Depending on the specification, data is taken and counted, making up a net size. Then there is the Calibration , where the 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 we get a calibrated size . And taking for example, 1 unit. for 2 person-hours, we get the final criterion that takes into account the features for several specifications. In real life, this model has more coefficients, but for clarity, there are enough of these models. Model Size is good when it allows you to urgently provide data on the timing for the customer, for example.
As promised, useful links that could be useful for more in-depth study of the topic:
Let's start with the analogy. You order a new furniture, you want to have some sort of bedside tables, cabinets, shelves. Certain sizes, from certain materials, in a certain period, for a certain amount. And you do not care how many people, what qualifications, what tools and what time of day it will do, right?
The result is important - the quantity, materials and dimensions of all components.
Consider the following points in my report:
- What is software size 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, because you can read about them without me, let's talk about practical application. I would like to make a report in an interactive format so that we can 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, do you think that in these similar processes is really important? The result is important for us, for a particular case it is measured in cubic meters. For example, you order the foundation for your villa. Naturally, based on your resources, you will have one of two options, but in the end, it is important for you that a certain number of cubic meters be dug. We get the first conclusion, in any work, startup, project, the result is important, therefore, the Result (the size of the result) is primary , and the 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 quite conditional and necessary for understanding.
Quantity = (performance * size) / qualitywhere the size, I emphasize again, is the conventional unit of work.
The worse we do, the more we fix - a vivid example of this formula.
This is all a smooth prelude to talking about techniques and units in terms of size.
The first point is the most ancient and the most incorrect method - lines of code , it is clear to everyone why. Then there is also an 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, just to note that they are based on differences from the point of view of system users. At the end, I will provide a slide with links to more detailed information on the topics covered in the report.
The next item is use case points . This is also quite a sophisticated technique, but according to my feelings, it is closer to life, closer to reality. It is based on Usage diagrams . If the specification describes the description of test cases, then I transform the complexity of test cases and, by adding complexity to the correction factor (there is even a 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 may differ within the project and within the team, depending on the volume of the project to the mood of the team and the format of its work.
And actually, the last point - Specific units and methods, meaningfully reflecting the amount of work or a substantial part of it , 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.
Well, now let's select why size is important ?
- Display of the actual amount of work;
- Abstraction from the level of knowledge and experience of the performers (all employees perform the task at different times);
- Use in metrics to assess performance (quality, quantity, SLA, KPI (you must take into account the size, it does not work without it));
- Setting and control of expectations for "return" (for example, everyone knows that once a week test reports are expected once a week from the testing team);
- Subsequent calculation of labor costs, timing;
- Forecasting of time, timing, quality;
- Use in Model Size (all these function points, user case points, story points, etc., and make up such size models)
Without such a “weight”, which is given by the criteria and metrics, the size itself does not matter either. Therefore, you need to understand in what cases the size is needed. Briefly can be specified 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, it means that there are situations when size is not important. So, for justice, let's mark them.
Taking into account the new knowledge, let's move on to the real-life case study that the guys in our Stratoplan did , I want to express my gratitude to them in advance that they did it. What is the case? What is work?
There is some product that has a kernel, such a nice good kernel, there are end customers for this product who want to configure it. By itself, the product includes a highly configured kernel, which you can write forms, fields, and so on.
Each customer comes in and asks that this core be configured for the specific needs of the business process. What do they understand by this? 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 get a certain product. Although it sounds complicated, it is quite simple.
As a result, this configuration unfolds on this core. I repeat that the need for such a product arises, when activity is typical and often repeated, there is a discrete element. We thought, collected data, how many man-hours does one or another tool of configured logic take and what happened?
The result is a model of size , which is sufficient for a preliminary assessment. It completely conveys the whole idea.
The first line describes which discrete elements we have: screen forms, reports, business objects, etc. This number of conventional units in the columns, "x2" and "x3", is how many times the time increases for such a discrete element and, therefore, the number of cases. Depending on the specification, data is taken and counted, making up a net size. Then there is the Calibration , where the 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 we get a calibrated size . And taking for example, 1 unit. for 2 person-hours, we get the final criterion that takes into account the features for several specifications. In real life, this model has more coefficients, but for clarity, there are enough of these models. Model Size is good when it allows you to urgently provide data on the timing for the customer, for example.
As promised, useful links that could be useful for more in-depth study of the topic:
- Selection of materials about the approaches to the assessment of labor costs 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 by FPA, UCP, COCOMO, Story Points
Source: https://habr.com/ru/post/242829/
All Articles