Some notes on the design of information systems
My last article Secrets of successful design of IP (information system) on the example of the construction of a hospital at times caused heated discussion in the comments. Therefore, I decided to present a number of theses based on this discussion.
Very often when discussing methods for designing and implementing an information systems project, you hear criticism of these methods by developers (programmers). Sometimes, developers simply don’t see that besides writing code, a project has a serious organizational component; what to identify, formulate and harmonize requirements is the most difficult task, that educating users and rebuilding all processes is not a one-day task.
Dear programmers, in order to find out what the system should do, you need to know not C # or JAVA at all, but to own the subject area. To design a logistics system, you need to be a logistician: have experience in this field or in several related, similar areas. Therefore, there are business analysts, whose task is to determine the functional appearance of the system.
The customer, at best, will give 30-50% of the necessary information, the rest should be thought out independently. And think out extremely critical. Initially, the customer does not know what he wants! As a rule, there is a joint development of a business model, and only then a list of functions is compiled.
For this and requires knowledge of the subject area. You need to understand the customer from a half-word: he also tells the idea, and you already know why he needs it and most importantly, how it is organized, how such a business should work, and not just software.
Agile vs. discussion Design technology (cascade, waterfall, waterfall) is more like a dispute of religious fanatics! The article was not about Agile at all, but all the comments were about “flexible” ones. Guys! Well, is it really impossible to look wider and see that for both methods there is a place under the sun ?!
In my opinion, Agile’s sharp rejection is a reaction to the extremely aggressive “pushing through” of this technology. After listening to the "preachers" of flexible technologies, it seems that before the Agile world did not exist, many years of experience in software development was not, well, in general, all who worked before us are fools and terrible sinners, since Agile was not enlightened. Naive! Such a worldview is typical for adolescents, but we ...
Let us reduce the degree and try to soberly evaluate the various approaches for each project.
As one commented wrote, “Agile is not for IT, and not about IT. Agile for business and pro business . Indeed, sometimes you need to get a very fast result, to enter the market with at least something, to stake out a place and find investors. Or is the development of new technologies, the requirements for which make problematic. This is definitely an Agile niche.
On the other hand, where do you find enough customers willing to work on flexible technologies? 70-80% of orders in the market are state structures where standard project technology is used. Moreover, according to GOST 34. And for this they pay well.
In addition, these methods can be combined in one development: the core is created by design technology, and some parts by trial and error (Agile). Well, not everything is possible to think in advance. In addition, there is flexibility in the design technology: there is such a thing as trial operation, during which much can change.
I can not vouch for everyone, but it seems that programmers think “flexibly”, Agile is responsible for the structure of their thinking! After all, programming is a constant search for the best solutions. You sit down at the task, do not yet know how it should be solved. You do not predict in advance either the result or the deadline (yes, yes, you multiply the developer’s deadlines by 6-10 times, and this is the only way you get the real picture, because they forgot about testing and improvements). This is the thinking of many programmers, because they are creative individuals. So you don’t have to force creative people to engage in project boring things. For this there are analysts, project managers.
We realized that Agile is the essence of the thinking of developers. But the customer thinks differently! And the customer wants to understand what he pays for, “touch” the future result, before the development begins. But it turns out that the game is only one gate: the developers are comfortable, and the customer doesn’t sleep at night, think whether it will work or not, and if it works, then what happens when it happens and how much it will cost. But on the other hand, for a laf programmer, I calmly work, and I’ll do it, I’ll do it when I finish, then I’m done, and I’ll pay as much as I ask. Isn’t it so?
But sometimes the customer should say so: we are doing something new, therefore, we are not ready to predict the dates, the cost, or the result. Do you agree? Then do it. This is at least fair.
Software development differs from other areas in that you learn something all the time. Each project is like a new world. Each project has its own requirements. Therefore, the head must always be kept on. Do not focus on any one method, one approach. You have to improvise, almost always.
When either project technology or Agile is criticized, critics rarely know the subject of their indignation. Very few of those who really studied (including standards: GOST, ISO, IEEE) and tried to seriously apply the design technology. But critics have enough of it. Very few teams that are really successful (so that the client is satisfied!) Apply Agile, but there are enough “preachers”.
And again, do not confuse Agile and chaos. If you do not know how to design and therefore choose flexible methods, then you will have a mess.
The successful use of Agile may require even more effort than the design technology. Higher coherence of the team, the qualifications of its members, the ability to find a common language with the customer.
Read other articles by the author:
Designing is not for programmers
Very often when discussing methods for designing and implementing an information systems project, you hear criticism of these methods by developers (programmers). Sometimes, developers simply don’t see that besides writing code, a project has a serious organizational component; what to identify, formulate and harmonize requirements is the most difficult task, that educating users and rebuilding all processes is not a one-day task.
Dear programmers, in order to find out what the system should do, you need to know not C # or JAVA at all, but to own the subject area. To design a logistics system, you need to be a logistician: have experience in this field or in several related, similar areas. Therefore, there are business analysts, whose task is to determine the functional appearance of the system.
The customer, at best, will give 30-50% of the necessary information, the rest should be thought out independently. And think out extremely critical. Initially, the customer does not know what he wants! As a rule, there is a joint development of a business model, and only then a list of functions is compiled.
For this and requires knowledge of the subject area. You need to understand the customer from a half-word: he also tells the idea, and you already know why he needs it and most importantly, how it is organized, how such a business should work, and not just software.
Agile Notes
Is agile a new religion?
Agile vs. discussion Design technology (cascade, waterfall, waterfall) is more like a dispute of religious fanatics! The article was not about Agile at all, but all the comments were about “flexible” ones. Guys! Well, is it really impossible to look wider and see that for both methods there is a place under the sun ?!
In my opinion, Agile’s sharp rejection is a reaction to the extremely aggressive “pushing through” of this technology. After listening to the "preachers" of flexible technologies, it seems that before the Agile world did not exist, many years of experience in software development was not, well, in general, all who worked before us are fools and terrible sinners, since Agile was not enlightened. Naive! Such a worldview is typical for adolescents, but we ...
Let us reduce the degree and try to soberly evaluate the various approaches for each project.
Agile is not suitable everywhere, as well as design technology
As one commented wrote, “Agile is not for IT, and not about IT. Agile for business and pro business . Indeed, sometimes you need to get a very fast result, to enter the market with at least something, to stake out a place and find investors. Or is the development of new technologies, the requirements for which make problematic. This is definitely an Agile niche.
On the other hand, where do you find enough customers willing to work on flexible technologies? 70-80% of orders in the market are state structures where standard project technology is used. Moreover, according to GOST 34. And for this they pay well.
In addition, these methods can be combined in one development: the core is created by design technology, and some parts by trial and error (Agile). Well, not everything is possible to think in advance. In addition, there is flexibility in the design technology: there is such a thing as trial operation, during which much can change.
Agile is how developers think
I can not vouch for everyone, but it seems that programmers think “flexibly”, Agile is responsible for the structure of their thinking! After all, programming is a constant search for the best solutions. You sit down at the task, do not yet know how it should be solved. You do not predict in advance either the result or the deadline (yes, yes, you multiply the developer’s deadlines by 6-10 times, and this is the only way you get the real picture, because they forgot about testing and improvements). This is the thinking of many programmers, because they are creative individuals. So you don’t have to force creative people to engage in project boring things. For this there are analysts, project managers.
We realized that Agile is the essence of the thinking of developers. But the customer thinks differently! And the customer wants to understand what he pays for, “touch” the future result, before the development begins. But it turns out that the game is only one gate: the developers are comfortable, and the customer doesn’t sleep at night, think whether it will work or not, and if it works, then what happens when it happens and how much it will cost. But on the other hand, for a laf programmer, I calmly work, and I’ll do it, I’ll do it when I finish, then I’m done, and I’ll pay as much as I ask. Isn’t it so?
But sometimes the customer should say so: we are doing something new, therefore, we are not ready to predict the dates, the cost, or the result. Do you agree? Then do it. This is at least fair.
Head should always be included
Software development differs from other areas in that you learn something all the time. Each project is like a new world. Each project has its own requirements. Therefore, the head must always be kept on. Do not focus on any one method, one approach. You have to improvise, almost always.
To criticize something, you need to study it.
When either project technology or Agile is criticized, critics rarely know the subject of their indignation. Very few of those who really studied (including standards: GOST, ISO, IEEE) and tried to seriously apply the design technology. But critics have enough of it. Very few teams that are really successful (so that the client is satisfied!) Apply Agile, but there are enough “preachers”.
And again, do not confuse Agile and chaos. If you do not know how to design and therefore choose flexible methods, then you will have a mess.
The successful use of Agile may require even more effort than the design technology. Higher coherence of the team, the qualifications of its members, the ability to find a common language with the customer.
Read other articles by the author: