Software Engineering in the Medical Information Field

Software Engineering has never been a fine learning. In my opinion, any model, measurement, or calculation that strives to be accurate is futile until the core laws of human thinking are clarified. In addition, some managers constantly use some existing processes and methods to update the concept of changing the tang without changing the changes, such as the next six sigma, one lean, this has led to many processes and methods that have been proven to be a tool for technical management and even a political slogan for enterprise management. In the end, many technical experts sneer at the field of software engineering. Indeed, no two software development programs can succeed with the same methodology. However, when the interest of some technical experts shifted from the operational patterns of machines to the operational patterns of the human brain and human organizations, they were surprised to find that they were so similar: the whole world is a computer, and each of us is a computing unit. All of these uncertainties in the software engineering field have also transformed from the object they hate into an exciting challenge.

Let's get to the truth and try and find the appropriate engineering methods from the perspective of a practitioner. We believe that you can do the same thing in many ways, but there are only a few ways to make you succeed.

The recent discussions at the Medical Information Forum allow me to review the application of some engineering methods in this field. So I simply forwarded my two posts. One was about requirement development, the other was about configuration management, which was left for later use.

In my opinion, there are only two decisive factors behind so many red lines in the software engineering process system, or at least at the actual operation level, for the successful release of the final project: one is requirement management, and the other is configuration management (including change and release management ). They are the first entry and exit of the project, and the other things, whether it is the division of labor, progress, risk control, etc., can be derived from the trend.

--

For the demand personnel, the two most taboo practices are the "sound transmitter" and the "fabricated demand ". Therefore, in addition to some communication skills, it is necessary to build a bridge between users and technical personnel:

1. Understand the basic principles of the communication process and common communication traps.
2. Basic Requirement Analysis (that is, correct refining and sorting of original requirements) skills.

As for the first point, people playing games such as too many people talk should be familiar with it. The second point requires some engineering knowledge and skills.

For example, many hospital procedures have three check-up and three check-up. However, if you do not pay attention to the User Interface Designed by some new users, important information (such as the patient name, gender, and age) is often not highlighted. As a result, the doctor suggested whether the font can be larger. This is an original customer requirement. Generally, doctors do not give you much detail when they are busy, or at most tell you the name or age. (maybe because he is a gynecologist, women generally come from, you don't have to worry about gender ). As a result, the "sound transmitter" type requires the technicians to tell them their names and ages. One day it was the turn of another department to go to this system, and another requirement was raised, that is, to increase the gender. Then the developer needs to modify it, and the test and change management personnel should check and track similar problems again. Or, one of them proposed to simply increase the font of the entire interface, saving every change. It may be because this person is relatively senior in some aspects, can be more appealing, or has a certain degree of influence in his position, but there are more doctors in this hospital, some people may think that these doctors are not proficient in computer operations and have poor eyes, so they also agreed to increase the font of the entire interface. Some people even suggested that the font of the entire interface should be made configurable, which sounds good, but did not expect this to increase the complexity of testing, implementation and maintenance. Finally, when the system was upgraded, the doctor was shocked and the font of the entire interface increased. Some of the doctors who have already done so won't mention it any more. The more the changes, the less decent the information I want to see. I just need to look closely at the information on the screen. This is a typical case of "fabricated demands.

From this example, we can see that the "sound transfer tube" is relatively better. At most, it will allow similar requests to be repeatedly revised (or even have some conflicting demands, for example, if it is changed, the cost increases, and the Convergence Rate of demand changes is a little lower. The most terrible thing is "fabricated demands", and in small projects, most of them are project managers who act as demand personnel. Once they make a wrong judgment on the demand, the consequences for the project will be unimaginable.

I have seen a clinic reservation system before. Due to insufficient pre-demand, the customer is eager for a technical solution. When formulating specific technical specifications, the Project Manager can make some highlights, it is proposed that the reservation owner can directly view the usage of the resources to be reserved, so as to improve the application rate. It would be a good option to book a meeting room in an office building, but it would not work in the medical industry, which violates the basic production relationships between patients, nurses/receptionists and doctors. Fortunately, before the final solution was introduced, the idea was finally corrected through various efforts. Otherwise, even if you don't easily make the prototype of the first version and give your comments to the user, the user will not understand the medical treatment at first glance, and others will be too lazy to talk to you.

These problems in the actual project are explained by the software engineering theory, which means the lack of a grasp of the business needs.

Although there are different expressions in software engineering, several requirements are generally mentioned: user requirements, business requirements, and system requirements (including hardware requirements and software requirements ). These requirements will be used no matter whether you are a project or a product. The most important thing is the business needs. A popular saying is industry experience. Of course, industry experiences that can be called business needs are generally abstract, modeled, and shared. Therefore, such business needs become the core of all demand changes. From the perspective of the user's final business goals, business needs are a benchmark for reviewing whether each demand change is reasonable.

Therefore, the original user requirements are analyzed and evaluated based on business needs, and the original requirements are extracted and sorted into the system requirements that can be used by technicians based on business needs, this will greatly reduce the frequency and control of demand changes. Of course, not all requirement personnel are required to have such requirement analysis capabilities, but at least those in the requirement team who have such engineering knowledge and skills can produce high-quality requirements, to produce high-quality products.

--

1. Why is configuration management required?

In the medical information project, such problems may occur. Sometimes, Software defects that have just been modified, or the customer requirements that have been fulfilled recently, disappear in the latest version. Sometimes, in the face of the problems raised by several departments or even several hospitals, the demand staff and developers are busy, but some key problems are sinking into the sea, the customer has not been able to reply. Sometimes, a common problem is discovered and the system needs to be upgraded on a large scale. However, because there are too many workstations installed in each department, each department may have some special user settings or custom patches, which workstations are suitable for upgrading and how can we fix problems without affecting the stable operation of the system? Sometimes, to achieve information integration and smoother workflows, You need to modify a system that has been launched, but the programmer responsible for developing the system has left, the developer responsible for maintaining the system could not find the code at the time, or could not easily find the code of a specific version on disk backup, but could not compile it. All these problems are related to configuration management.

Many people may think that the configuration management work is poor. In the project manager's view, configuration management is nothing more than managing various documents and recording the versions to be released. In the developer's view, configuration management is nothing more than daily routine check-in and checkout, as well as regular integration and construction; In the opinion of implementers, configuration management is nothing more than recording and reporting the hardware settings and software installation of various servers and workstation. It is boring and boring.

Indeed, configuration management does not bring direct value to the project as it does in programming, however, one of its most important tasks is to visualize various invisible tasks, including programming (in terms of configuration management, we call it configuration item recognition ), this visualization is the foundation for team communication and collaboration, project quality, risks, progress and cost control, and even quantitative audit. It is the seemingly simple and repetitive work of configuration management that provides a solid guarantee for the smooth operation of the project.

2. What is configuration management?

The main task of configuration management is to record, control, and report constantly changing work products in the project-these work products may include requirements and design documents, each server and workstation, or even fine-grained to every code file and personalized setting file that records user operation preferences-the purpose is to ensure the consistency and quality integrity of the association between these work products. For the entire project cycle, configuration management is an important supporting work, and it is the only way for the project to go fine-grained management.

Traditional configuration management includes configuration item identification, change control, configuration status report, and configuration audit. In some theoretical models [ITIL], configuration management may be described separately from change management and release management. However, they are closely related: the evaluation of changes must be carried out within the status monitoring activities related to configuration management and the process control involving multi-party collaboration, changes are generally implemented through release management activities. Therefore, the scope of the discussion here is the complete configuration management including change control and release management.

Of course, in specific project practices, different medical information system providers or IT service departments in different medical institutions have slightly different definitions of configuration management work. They usually add application, maintenance, training and support of configuration management tools, software integration, build, and version release based on traditional configuration management, it even includes creating an automatic software installation package.

3. How to manage configurations

In some people's impression, implementing configuration management means that some documents must be written in the specified format, and some code must be checked in and checked out at the specified time and location (directory. In the past, developers discovered some technical issues in the Code and may immediately modify them, but now they have to go through layer-by-layer approval. In the past, when the demand personnel heard a complaint from the customer, they could directly leak the complaint to the technical personnel and order them to modify it quickly. Now, they should not only discuss it, it also requires tedious records on various documents, and even emails to those who previously thought they were not necessary to be informed. Is configuration management really a tedious and boring process, which not only increases project costs, but also delays the response time of customers, and also makes people feel that the process is too cumbersome?

In fact, one of the reasons why informatization projects are more likely to fail than traditional projects in the engineering field lies in the invisibility of many informatization work products. For example, if a mechanical part is long or several millimeters short, both engineers and managers can see it with the naked eye. However, if a foreign key constraint is omitted during database design, or another version of the compiler is accidentally used, the program compiled from the same code may be slightly different, sometimes it may be hard to perceive (unless it is a professional test engineer who has used well-designed use cases for a long period of testing ). To resolve these risks and prevent them from happening, IT engineers and managers must use some processes and methods to ensure that these components can work properly during integration and meet customer needs. Configuration management is a very basic and important process and method.

Therefore, configuration management is not a plug-in, but we gradually forget it because we use it every day. For example, the term "version" is often used in configuration management. It is an important tool to identify configuration changes. Another example is the "demand change" that we often talk about ". In fact, any change occurs on the basis of a benchmark. Without a benchmark, there is no way to talk about the change. This benchmark is the "baseline" that requires special attention in configuration management ".

Of course, the premise for implementing all configuration management methods is the high-level understanding and support. Therefore, in the information project, the project manager is responsible for communication, and has the responsibility to allow your leaders, customers, and all team members to understand the relevant configuration management concepts, policies, processes, and tools, this is a prerequisite for configuration management and other related work.

4. Who will perform configuration management?

In many theoretical models [RUP], there is a configuration administrator or configuration management engineer role. Therefore, many people will habitually think that the configuration management work in the project should be completed by this role. At the same time, the configuration management work itself does not seem as technical as the development or testing work, so this role is often played by some young engineers. In addition, development teams usually get together and better management. The implementation team often goes on business trips, installs hardware and software on the customer's site, and makes necessary custom settings, therefore, configuration management should be done in the development team to ensure that the version released to the implementation team is correct. These incorrect decisions often lead to invalid configuration management and eventually lead to project confusion.

I believe that in the development team, configuration management engineers must have the following qualities. I. programming experience, knowing how software is developed step by step, which is an unavoidable Foundation; II. The habit of reflecting on development methods and the ability of system thinking, this is the basic quality of Configuration Management. 3. Understand the use and maintenance of configuration management tools and provide support for projects. This can be achieved through learning. For Configuration Management that spans the development team and implementation team, you also need to understand how the implementation team works. Of course, the ability to systematically think about the process is always the core ability to develop and optimize configuration management policies for the team and help the team improve work efficiency, service quality, and customer satisfaction. None of these can be easily done by a new employee. However, if a senior engineer or project manager is assigned a part-time job, the cost is too high. But sometimes, especially in small teams, this cost is worthwhile.

In fact, the key to implementing configuration management among a large number of immature small teams is to instill in everyone the idea that configuration management is not a matter for the configuration administrator, the entire team is required to participate. Configuration management is not only a management method and process, but also a work habit. This kind of habit requires everyone to take into account the consistency and integrity of work products between different Members when working, consider whether your work will affect the overall quality of the final products or services delivered by the team. Therefore, developing this habit will benefit both a team and individual developers. The author believes that this is also a good starting point for building a workshop team into a formal engineering team.