Secrets of successful design of IP (information system) on the example of the construction of the hospital
Why precisely hospital?
Why not? This is a good example. A project is a project everywhere: plus or minus are the same stages, the same control scheme, workflow, risk management, quality control, and so on. Everywhere there are requirements and to equipment, and to premises, and to software. You may ask, what are the requirements for premises in the Information System? Very simple: the location of the workplace operators, the server - and both will need air conditioning. Now and the requirements for the premises. And hardly anyone today doubts whether the hospital needs software. If you want to keep up with the times, you will be faced with the task of creating an automated medical institution with electronic medical records, where doctors do an examination with tablets, and for example, nurses celebrate a washed toilet not on a leaf, but on the phone. Requirements for software in this case will be enough. And as soon as software is required, There will be a need to install the server, somewhere to put the admin and operators. Everything is interconnected.
We chose a construction project because it is easiest to demonstrate how to design an IC. The information system is hidden somewhere inside, we do not see it, and the walls are here before us: curves and oblique, with dead-end corridors, because the project was made on the knee, and the customer also changed his requirements a hundred times during the play.
What does the hospital have to do if we develop software?
And no, dear developers, executives, analysts, testers.
Not the software you develop ... Take Android, this is software. And if, for example, you have an accounting system before you, then you are already dealing not just with software, but with the INFORMATION SYSTEM.
The difference is obvious. If you bought a phone, everything is simple: turn it on, the green man starts up (Android), use it. And if you purchased a box with accounting software, then it is clear that now you need servers, you need to configure the network, configure workstations, train employees, integrate the system with the rest of the enterprise IC, drive the system in test mode. Yes, and accountants need to somehow persuade to move to a new software, not all of them are ready for innovations. In general, in any IT project, 10–20% is IT, and the rest is organizational and administrative measures, well, very dense, jewelry, work with personnel.
And, finally, let us recall the definition of the system from the distant 90s, which nobody canceled:
Automated system: a system consisting of personnel and a complex of automation equipment for its activity , implementing information technology for performing installed functions.That is, IP is first of all people, plus technology that helps automate their activities, and not vice versa.
GOST 34.003-90. Information technology. Set of standards for automated systems. Automated systems. Terms and Definitions.
How to design a hospital
Imagine that you are a construction organization, a customer comes to you and asks to build a hospital in a certain place. You will immediately run to lay bricks or ...? If you look at how Information Systems are often created, then it is: the performers immediately begin to “interfere with concrete and purchase double-glazed windows”. Like, will come out wrong - rebuild! We will rebuild until we achieve the desired result.
However, if you are a serious organization, then first offer the customer a construction project. Do you agree? And why is the Information System wrong? Maybe it’s not the difference between building and software development, but in the case of the same hospital, they think a lot, plan, and then build, and develop the software and then think? Is it because there is a lot of hearing about Krivoruk programmers, but nothing about the same migrant workers at a construction site? Builders work on the project, in contrast to the developers.
Consider now the design process in more detail. There are several stages in it. Why do we need to go through several stages, why not do it at once? For clarity, I will give a school example ... How many years at school have been studying multiplication? You say - one or two months, and you will be fundamentally wrong. Yes, how to multiply 5 by 6, take place in a week. Still a certain time is taught the multiplication table. And multiplication of fractions, numbers with degree, logarithms, expressions in brackets, complex numbers, raising to the power how much is studied? Almost all school years! It turns out that we study the same multiplication every year from different angles
.
So, any process and learning, and design, cyclical. First, we got general concepts about numbers, then we learned how to perform simple actions with them, then we learned about fractions and learned how to work with them, and so on.
At first we understood what problem should be solved with the help of the Information System. Then they determined the range of tasks to be solved, understood what the system should do, what actions the personnel should perform. Then they determined how the system should perform the previously defined tasks. These stages can be skipped, only you have to go back and redo everything: measure it seven times and cut it off one time much faster than vice versa, and less material will go.
We give another example. You are at the top of the mountain looking down into the strong binoculars and trying to make a detailed descent route. In the eyepieces you can see every pebble on the path, every puddle. But whether this path is and whether it leads to the top is not visible through binoculars: there is no general plan. An intelligent mountaineer will first outline the paths with the naked eye, and then they will be viewed under high magnification. As soon as you plunge into detail, you lose a general view of the project. Taking a telescope at once, you ideally describe 10 functions, while forgetting about 40 others, you don’t mention them at all.
The complexity of the phased design is that at the beginning of the process it is necessary to operate with abstract concepts. So you want to "feel" something ready, and not to talk about certain requirements, functions, tasks, processes. Drawing a user interface right away is easier, but it’s also easier to miss at least half of the requirements. If you first make a detailed list of operations that the user must perform when working with a particular screen form, the designer will only have to draw, and not fantasize, as often happens.
Now we’ll finally move on to the design stages.
1. Drafting general requirements
So, let's say you are a designer. A customer comes to you, "sent" by responsible builders. The customer, of course, asks you to develop a hospital project. You run to the drawing room and ... Well, this is already antiquity - you run ArchiCAD and draw.
But of course it's not about you. You are a professional and start asking a bunch of "stupid" questions. And the most important of them is why it is necessary to build a hospital. What is the purpose of construction. If the goal is not clear, then you will not be able to answer the question, whether it should be a large hospital or a small one, what profile than equipped. Unfortunately, customers often say a lot of interesting things, except for the main thing - what is their goal. Here it is necessary to "pull out" of it in the first place. And you should ask a question. The customer himself is not an expert, he has an idea, and in this he sees his role fulfilled. He does not understand which way to go in order to implement his idea. As a rule, the customer is waiting for the good old miracle - to come to the beach, throw a net (pay money), catch a fish, and she will fulfill his desire ... And it happens like in a joke about a rich man,
To understand the purpose of the project, it is not enough to make a couple of sentences with a standard set of phrases. The goal of the project is usually determined on the basis of opposition: the existing information model is described (for example, people are in the archive and papers are sorted out), then its shortcomings (due to lack of automation, 10 people are involved in the archive, which is clearly redundant, other departments cannot receive for weeks from the archive they need the information, etc.) and propose a solution (to implement software that will allow to carry out a number of operations in an automated mode, the operations must be listed). If a completely new type of service is introduced to the market, then it is necessary to study the existing market and “criticize” the tools available there, then propose a solution.
In addition, at this stage it is necessary to determine what legislative requirements need to be taken into account, how to legally formalize certain operations, how the new service will be monetized, how it is planned to enter the market, how to interest the external participants in the new system.
In other words, it is necessary to make a business model. On the one hand, this is not the task of developers, but, on the other hand, without a clear definition of the purpose and methods for its implementation, it is not clear what tasks the system should solve. And if the customer himself has not really formulated what he needs, he is unlikely to be satisfied with at least some result.
2. Choosing a system concept
At this stage, it is necessary to choose general technical solutions with the help of which the requirements drawn up at the previous stage can be fulfilled. Whether it is a web application or native, thick client or thin, centralized database or distributed, relational database management system or noSQL, monolith or microservices, Java or Python. Often, these issues are forgotten to be discussed on time, and then it turns out that one of the programmers chose a specific tool on their own, and in the end this solution does not allow to achieve the goal.
3. Development of technical specifications
We made general requirements for the hospital, chose a concept. “Well,” says the customer, “now everything is clear, you can draw.” Is it possible? The requirements are general, they need to be detailed. For example, at the first stage you determined that there should be a laboratory for blood analysis. But what kind of equipment will there be, how much does it consume electricity, compressed air (what if?), Do we need quartz lamps for disinfection, laboratory tables, ventilation? Without this, it will be hard to design. This is the first. And secondly, it is necessary to prescribe a plan for building a hospital, preparing it and putting it into operation.
For the Information System, the development of TZ ( Technical Task ) is the central part of the project. Technical assignment describes:
- WHAT the system should do.
- What should be the overall structure of the system.
- How to create a system.
That is, TK contains functional and non-functional requirements, as well as requirements for the stages of development, handover, documentation. Also in the TOR should be briefly described the processes that we actually automate.
When describing the functions of the system (and this is the central part of the TZ), it should be understood - we present the requirements for what the system should do, and not how. You should be more important latitude, not depth. For example, in the first stage (general requirements), we identified the need for a user login block function. The TOR indicated that the account is blocked if not used for 90 days or after 6 unsuccessful login attempts, access may be limited by the administrator for a certain period, when an attempt is made to enter a blocked user, a message should be displayed, etc. And in the technical project (let's run ahead), we will draw a mockup of the user's card with the blocking flag and the unlock date, create a login script in which the blocking check is performed, automatic unblocking after the set period, blocking in case of unsuccessful attempts to enter; we define what is performed on the client side, and what is the server.
I want to debunk several myths associated with the development of technical specifications .
Myth one: TK only contains requirements for the contractor.
No, TK is how to create a system, and in the terms of reference there are sections in which the distribution of responsibility can be described.
Myth Two: There is often a lot of "water" in the Terms of Reference .
Indeed, quite often TK contains general information about the system, but they are needed. For example, we discussed-discussed system requirements; as a result, one team realized that it was necessary to develop an application for Windows, and another for a browser. One thought that the system is called so, and the other - in a different way. It seems to be obvious things, but they should be understood equally by all team members and all involved experts.
Myth Three: Requirements for personnel, servers, communication channels, modes of work of administrators are superfluous, as they are the responsibility of the customer.
Firstly, as we have already considered, TK is written for everyone at once, and secondly, TK describes how to make the system work, and not only software was written. Otherwise there will be another box with a disk and thick instructions lying on the shelf. Thus, the organizational part of the TZ, non-functional requirements are no less important than functional requirements.
In more detail, we consider the preparation of TZ in a separate article Development of a Technical Specification according to GOST 34 is easy and simple .
4. Development of a technical project
So, move on. Here before you (we have admitted that you are a designer), the Terms of Reference for the construction of a hospital with a huge list of requirements. Sit you, look sad at 100 pages of TK, and do not know where to start. Then the picture gradually begins to clear. You think: aha, we need so many meters for the wards, so much for the kitchen, so much for the recreation area, laboratory, nursing and so on and so forth. Then a lot of sketches, sketches, variants appear, you rework, change places in places, in short, look for optimal ratios. Then go to the details - drawings, drawings, drawings: walls, doors, windows, cable channels, wiring, pipes, ventilation, floor decks, wall materials, finishing ... and so on, and so on and so forth. In general, in as much detail as possible, you outline what
When developing a technical project of an Information System, documents are needed that contain the following: detailed scenarios describing the work and interaction of the system being developed, users and related systems; detailed user interface layouts containing a description of the data type and behavior of each interface element (default value, conditions under which the field value can be changed, visibility, actions performed by the system when the element is changed, etc.); a description of the protocols for integration with related systems and equipment, report forms and a description of the algorithm for their formation, the structure of servers and databases, if there are several of them.
Usually this is more than enough to be able to give the documents to the developers and get a sane result. Detailed layouts and scripts provide enough information about the behavior of the system and the interface, as well as the data structure. Developers will be put in a rigid framework in which you can fantasize, but then it will not get out.
I hope that in the following articles we will take a closer look at how to carry out technical design qualitatively, how to develop layouts, scenarios, what documents need to be compiled.
5. Development of working documentation
The logical question is what kind of working documentation for a hospital? Really instructions for cleaning the corridor? Jokes jokes, and the fire system must be maintained? It is necessary. What about elevators? And computer networks? And the water supply? “Well, this is not related to the hospital project!” - you will say. Yes, partly it is. However, the hospital is handed over to the customer as a whole, and all systems must have the appropriate operational documentation. And so that the change was quick, successful, you make a list of requirements, against which you can put a tick, if everything is in order.
The availability of user guides and administrator for the IC is a standard; everything is clear with this. But about the process of acceptance of the system to the customer often think at the last moment. And in vain. For this, there is an excellent document “Program and Test Methods”, which is also usually related to working documents. It is a kind of checklist containing a description of verification procedures. If this document is prepared in advance (and the scenario, as a basis, can be borrowed from a technical project), then the developers will have a clear criterion for accepting their work. You do not need your own or outsourced programmers to prove their case - there is a script, it should be worked out. And there will be no problems with the customer - the imagination is already limited by the document.
And where is the place for Agile?
Some people use Agile (or other “flexible” development methods) with two hands, others are strongly opposed. The author of the article has his own opinion: Agile is very good, but to the point. And it is usually used for other purposes.
Tell me, lovers of Agile, is it possible using this technology to determine the result that you get at the end of development, the cost and timing? Not? Well, how many
Secondly, Agile is good at innovation, where it’s not clear what kind of results are needed, or the way to achieve it is not clear. It is called OCD, experimental design development. Or even R & D - research and development work. At any factory there is an experienced workshop, where with a file, reworking several times, get prototypes. Imagine that you need to re-develop the touchscreen, all gestures and behavior. Here you really should try and try, you can not describe the behavior in advance. But how often do you have tasks of this kind? It is necessary to distinguish engineering and research. Mostly we are information system design engineers.
Thirdly, in a large project there may be stages where exactly OCD is required, and then Agile will help. At the operational planning level, no one interferes with the use of sprints. On the contrary, a very convenient technology: plan for a week or two and constantly monitor the result. At the strategic level - cascade planning, at the tactical level - iterative. And no contradictions!
Unfortunately, very often, “preaching” Agile, the developers try to disguise their inability to develop a system design (or they don’t even know that this is possible). They act in the most convenient way for them: we will finish and finish for the customer’s money. As long as no one controls the costs, it is completely out of hand. But then an outsider (supervisor) may have a feeling that there is a process, but there is no end and no end, and the result is not visible. Try to look not only from your bell tower.
Where to learn more about the design of information systems?
There are many books on this subject. Thick and not. But a book is always a FOREIGN experience. And you have a different character, a great situation and project. There is such a TRIZ system - the theory of solving inventive problems. Its author, Altshuller, tries to explain the steps that need to be taken to invent something. It turns out? Not usually. The principles are stated interesting, useful, but the uniform template according to the invention does not leave. Each person thinks and creates in his own way, and it is impossible to teach this, one can only learn. Someone else's experience should be used, it is foolish not to use, but it must be experienced (reworked) by you, shifted to YOUR thinking. Copy the miracle will not succeed.
If you want to learn how to design, I suggest taking the GOST 34th series as a basis. This is a real masterpiece, the result of the work of entire research institutes. During the development of these standards, dozens (if not hundreds) of the most complex automation projects for a wide variety of systems were studied. Accumulated tremendous experience.
These standards are difficult to master, and you will not learn how to use them. Therefore, we will try to reveal their essence in subsequent articles.
Read continued: Some notes on the design of information systems .
Read other articles by the author: