And if we do not design a system for managing the production of IT products. Part 3. Infrastructure support
In the previous parts Summary:
"Part 1"
I Introduction
II Market Analysis Solutions
1. Standardization of system functions on the market
2. Disadvantages of existing systems
3. Challenges in creating a support system for the production of information systems
III Designing the basic structure of the system
1. The division of problems to be solved by type
"Part 2"
2. Requirements and tasks for them
3. Specifications and tasks for them
4. Assemblies and tasks for them
5. Analysis of the design phase
')
We will continue the destruction of the usual patterns and the construction of other new ones, which we started in the previous part.
We will touch briefly on the organization of the process from the point of view of project management. In view of the fact that we are talking about the production of more or less unique products, the essence of the “Project” has already been mentioned in previous sections.
Since most software development methodologies promote a healthy iterative approach, we will add another element that divides the project into smaller parts - iteration. In this case, we will not be sprayed on the whole process of information systems production, but organize work in iterations only for activities related directly to the implementation of requirements in code. This will slightly reduce the scalability of our system, but we at the very beginning noted that the universality of existing products reduces their technological suitability. Therefore, we will tailor the system for themselves.
In standard trackers, iterations are most often designated in tasks with the help of tags, epics, or other additional features. We will introduce an additional entity "Iteration".
A possible data model is presented in Fig.7.
Figure 7. - Model of project organization
Let's provide the opportunity to type "Specifications" in the iteration through the new element "Scope per iteration". This will solve the problem, inevitability to implement one specification in several iterations. The overwhelming majority of projects are completely imperfect, and this chance may turn out to be quite useful.
In the element “Scope for iteration” we add the sign “Implemented”, thus organizing a checklist to indicate success (well, or failure). Now, when implementing the specification in the code and after thoroughly checking it, you can “skip” it in the Scope list for iteration. And if you wish, this process can be automated at all, for example, according to the status of completed tasks. IT managers are very fond of such visual tunings in minimalist styles - only he, a list of tasks and a tick about its implementation, nothing superfluous, distracting attention.
Now let's go from the back of the Scope. There in the rear, where it is expected to receive confirmation of the planned, we will tie "Scope to iterate" to "SRS Tasks". Thus, we will be able to track all the activities performed according to the specifications, performed within the framework of the iteration. Those who carefully read the article, certainly noticed that now we have formed an excessive link: “The SRS task” is directly connected with the “Specification” and in addition, through “Scope for iteration”. In these circumstances, who really used to resolve such difficulties. For example, you can remove the link to the specification, but this will complicate the work with data. In particular, the SRS task cannot be set up without iteration. And you never know what. Or leave a redundant link, but ensure the consistency of the data in the links. To do this, too, have plenty of funds.
And as is customary in a decent society, each iteration must end with a final assembly with implemented functionality, in accordance with the obligations assumed (specifications for iteration). To do this, set in "Iteration" a link to the "Assembly".
Let's test our model with the following scenario:
On our data model, this script falls into the light.
So what do we have? We can get the Scope by iteration, as the context of the implemented functionality. View task lists by type, by artist, etc. as an execution plan. See reports on what and from this is done. And in the end get the current version of the product.
Work on the change (management) requirements can be performed outside of iterations. Although if it is important to include them in its framework, you can add another entity “Scope of requirements for iteration” and inherit it from a common ancestor, see fig. 8. Similarly, in case of urgent need, you can also include assembly work in the iteration.
Figure 8. - Scope organization model per iteration
Considering the topic of assemblies at the very beginning, we touched upon the problem of integration solutions, which imply the inclusion of several assemblies of different subsystems in the product at the same time, which form a single software package. A dilemma arises in this plane: on the one hand, several actual assemblies are involved in one project at the same time, on the other, the same assembly can get into different projects and enter different final products. Willy or not, there is a need to include another element - “Product”.
In fact, the target product should be the result of the entire process of creating an information system in a project.
For such a rotation, we now need to remove the existing link “Assemblies” with the “Project”, and establish it through the additional element “Assembling in the Product”, as shown in Fig.9.
Figure 9. - Model organization of the accounting of the target product
Since collecting the new version of the target product bit by bit, it does not always require reassembly of these particles (subsystems included in it), then for the “Assembly in the product” we indicate the version of the product itself for which the selected assembly is relevant. The decision is so-so, and of course this mechanism can be realized by painting it.
As an option in this solution, the assembly of each subsystem can be represented as a separate product and form the target product from other more elementary products.
In this publication we have more than once casually touched upon the topic of communicating participants in a project. For example, they considered commenting requirements and specifications during their discussion. In standard products, there is often a more useful function - notifications, informing participants about the set task, mentioning in comments, etc.
But here is another interesting topic that is not often found in the products offered - holding meetings and rallies within the framework of the system under consideration. It is convenient, when planning a meeting, to determine the issues discussed on the basis of the set of elements with which we operate in our system: requirements, specifications, assemblies, iterations, tasks, etc. Again, participants in discussions are always at hand, in the form of stakeholders (project stakeholders). You can even prepare in advance draft problem solving, and allow guests to familiarize themselves with the agenda the day before.
A possible data model is presented in Figure 10.
Figure 10. - Model of the organization of meetings
For example, imagine the following picture: several teams participating in a project remotely, communicate by telephone or using sound perceiving messengers and discuss the “burning” project. Everything is already sparkling and heated to the limit. Not scary yet? Then aggravate. The discussion involves analysts, testers and developers, and project managers. At first, how not to twist the theme one - who is to blame? Submitted?
Well, let's say the first question was discussed, they shouted, opened their eyes to each other, to whom they really are. It's time to move on to the second - what to do? This is where a list of questions prepared in advance can be useful, or even better - a list of draft decisions prepared for it, which all participants in the discussion see on their screens. Now imagine that right from a question, anyone can go, for example, into a requirement or a task for its implementation. See comments, reports. Poke someone with a nose in facts and figures. And just as easily and naturally go back to the question page. Conveniently?
But that is not all. After discussing the issue, you can immediately formulate decisions on it, fixing a plan for further action, which can later be transformed into tasks for the performers. And everything, all the participants quickly see it all at once and silently agree, or are loudly indignant. And the main thing is that all this is fixed in the system and it cannot be cut down with an ax. And now it is not necessary to put photos with handwritten scribbles. Such blitz rallies are very productive and effective in terms of correcting the situation for the better.
In the system according to the list of meetings of the project, you can easily refresh the memory of past battles and become proud of promptly and efficiently taken measures that removed all the obstacles encountered in the creation of a product.
"Part 1"
I Introduction
II Market Analysis Solutions
1. Standardization of system functions on the market
2. Disadvantages of existing systems
3. Challenges in creating a support system for the production of information systems
III Designing the basic structure of the system
1. The division of problems to be solved by type
"Part 2"
2. Requirements and tasks for them
3. Specifications and tasks for them
4. Assemblies and tasks for them
5. Analysis of the design phase
')
IV DESIGN OF SYSTEM INFRASTRUCTURE ELEMENTS
Among the innumerable types of magic, creation provides more freedom. Each creates its own way. Do your best and find your own form.
(Fairy Tale Tale)
We will continue the destruction of the usual patterns and the construction of other new ones, which we started in the previous part.
1. General project infrastructure
We will touch briefly on the organization of the process from the point of view of project management. In view of the fact that we are talking about the production of more or less unique products, the essence of the “Project” has already been mentioned in previous sections.
Since most software development methodologies promote a healthy iterative approach, we will add another element that divides the project into smaller parts - iteration. In this case, we will not be sprayed on the whole process of information systems production, but organize work in iterations only for activities related directly to the implementation of requirements in code. This will slightly reduce the scalability of our system, but we at the very beginning noted that the universality of existing products reduces their technological suitability. Therefore, we will tailor the system for themselves.
In standard trackers, iterations are most often designated in tasks with the help of tags, epics, or other additional features. We will introduce an additional entity "Iteration".
A possible data model is presented in Fig.7.
Figure 7. - Model of project organization
Let's provide the opportunity to type "Specifications" in the iteration through the new element "Scope per iteration". This will solve the problem, inevitability to implement one specification in several iterations. The overwhelming majority of projects are completely imperfect, and this chance may turn out to be quite useful.
In the element “Scope for iteration” we add the sign “Implemented”, thus organizing a checklist to indicate success (well, or failure). Now, when implementing the specification in the code and after thoroughly checking it, you can “skip” it in the Scope list for iteration. And if you wish, this process can be automated at all, for example, according to the status of completed tasks. IT managers are very fond of such visual tunings in minimalist styles - only he, a list of tasks and a tick about its implementation, nothing superfluous, distracting attention.
Now let's go from the back of the Scope. There in the rear, where it is expected to receive confirmation of the planned, we will tie "Scope to iterate" to "SRS Tasks". Thus, we will be able to track all the activities performed according to the specifications, performed within the framework of the iteration. Those who carefully read the article, certainly noticed that now we have formed an excessive link: “The SRS task” is directly connected with the “Specification” and in addition, through “Scope for iteration”. In these circumstances, who really used to resolve such difficulties. For example, you can remove the link to the specification, but this will complicate the work with data. In particular, the SRS task cannot be set up without iteration. And you never know what. Or leave a redundant link, but ensure the consistency of the data in the links. To do this, too, have plenty of funds.
And as is customary in a decent society, each iteration must end with a final assembly with implemented functionality, in accordance with the obligations assumed (specifications for iteration). To do this, set in "Iteration" a link to the "Assembly".
Let's test our model with the following scenario:
- For iteration, a certain number of specifications is selected, which is included in Scope;
- By Scope for each line is created SRS Task for the implementation of the specification in the code;
- Registered in the system new assembly;
- After completing all the development tasks, a build task is set;
- Scope for each line creates a SRS Task for testing;
- After installing the assembly on the stands, test tasks are performed;
- Scope for each line that has not been successfully tested, set SRS tasks to correct errors;
- Repeat with paragraph 4, until errors are detected;
- An extreme assembly is assembled in the iteration, the iteration is summarized.
On our data model, this script falls into the light.
So what do we have? We can get the Scope by iteration, as the context of the implemented functionality. View task lists by type, by artist, etc. as an execution plan. See reports on what and from this is done. And in the end get the current version of the product.
Work on the change (management) requirements can be performed outside of iterations. Although if it is important to include them in its framework, you can add another entity “Scope of requirements for iteration” and inherit it from a common ancestor, see fig. 8. Similarly, in case of urgent need, you can also include assembly work in the iteration.
Figure 8. - Scope organization model per iteration
2. Integration solutions
Considering the topic of assemblies at the very beginning, we touched upon the problem of integration solutions, which imply the inclusion of several assemblies of different subsystems in the product at the same time, which form a single software package. A dilemma arises in this plane: on the one hand, several actual assemblies are involved in one project at the same time, on the other, the same assembly can get into different projects and enter different final products. Willy or not, there is a need to include another element - “Product”.
In fact, the target product should be the result of the entire process of creating an information system in a project.
For such a rotation, we now need to remove the existing link “Assemblies” with the “Project”, and establish it through the additional element “Assembling in the Product”, as shown in Fig.9.
Figure 9. - Model organization of the accounting of the target product
Since collecting the new version of the target product bit by bit, it does not always require reassembly of these particles (subsystems included in it), then for the “Assembly in the product” we indicate the version of the product itself for which the selected assembly is relevant. The decision is so-so, and of course this mechanism can be realized by painting it.
As an option in this solution, the assembly of each subsystem can be represented as a separate product and form the target product from other more elementary products.
3. Communication support
In this publication we have more than once casually touched upon the topic of communicating participants in a project. For example, they considered commenting requirements and specifications during their discussion. In standard products, there is often a more useful function - notifications, informing participants about the set task, mentioning in comments, etc.
But here is another interesting topic that is not often found in the products offered - holding meetings and rallies within the framework of the system under consideration. It is convenient, when planning a meeting, to determine the issues discussed on the basis of the set of elements with which we operate in our system: requirements, specifications, assemblies, iterations, tasks, etc. Again, participants in discussions are always at hand, in the form of stakeholders (project stakeholders). You can even prepare in advance draft problem solving, and allow guests to familiarize themselves with the agenda the day before.
A possible data model is presented in Figure 10.
Figure 10. - Model of the organization of meetings
For example, imagine the following picture: several teams participating in a project remotely, communicate by telephone or using sound perceiving messengers and discuss the “burning” project. Everything is already sparkling and heated to the limit. Not scary yet? Then aggravate. The discussion involves analysts, testers and developers, and project managers. At first, how not to twist the theme one - who is to blame? Submitted?
Well, let's say the first question was discussed, they shouted, opened their eyes to each other, to whom they really are. It's time to move on to the second - what to do? This is where a list of questions prepared in advance can be useful, or even better - a list of draft decisions prepared for it, which all participants in the discussion see on their screens. Now imagine that right from a question, anyone can go, for example, into a requirement or a task for its implementation. See comments, reports. Poke someone with a nose in facts and figures. And just as easily and naturally go back to the question page. Conveniently?
But that is not all. After discussing the issue, you can immediately formulate decisions on it, fixing a plan for further action, which can later be transformed into tasks for the performers. And everything, all the participants quickly see it all at once and silently agree, or are loudly indignant. And the main thing is that all this is fixed in the system and it cannot be cut down with an ax. And now it is not necessary to put photos with handwritten scribbles. Such blitz rallies are very productive and effective in terms of correcting the situation for the better.
In the system according to the list of meetings of the project, you can easily refresh the memory of past battles and become proud of promptly and efficiently taken measures that removed all the obstacles encountered in the creation of a product.
Source: https://habr.com/ru/post/354518/
All Articles