1

The article is devoted to the issues of building an information system designed to analyze investment projects that are submitted to administrative structures in order to obtain financial support. The structure of such a system is an information complex consisting of an external module and the main system. The external module is designed to prepare the initial information on the project and is located at the enterprise participating in the competition. The main system analyzes projects and is located in the administrative control body. The structure of the main system is aimed at implementing the features of the analysis of investment projects. The paper also proposes the basic principles and methodology for evaluating investment projects. To evaluate the project, many initial indicators are divided into groups that characterize certain aspects of the financial condition of the organization. Also included are additional indicators that are important for the social, cultural and other development of the territory. In this regard, the presented methodology allows, in the process of making a decision on the allocation of loans, to rank investment projects not only by financial indicators, but also take into account the priorities of the administrative organizational structure that are not directly related to the financial condition of the organization participating in the competition.

Information system

structure

methodology

investment project

administrative structure

1. Brykin I.M., Beklemishev A.V. Evaluation, selection and analysis of investment projects. - M .: LLC "International Media Group", 2011. - 47 p.

2. Bailey D.V., Sharp U.F., Alexander G.D. Investments. – M.: INFRA-M, 2012. – 1028 p.

3. Vilensky P.L., Livshits V.N., Smolyak S.A. Evaluation of the effectiveness of investment projects. Theory and practice: Proc. Benefit. – M.: Delo, 2008. – 888 p.

4. Kravchenko T.K., Presnyakov V.F. Infocommunication technologies of enterprise management - M.: State University Higher School of Economics, 2003. - 272 p.

5. Lipsits I.V., Kossov V.V. Investment analysis. Preparation and evaluation of investments in real assets. – M.: INFRA-M, 2014. – 320 p.

6. Svetlov N.M., Svetlova G.N. Information technologies for project management - M.: INFRA-M, 2012. - 144 p.

7. Shuremov E. Computer business analysis. // PC world. - 1998. - No. 1. - P. 80–83.

The effectiveness of managerial decision-making on the provision of investments in the field of small business in market conditions largely depends on the tools used to analyze the financial and economic activities of enterprises. The choice of analysis tools for administrative organizational structures is especially important, when the decision to lend to a project should be influenced not only by the financial performance of the enterprise, but also by the priorities of the administrative entity that is under the control of this organizational structure.

The problems considered in the article are related to the development of systems for analyzing the activities of an enterprise by external organizations and management and control bodies. The purpose of the systems is not only to assess the financial and economic condition of the enterprise, but also the possibilities and prospects for interaction or collaboration with it. The information base of the analysis is made up of indicators obtained in one way or another from standard accounting, statistical reporting and open sources.

Among the existing financial and analytical systems, one can single out the developments of such firms as Expert Systems, Galaktika, INEK, Alt-Invest, however, their effective use without modifications by administrative organizational structures is problematic, since these systems do not solve the problems of assessment project in relation to parameters that are priority for the administrative structure, but not of a financial nature.

Information system structure

The necessity and relevance of a qualitative analysis of the flow of investment projects and the existing differences in the interests of an ordinary investor and an investor in the form of an administrative organizational structure translate the problem of choosing an instrument into the plane of its development. At the same time, it is advisable to assign the following tasks to the developed system:

Analysis of the financial condition of the enterprise, including in dynamics;

Analysis of the financial part of the business plan of the project;

Analysis of the impact of credit on the financial condition of the enterprise;

Taking into account the city's priorities in the process of project analysis;

Comparative analysis of projects of several enterprises;

Forecast of the development of the enterprise and the return of loans.

Based on the features and nature of the tasks set, a block diagram of the analysis system has been developed, shown in the figure.

The external module of the system is an autonomous program that is designed to prepare the initial information necessary for making a decision on the allocation of a loan to finance the proposed project:

Balance sheet and additional balance sheet documents;

Financial part of the business plan of the project;

Additional information required to take into account the priorities of the administrative authority.

The module provides for both direct input of information using the keyboard, and work in the mode of importing data from other systems. At the same time, the external module checks the correctness of the information entered in order to exclude unintentional errors.

The structure of the main part of the system is aimed at implementing the features of the analysis of investment projects.

The key role is played by the “Module for setting up the working environment and expert system”. In this module, various analysis scenarios are formed, additional rules and criteria are determined that reflect the interests of the city and the administration, and critical values ​​of financial ratios are set.

"Module for calculating financial indicators" calculates financial ratios.

Structural diagram of the information system for the analysis of investment projects

"Project analysis and results visualization module" presents the results of the analysis in analytical, graphical and tabular ways.

"Report generation module" is associated with standard software and is intended for the preparation of reporting materials.

The expert system is designed to assist in the analysis of the results obtained.

Methodology for the analysis of investment projects

The methodology for analyzing investment projects consists in a comprehensive analysis of the financial condition of an enterprise, together with an assessment of the investment project itself and determining the rating of the project for further decision-making on the allocation of loans.

There are many initial indicators, which are divided into groups that characterize certain aspects of the financial condition of the organization. These groups of indicators are concentrated in separate documents, for example, an accounting report, etc.

Thus, there are L-groups of initial indicators , where and L-groups of relative indicators , where , l is the number of the group, and kl is the ordinal number of the indicator in the group.

Based on the primary indicators, Q-groups of secondary indicators are formed, where q = 1, Q, , and mq is the ordinal number of the indicator in the q-th group. We call these indicators coefficients.

On the basis of indicators and indicators of the dynamics of their change are formed in absolute and relative units of the type

where j - characterizes the number of measurements of the indicator or coefficient.

Each indicator and coefficient is fixed at a number of time points. The obtained values ​​allow us to identify the dynamics of changes in indicators and coefficients over time:

Then I = J + 1.

Conditions are set for coefficients . The correspondence of the coefficients to the conditions shows that the state of the generalized characteristics of the financial condition of the enterprise, which is determined by this coefficient, is normal.

In the process of analyzing an entrepreneurial project, at least three fundamental tasks are solved:

a) assessment of the possibility of repayment of the loan by the enterprise in question and, consequently, the decision to include it in the list of potentially suitable for lending;

b) assessment of the possibility of lending, based on the priorities of the administration;

These tasks are solved within the framework of a multilevel analysis of coefficients and indicators.

The analysis is carried out with the calculation of coefficients and evaluation of conditions. The coefficients are divided within the groups into subgroups of more and less important ones. The first level of analysis is associated with the assessment of the fulfillment of conditions for the selected subgroups of coefficients and mainly solves the problem

a) At the second and subsequent levels, other coefficients and indicators are analyzed, as well as the dynamics of their change.

The results of the analysis are drawn up in the form of separate documents, which characterize the various aspects of the enterprise and the proposed project.

At the next stage, an assessment of the project is formed according to the item

b) To take into account the interests of the administration, an additional group of indicators (fh) and conditions (χh) is introduced, where h = 1,H. These indicators can be calculated or presented by the enterprise. If an enterprise does not meet the criteria, it is excluded from the group of potentially credited ones.

a) options for determining the rating of investment projects are formed, focused on evaluation within a certain area, for example, in the field of food production, etc. The main differences between the options, or let's call them scenarios, are that:

In the groups of relative indicators and coefficients, separate elements are distinguished, which will be taken into account when determining the rating of the project in this scenario, i.e.

where ζ is the scenario number;

For selected indicators and coefficients, weights are set that characterize the impact of this indicator on the rating in this group, i.e. respectively

Also, the weights are determined for the groups of indicators and coefficients participating in the rating, i.e. , where d ζ is the number of the group, and D ζ is the total number of groups participating in the evaluation;

The weights are less than 1, the sum of the weights of each set over the entire sample is 1.

b) the version of the best enterprise for the group of evaluated projects is formed. The version of the best enterprise is a set of previously selected indicators with the best values ​​over the entire set, i.e. the values ​​of these indicators may belong to different enterprises. This version is not associated with a real object and is used for rating purposes. All further ratios for rating assessment are given only for coefficients. Similar formulas are constructed for the parameters and fh .

Thus, a set of indicators is formed , where , if the higher , the better, and otherwise. Here s is the number of the enterprise in the list, and is the value of the coefficient for the s-th enterprise.

where , if the growth of the coefficient characterizes the improvement in the financial condition of the enterprise and

e) the higher R ζ s, the higher the rating of the s-th enterprise in the ζ-th assessment scenario.

By normalizing (R ζ s) by , it is possible to arrange enterprises in ascending or descending order of their rating. Rating by indicators , and fh can be carried out separately.

Conclusion

The presented methodology allows, in the process of making a decision on the allocation of loans, to rank investment projects not only by financial indicators, but also take into account the priorities of the administrative organizational structure that are not directly related to the financial condition of the organization participating in the competition.

Thus, the information system, when implemented, will be a powerful tool that incorporates effective decision support mechanisms in the field of investment activity and is aimed at providing an analysis of both the financial condition of enterprises and investment projects submitted for the competition.

Bibliographic link

Klevtsov S.I., Klevtsova A.B. MODEL OF INFORMATION SYSTEM FOR ANALYSIS OF INVESTMENT PROJECTS FOR ADMINISTRATIVE STRUCTURES // Fundamental Research. - 2016. - No. 12-1. - P. 58-61;
URL: http://fundamental-research.ru/ru/article/view?id=41046 (date of access: 04/26/2019). We bring to your attention the journals published by the publishing house "Academy of Natural History"

Any enterprise, firm, organization has its own organizational structure. This structure is multidimensional and can be divided into several interrelated and interdependent substructures, which can be considered as independent structures, production management structure, personnel structure, marketing, financial, economic, information structures.

All of them are in close interaction and it is their combination that will create the organizational structure of the enterprise. One of the most important places in this structure is occupied by the information system. In principle, any management system can be represented as an information system with various information flows in the form of documents, orders, requests addressed within the organization, outgoing or incoming from the external environment.

In recent decades, the volume of information in society in general and information used in the enterprise in particular has increased dramatically. This is due to the growing pace of development of science and technology, the emergence of new technologies, and their rapid turnover. In the markets of raw materials and products, conditions have developed that require constant monitoring of the state of the market, its changes, and trends in its development; All this leads to the fact that in modern conditions, business leaders have to deal with so much information, it changes so quickly that it often becomes simply impossible to process manually. In addition, at large enterprises with large turnover of products and the number of employees, there is a need to take into account and control a large volume of financial, production, personnel, purchasing and marketing, marketing information. In this regard, there is a need to create automated systems for collecting, processing, storing information. They should facilitate the process of working with information circulating in the enterprise.

The advent of computer technology makes it possible to create such systems. At modern enterprises, almost all work with information is automated, there are special programs that allow you to keep accounting records, workflow, marketing research, forecasting and strategic planning, and much more on a computer. But in addition to automation, the question of competently building the structure of an information system, optimizing information flows, screening out unnecessary information, simplifying the search and obtaining the necessary information will remain relevant. The presence of a well-established automated information system in the enterprise greatly simplifies the process of enterprise management. It allows you to collect, sort, process the necessary information in time and make the right decision. Sometimes, a decision taken at the wrong time, due to a lack or untimely receipt of information, can lead to the death of the enterprise. Therefore, it is necessary to pay great attention to the creation and maintenance of the effective functioning of the enterprise information system.

The basic concepts used in the theory of information systems and automated information systems are information, system, information retrieval system, automated control system, automated workplace. Information - from lat. Informatio clarification, presentation of information originally transmitted by people orally, in writing or in any other way since the middle of the 20th century, a general scientific concept that includes the exchange of information between people, a person and an automaton, an automaton and an automaton. A group system is a set of ordered and interconnected elements in a certain way that have stable unity, internal integrity, and autonomy of existence in the external environment. The information retrieval system of the IPS is a set of tools for storing, searching and issuing the necessary information upon request, the search for placing information in the IPS is carried out manually or using a computer according to certain rules and in accordance with the accepted information language. Automated control system ACS is a set of mathematical methods, computer hardware, communications and organizational complexes that provide rational management of a complex process object in accordance with a given goal. Automated workstation AWS workplace of the operator, dispatcher, designer, technologist, equipped with computer technology to automate the process of processing and displaying the information necessary to complete the production task. Recently, the role of information used in enterprises, in various organizations has increased. We can say that it is one of the resources used in the activities of the enterprise. However, information resources differ in their properties from resources in the traditional concept of material, energy, technological.

Various researchers have proposed different ways of classifying information support. So, from the point of view of the interaction of the organization's enterprise with the environment, it is customary to divide all information, mainly documentary, into incoming and outgoing. Depending on the storage period, a distinction is made between a constant, a conditionally constant, sometimes updated, and a variable that changes regularly. The information is also divided according to the levels of management of the factory, intra-factory, workshop, intra-shop. By the nature of the activity, design and technological. accounting, accounting and reporting, planning, marketing, personnel, production. In automated systems, information support is divided into machine-based in computer memory and off-machine. These classifications in various combinations are used when indexing various documents of letters, orders, instructions and other documents used by enterprises and organizations in their practical activities. History of development. In the history of the creation of automated information systems, two directions developed relatively independently: 1. development of automated information systems AIS as automated control systems for automated control systems 2. development of automated systems of scientific and technical information ASNTI. Work on their creation began almost simultaneously in the 60s.

The first direction - the development of AIS and ACS - was initiated by scientific and technological progress and the problems of organizational management that arose in connection with this, an increase in the amount of information, difficulties with its manual processing. Foreign practice followed the path of developing separate software procedures, for example, for accounting, accounting for material assets, and the main work was carried out in the direction of researching and improving the capabilities of computer technology, developing tools that provide the most rational organization of information arrays, a user-friendly interface, and increasing computer memory . In our country, the problem of providing managerial employees with information was immediately posed systematically. A classification of automated control systems was developed, in which, first of all, automated control systems of different levels of the control system were distinguished - for the level of enterprises and organizations, sectoral, republican and regional, and a nationwide automated system.

Similarly, at the level of enterprises, and especially those created in the 70s. of research and production associations of NPOs, in the structure of automated control systems or integrated automated control systems of associations, stratum levels were distinguished - automated control systems of an association, automated control systems of enterprises and organizations of research institutes, design bureaus included in NPOs, automated control systems of production, workshop complexes, automated control systems of workshops and sites. At the level of workshops and sections, automated control systems were first divided into automated control systems for technological processes, automated control systems for technical and technological preparation of production, and automated control systems for organizing production. Work on the creation of centralized nationwide ACS and ASNTI was suspended due to the transformations of 19-91. However, in the transition to a market economy, to a rule of law, the role of another important type of information increases - legal and regulatory, methodological, regulating the activities of enterprises while providing them with greater independence and reducing the organizational and administrative documentation of current orders and orders, auditing command and administrative management methods. In the future, as enterprises and their automated control systems developed, especially in the context of granting greater independence to industries and workshops and the redistribution of management functions between the enterprise administration and production and workshop managers, it also became more convenient to represent the structure of automated control systems in the form of a multi-level, stratified one. The division of the automated control system into functional and supporting parts, and the latter - into information support, technical, organizational, software and other types of support - made it possible to involve specialists in these areas to clarify the corresponding types of support. This approach to organizing the development of automated control systems helped to cope with the complexity of the system and accelerate the development of automated control systems through parallel work on the analysis and selection of the structure of certain types of support. However, if separate projects are developed, then after development there is a rather difficult task of their coordination, interconnection of the accepted structures of these types of support, the criteria taken into account in their development, etc. Therefore, at a certain stage in the development of work on the creation of automated control systems, a special principle of the unity of information support, hardware and software, as the main types of support, was even formulated. Currently, there are a huge number of ready-made software products. Therefore, when creating an automated system at an enterprise, there is no need to engage in independent software development. Evaluation of the effectiveness of information resources. With a variety of types and forms of information resources, the problem of their evaluation seems almost insoluble.

Indeed, how to compare different types of information What information should be provided to managers, managers, scientists, designers, technologists and other employees of the enterprise How to determine which information storage and retrieval is more important to automate in the first place How to determine the efficiency of using information resources in general.

The increase in production volumes, the frequency of updating the range of products and technologies, the complexity of managing rapidly developing regions, production systems, and the non-industrial sector have led to an increase and complexity of information flows. Under these conditions, it became necessary to evaluate the costs of information resources, to determine their contribution to the efficiency of the functioning of production, educational and other systems.

Various information sciences have attempted to measure it. To assess the satisfaction of information needs in the theory of scientific and technical information, measures of relevance and pertinence are introduced. Relevance refers to the compliance of the output with the request; under pertinence - the correspondence of the output to the needs of the user. In practice, when assessing the significance of information arrays of automated control systems, sometimes indirect estimates are used, such as the frequency of accessing the array, the number of documents prepared on its basis, the number of departments serviced, the volume of arrays, etc. indirect quantitative characteristics. For solving particular problems, the considered methods of evaluating information sometimes give quite satisfactory results. However, in the case of evaluating the entire set of information resources, it is desirable to be able to compare different types of information, to obtain, if not a single measure, then at least comparable estimates of the usefulness of various information resources for a production or other system in order to allocate funds for information support more rationally. It is practically unrealistic to apply the traditional cost measure to assess the effectiveness of information resources. It is possible, of course, to evaluate the economic efficiency and payback period of automation of storage and retrieval of certain types of information support. However, on the basis of these estimates, one cannot judge the significance of information for improving production or organizational management systems, the usefulness of information for scientific research, and design solutions. Based on the basic idea of ​​using system representations in organizing complex examinations, one can set the task of evaluating the effectiveness of information resources, as the task of assessing the degree of their influence on the implementation of system circuits.

With such a statement of the problem, it is necessary to solve two problems: 1 to form the structure of the goals of the main directions of development of the system that determine its activity in the corresponding period of existence, 2 to choose an approach to assessing the degree of influence of information on the achievement of goals. To ensure the completeness of the analysis of the activities of the organization's enterprise, when forming the structure of goals, it is necessary to apply methods for structuring goals and functions, the choice of which is determined by the previously developed concept of its development. To assess the degree of goal compliance, a probabilistic measure can be used, i.e., to estimate the probability that a given information resource will be used to achieve a subgoal. Such estimates can be obtained as estimates of the relative importance, the relative contribution of the information resource to the implementation of the corresponding subgoal, but this raises the problem that the same information can affect more than one subgoal. It is possible to use an information measure of the degree of influence of the resource on the implementation of subgoals, which allows taking into account not only the probability of achieving the subgoal p, but also the probability q that this information will be used by the decision maker in the implementation of the subgoal. The assessment of the information potential H is more convenient than assessments of relative importance; they can be summed up, one can take into account not only p but also q, the concept of information potential is better perceived by managerial employees. In real conditions, more complex methods can be used.

Why not? This is a good example. A project is a project everywhere: plus or minus the same stages, the same management scheme, document flow, risk management, quality control, and so on. Everywhere there are requirements for equipment, and for premises, and for software. You ask, what can be the requirements for the premises in the Information System? Very simple: the location of the workplaces of operators, servers - both of them will need air conditioning. Here are the requirements for the premises. And hardly anyone now doubts whether the hospital needs software. If you want to keep up with the times, you will face the task of creating an automated medical institution with electronic medical records, where doctors do examinations with tablets, and, for example, nurses mark the washed toilet not on a leaf, but on the phone. There will be plenty of software requirements in this case. And as soon as the software is needed, it will be necessary to install servers, put the administrator and operators somewhere. Everything is interconnected.

We chose the construction project because it is the easiest way to demonstrate how to design an IC. The information system is hidden somewhere inside, we don’t see it, but the walls are here in front of us: crooked and oblique, with dead-end corridors, because the project was done on the knee, and even the customer changed his requirements a hundred times in the course of the play.

Program code inside (but no one sees this)

What does the hospital have to do with it if we develop software?

But no, dear developers, managers, analysts, testers.

You don't develop software... Let's take Android, it's software. And if, for example, you have an accounting system in front of you, then you are already dealing not just with software, but with an INFORMATION SYSTEM.

The difference is obvious. If you bought a phone, everything is simple: turn it on, the green man (Android) starts up, use it. And if you have purchased a box with accounting software, then it is clear that servers are now needed, you need to set up a network, configure workstations, train employees, integrate the system with the rest of the enterprise's IS, and drive the system in test mode. Yes, and accountants still need to somehow be persuaded to switch to new software, not all of them are ready for innovations. In general, in any IT project, 10-20% is IT, and everything else is organizational and administrative measures, and very tight, jewelry work with personnel.

Information system (is it only software?)

And, finally, let's recall the definition of the system from the distant 90s, which no one has canceled:

Automated system: a system consisting from the staff And a set of means for automating its activities, which implements information technology for the performance of established functions.

GOST 34.003-90. Information technology. Set of standards for automated systems. Automated systems. Terms and Definitions.

That is, IP in the first place is people, plus technology that helps automate their activities, and not vice versa.

How to design a hospital

Imagine that you are a construction organization, a customer comes to you and asks to build a hospital in such and such a place. Will you immediately run to lay bricks or ...? If you look at how Information Systems are often created, then it is true: the performers immediately begin to "interfere with concrete and buy double-glazed windows." Like, it won’t work out that way - we’ll 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? Why not with the Information System? Maybe it's not about the differences between construction and software development, but that in the case of the same hospital, first they think a lot, plan, and then build, while software is first developed and then they think? Isn't that why you hear a lot about crooked programmers, but nothing about the same guest workers at a construction site? Builders work on a project, unlike developers.

Without a project, it's always like this, even if you can't see it

Let us now consider the design process in more detail. It has several stages. Why do you need to go through several stages, why not do it at once? For clarity, I will give a school example ... How many years have they been studying the operation of multiplication at school? You will say - one or two months, and you will be fundamentally wrong. Yes, how to multiply 5 by 6, pass in a week. For a certain time, they learn the multiplication table. And how much do they study the multiplication of fractions, numbers with a degree, logarithms, expressions in brackets, complex numbers, raising to a power? Almost all school years! It turns out that we study the same multiplication every year from different angles.
ami.

Why isn't this taught in first grade?

So, any process of both learning and designing is cyclical. First we got general concepts about numbers, then we learned how to perform simple operations with them, then we learned about fractions and learned how to work with them, and so on.

First, we understood what problem we should solve with the help of the Information System. Then we determined the range of tasks to be solved, understood WHAT the system should do, what actions the personnel should perform. Then we determined HOW the system should perform the previously defined tasks. You can skip these stages, you just have to go back and redo everything: measuring seven times and cutting once is much faster than vice versa, and it will take less material.

Let's take another example. You are on top of a mountain looking down through powerful binoculars and trying to map out a detailed route of descent. Through the eyepieces, you can see every pebble on the path, every puddle. But whether this path is right and whether it leads to the top is not visible through binoculars: there is no general plan. A sensible climber will first outline the descent paths with the naked eye, and then examine them under strong magnification. As soon as you plunge into detail, you lose the overall view of the project. Taking a telescope right away, you will ideally describe 10 functions, while forgetting about 40 others, not mentioning them at all.

It is visible well, but only a small part

The complexity of phased design is that at the beginning of the process you have to operate with abstract concepts. So you want to “feel” something ready, and not 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, then the designer will only have to draw, and not fantasize, as is often the case.

Now let's finally move on to the design stages.

1. Drawing up 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 board and... Well, it's already ancient - start 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 - why you need to build a hospital. What is the purpose of the building. If the goal is not clear, then you will not be able to answer the question, should it be a large hospital or a small one, what profile, what is equipped. Unfortunately, customers often say a lot of interesting things, except for the main thing - what is their goal. This is what needs to be “pulled out” of it in the first place. And you should ask the question. The customer himself is not a specialist, he has an idea, and on this he sees his role fulfilled. He does not understand what path must be taken to implement his idea. As a rule, the customer is waiting for a good old miracle - to come to the seashore, cast a net (pay money), catch a fish, and it will fulfill his desire ... And it happens like in a joke about a rich man who, having caught a goldfish, asked to fulfill one wish: “ I want to have everything!” - “No problem,” the fish replied, “you had everything ...”

To understand the purpose of the project, it is not enough to make a couple of sentences with a standard set of phrases. The purpose of the project is usually determined on the basis of opposition: they describe the existing information model (for example, people sit in the archive and sort through papers), then its shortcomings (due to the lack of automation, 10 people are involved in the archive, which is clearly redundant, other departments cannot get it for weeks from the archive the information they need, etc.) and offer a solution (introduce software that will allow a number of operations to be carried out in an automated mode, the operations must be listed). If a completely new type of service is introduced to the market, then it is required to study the existing market and “criticize” the tools available there, then offer a solution.

In addition, at this stage, it is necessary to determine what legal 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 external participants in the new system.

In other words, you need to create a business model. On the one hand, this is, as it were, not the task of the developers, but, on the other hand, without a clear definition of the goal and methods for its implementation, it is not clear what tasks the system should solve. And if the customer himself has not yet clearly formulated what he needs, he is unlikely to be satisfied with at least some result.

2. Choice of system concept

At this stage, it is necessary to select general technical solutions with which the requirements drawn up in the previous stage can be met. Will it be a web application or native, thick client or thin, centralized database or distributed, relational DBMS or noSQL, monolith or microservices, Java or Python. Often these issues are forgotten to be discussed in time, and then it turns out that one of the programmers independently chose a certain tool, and in the end this decision does not allow achieving the goal.

3. Development of Terms of Reference

We made general requirements for the hospital, chose the concept. “Well,” the customer will say, “now everything is clear, you can draw.” Is it possible? The requirements are general, they need to be detailed. For example, in the first step, you determined that there should be a blood laboratory. But what kind of equipment will be there, how much electricity, compressed air does it consume (what if?), do you need quartz lamps for disinfection, laboratory tables, ventilation? Without this, it will be difficult to design. This is first. And secondly, it is necessary to prescribe a plan for the construction of a hospital, its preparation and commissioning.

For the Information System, the development of TK () is the central part of the project. describes:

1. WHAT the system should do.
2. What should be the overall structure of the system.
3. How to create a system.

That is, the TOR contains functional and non-functional requirements, as well as requirements for the stages of development, acceptance, documentation. Also, the TOR should briefly describe the processes that we actually automate.

When describing the functions of the system (and this is the central part of the TOR), it should be understood that we provide requirements for WHAT the system should do, and not HOW. Breadth should be more important to you than depth. For example, in the first stage (compilation of general requirements), we identified the need for a function to block user login. The TOR indicated that the account is blocked when not used for 90 days or after 6 unsuccessful login attempts, access can be limited by the administrator for a certain period, when a blocked user tries to log in, a message must be displayed, etc. And in the technical project (running ahead), we will draw a user card layout with a lock flag and an unlock date, create a login script that checks for a lock, automatically unlocks after a set period, and locks in case of unsuccessful login attempts; Let's define what is done on the client side and what is on the server side.

I would like to debunk a few myths related to .

Myth one: The TOR contains requirements only for the contractor.

No, TOR is how to create a system, and there are sections in the terms of reference in which you can describe the distribution of responsibility.

4. Development of a technical project

So let's move on. Here in front of you (we assumed that you are a designer) Terms of Reference for the construction of a hospital with a huge list of requirements. You sit, look sadly at 100 pages of TK, and don't know where to start. Then the picture gradually begins to clear up. You think: yeah, we need so many meters for the wards, so much for the kitchen, so much for the recreation area, laboratory, nursing rooms, and so on and so forth. Then a lot of sketches, sketches, options come to light, you redo it, change places in places, in short, you look for optimal ratios. Then go to the details - drawings, drawings, drawings: walls, doors, windows, cable channels, wiring, pipes, ventilation, interfloor ceilings, wall materials, finishes ... and so on, and so on, and so on. In general, in as much detail as possible, outline how the hospital should look and function after construction is completed.

When developing a technical project of an Information System, documents are required that contain the following: detailed scenarios that describe the operation and interaction of the developed system, 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 changes, etc.); description of protocols for integration with related systems and equipment, report forms and description of their generation algorithm, structure of servers and databases, if there are several of them.

Usually this is more than enough to be able to give documents to developers and get a sane result. Detailed layouts and scripts provide enough information about system and interface behavior as well as data structure. Developers will be placed in a rigid framework in which you can fantasize, but then you will not get out.

I hope that in the following articles we will take a closer look at how to carry out high-quality technical design, how to develop layouts, scenarios, what documents need to be drawn up.

5. Development of working documentation

A logical question is what kind of working documentation for a hospital? Really instructions for cleaning the corridor ?! Joking aside, does the fire system need to be serviced? Necessary. And the elevators? What about computer networks? And the plumbing? “Well, this is not related to the hospital project!” - you say. Yes, this is partly true. However, the hospital is leased to the customer as a whole, and all systems must have the appropriate operational documentation. And in order for the delivery to be quick, successful, you will make a list of requirements that you can check in front of if everything is in order.

The presence of user and administrator manuals for IS is a standard, everything is clear with this. But the process of delivery and acceptance of the system to the customer is often thought at the last moment. And in vain. To do this, there is an excellent document "Program and Test Methods", also usually related to working documents. It is a kind of checklist containing a description of the verification procedures. If this document is drawn up in advance (and the script can be borrowed from the technical project as a basis), then the developers will have a clear criterion for accepting their work. You don't need your own or outsourced programmers to prove you're right - there is a script, it must be worked out. And there will be no problems with the customer - the fantasy is already limited by the document.

Where is the place for Agile here?

Some people are all for Agile (or other "agile" development methods), while others are strongly against it. The author of the article has his own opinion: Agile is very good, but out of place. And they usually use it for other purposes.

Tell me, Agile lovers, is it possible, using this technology, to determine the result that you will get at the end of development, the cost and timing? No? Well, how many fools of customers will you find who will get involved in work with an unclear result, budget and duration? Would you order an apartment renovation to an Agile team? Thus, Agile has a place to be, but for internal projects. You can do repairs yourself as much as you like and review everything several times. For external customers, this is a scam called by a smart term (of course, you will not agree with this wording, but try to convince the client of the same).

The customer thinks: and how much more will they lead me in a circle by the nose?

Secondly, Agile is good at innovation, where it is not clear what result is required to be obtained, or the way to achieve it is not clear. This is called R & D, developmental development. Or even R&D - research and development work. At any plant there is an experimental workshop, where with a file, reworking several times, prototypes are obtained. Imagine that you need to re-design the touchscreen, all gestures and behavior. Here you really should try and try, you can’t describe the behavior in advance. But how often do you face tasks of this kind? It is necessary to distinguish between engineering development and research. Basically, we are information systems engineers.

Thirdly, in a large project there may be stages where OCD is required, and then Agile will help. Nobody interferes with the use of sprints at the level of operational planning. 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 - iterative. And no contradictions!

Unfortunately, very often, by "preaching" Agile, developers try to disguise their inability to develop a system design (or do not 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, you can get away with it. But then an outside observer (bosses) may get the feeling that the process is there, but the end and the edge, and the result is not visible. Try to look not only from your bell tower.

Where can I learn more about information systems design?

There are many books on this subject. Thick and not so thick. But the book is always someone else's experience. And you have a different character, a great situation and project. There is such a TRIZ system - the theory of inventive problem solving. Its author, Altshuller, tries to explain the steps to take to invent something. It turns out? As a rule, no. The principles are stated interesting, useful, but a single template according to the invention does not come out. Each person thinks and creates in his own way, and it is impossible to teach this, you can only learn. It is necessary to use someone else's experience, it is foolish not to use it, but it must be experienced (processed) by you, transferred to YOUR thinking. You can't copy a miracle.

Tags: Add tags

Information systems design

Part 1. Stages of project development: strategy and analysis

Introduction "Waterfall" - project development scheme Strategy Analysis ER diagrams arcs Normalization Data flow diagrams Some principles for checking the quality and completeness of the information model Entity quality Attribute Quality Connection quality System functions Strategy Refinement

Introduction

The design of information systems always begins with the definition of the purpose of the project. The main task of any successful project is to ensure that at the time of system launch and during the entire period of its operation it is possible to provide:

the required functionality of the system and the degree of adaptation to the changing conditions of its functioning;

required system throughput;

the required response time of the system to a request;

trouble-free operation of the system in the required mode, in other words, the readiness and availability of the system to process user requests;

ease of operation and support of the system;

the necessary security.

Performance is the main factor that determines the efficiency of a system. Good design is the foundation of a high performance system.

Information systems design covers three main areas:

designing data objects to be implemented in the database;

designing programs, screen forms, reports that will ensure the execution of data queries;

taking into account a specific environment or technology, namely: network topology, hardware configuration, architecture used (file-server or client-server), parallel processing, distributed data processing, etc.

In real conditions, design is a search for a way that satisfies the requirements of the functionality of the system by means of available technologies, taking into account the given restrictions.

Any project is subject to a number of absolute requirements, for example, the maximum project development time, the maximum financial investment in the project, etc. One of the difficulties of design is that it is not as structured as the analysis of project requirements or the implementation of a particular design solution.

It is believed that a complex system cannot be described in principle. This, in particular, concerns enterprise management systems. One of the main arguments is a change in the conditions for the functioning of the system, for example, a directive change in certain flows of information by the new leadership. Another argument is the scope of the terms of reference, which for a large project can be hundreds of pages, while the technical project may contain errors. The question arises: maybe it’s better not to conduct surveys at all and not to make any technical project, but to write the system “from scratch” in the hope that there will be some miraculous coincidence of the customer’s desire with what the programmers wrote, and also that that all this will work stably?

If you look at it, is the development of the system really so unpredictable and is it really impossible to get information about it? It is likely that an idea of ​​the system as a whole and of the ways (management) envisaged for its development can be obtained through seminars. After that, break the complex system into simpler components, simplify the connections between the components, provide for the independence of the components and describe the interfaces between them (so that a change in one component does not automatically entail a significant change in another component), as well as the possibility of expanding the system and "stubs" for unrealizable in one or another version of the system of functions. Based on such elementary considerations, the description of what is supposed to be implemented in the information system no longer seems so unrealistic. You can follow the classical approaches to the development of information systems, one of which is the "waterfall" scheme ( rice. 1) is described below. Some other approaches to the development of information systems will also be briefly considered, where the use of the elements described in the "waterfall" scheme is also acceptable. Which approach from those described below to follow (and whether it makes sense to come up with your own approach) is to some extent a matter of taste and circumstances.

Rice. 1. Waterfall scheme

The software life cycle is a model for its creation and use. The model reflects its various states, starting from the moment the need for this software arises and ending with the moment it is completely out of use for all users. The following life cycle models are known:

cascade model. The transition to the next stage means the complete completion of the work at the previous stage.

Staged model with intermediate control. Software development is carried out in iterations with feedback loops between stages. Inter-stage adjustments can reduce the complexity of the development process compared to the waterfall model; the lifetime of each of the stages is stretched for the entire development period.

spiral model. Particular attention is paid to the initial stages of development - strategy development, analysis and design, where the feasibility of certain technical solutions is checked and justified through the creation of prototypes (prototyping). Each turn of the spiral involves the creation of a certain version of the product or any of its components, while the characteristics and goals of the project are specified, its quality is determined, and the work of the next turn of the spiral is planned.

Below we will consider some of the project development schemes.

To the begining

"Waterfall" - project development scheme

Very often, design is described as a separate stage of project development between analysis and development. However, in reality, there is no clear division of the project development stages - design, as a rule, does not have a clearly defined beginning and end, and often continues at the testing and implementation stages. Speaking about the testing stage, it should also be noted that both the analysis stage and the design stage contain elements of the work of testers, for example, to obtain an experimental justification for choosing a particular solution, as well as to evaluate the quality criteria of the resulting system. At the stage of operation, it is appropriate to talk about the maintenance of the system.

Below we will consider each of the stages, dwelling in more detail on the design stage.

To the begining

Strategy

Defining a strategy involves examining the system. The main task of the survey is to assess the real scope of the project, its goals and objectives, as well as to obtain definitions of entities and functions at a high level.

At this stage, highly qualified business analysts are involved, who have constant access to the management of the company; the stage involves close interaction with the main users of the system and business experts. The main task of interaction is to obtain as complete information about the system as possible (a complete and unambiguous understanding of customer requirements) and transfer this information in a formalized form to system analysts for the subsequent analysis stage. As a rule, information about the system can be obtained as a result of conversations or seminars with management, experts and users. Thus, the essence of this business, the prospects for its development and the requirements for the system are determined.

At the completion of the main phase of the system survey, technicians form likely technical approaches and estimate the costs of hardware, purchased software, and development of new software (which, in fact, is assumed by the project).

The result of the strategy definition stage is a document that clearly states what the customer will receive if he agrees to finance the project; when he receives the finished product (work schedule); how much it will cost (for large projects, a schedule of financing at different stages of work should be drawn up). The document should reflect not only the costs, but also the benefits, for example, the payback time of the project, the expected economic effect (if it can be estimated).

The document must describe:

restrictions, risks, critical factors affecting the success of the project, for example, the response time of the system to a request is a given limitation, and not a desirable factor;

a set of conditions under which it is supposed to operate the future system: system architecture, hardware and software resources provided to the system, external conditions for its functioning, composition of people and work that ensure the smooth functioning of the system;

deadlines for completion of individual stages, the form of delivery of work, resources involved in the process of developing the project, measures to protect information;

description of the functions performed by the system;

future requirements for the system in the event of its development, for example, the ability of the user to work with the system using the Internet, etc.;

entities necessary to perform system functions;

interfaces and distribution of functions between a person and a system;

requirements for software and information components of software, requirements for DBMS (if the project is supposed to be implemented for several DBMS, then the requirements for each of them, or general requirements for an abstract DBMS and a list of DBMS recommended for this project that satisfy the specified conditions);

that will not be implemented within the framework of the project.

The work performed at this stage allows us to answer the question of whether it is worth continuing this project and what customer requirements can be met under certain conditions. It may turn out that the project does not make sense to continue, for example, because certain requirements cannot be satisfied for some objective reasons. If a decision is made to proceed with the project, then an idea of ​​the project scope and cost estimate is already available for the next stage of the analysis.

It should be noted that at the stage of choosing a strategy, and at the stage of analysis, and during design, regardless of the method used in the development of the project, one should always classify the planned functions of the system in order of importance. One possible format for representing such a classification, MoSCoW, was proposed in Clegg, Dai and Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

This abbreviation stands for: Must have - necessary functions; Should have - desirable functions; Could have - possible functions; Won "t have - missing functions.

The implementation of the functions of the second and third categories is limited by the time and financial framework: we develop what is needed, as well as the maximum possible number of functions of the second and third categories in order of priority.

To the begining

Analysis

The analysis stage involves a detailed study of business processes (functions defined at the strategy selection stage) and the information necessary for their implementation (entities, their attributes and relationships (relationships)). At this stage, an information model is created, and at the next design stage, a data model is created.

All information about the system collected at the strategy definition stage is formalized and refined at the analysis stage. Particular attention should be paid to the completeness of the transmitted information, the analysis of information for the absence of contradictions, as well as the search for information that is not used at all or duplicated. As a rule, the customer does not immediately form the requirements for the system as a whole, but formulates the requirements for its individual components. Pay attention to the consistency of these components.

Analysts collect and record information in two interrelated forms:

functions - information about events and processes that occur in business;

entities - information about things that are important to the organization and about which something is known.

The two classic results of analysis are:

a hierarchy of functions that breaks down the processing into its component parts (what is done and what it consists of);

entity-relationship model (Entry Relationship model, ER-model), which describes entities, their attributes and connections (relationships) between them.

These results are necessary but not sufficient. Sufficient results include data flow diagrams and entity life cycle diagrams. Quite often, analysis errors occur when trying to show the life cycle of an entity in an ER diagram.

Below we will review the three most commonly used structural analysis methodologies:

Entity-Relationship Diagrams (ERD), which serve to formalize information about entities and their relationships;

data flow diagrams (Data Flow Diagrams, DFD), which serve to formalize the representation of system functions;

state transition diagrams (State Transition Diagrams, STD), which reflect the behavior of the system, depending on time; Entity life cycle diagrams belong to this class of diagrams.

To the begining

ER diagrams

ER diagrams ( rice. 2) are used to design data and are a standard way of defining data and relationships between them. Thus, the detailing of data warehouses is carried out. The ER diagram contains information about the entities of the system and how they interact, includes the identification of objects that are important for the subject area (entities), the properties of these objects (attributes) and their relationships with other objects (links). In many cases, the information model is very complex and contains many objects.

Rice. 2. An example of an ER diagram

An entity is displayed as a rectangle with the name of the entity at the top (for example, TITLES). The box can list the attributes of an entity; attributes of ER-diagrams, typed in bold, are key (so Title Identity is a key attribute of the TITLES entity, other attributes are not key).

A relationship is represented by a line between two entities (blue lines in the figure).

Single line right ( rice. 3) means "one", "bird's foot", on the left is "many", and the relation is read along the line, such as "one to many". A vertical bar means "required", a circle - "optional", for example, for each publication in TITLE, a publisher must be indicated in PUBLISHERS, and one publisher in PUBLISHERS can issue several titles in TITLES. It should be noted that links are always commented (an inscription on the line depicting the link).

Rice. 3. ER diagram element

We also give an example ( rice. 4) images of the reflective relationship "employee", where one employee can supervise several subordinates and so on down the hierarchy of positions.

Rice. 4. ER diagram of a reflexive relation

Note that such a relationship is always optional, otherwise it would be an infinite hierarchy.

Entity attributes can be key - they are in bold; mandatory - they are preceded by the "*" sign, that is, their value is always known, optional (optional) - they are preceded by O, that is, the values ​​\u200b\u200bof this attribute at some point may be absent or undefined.

To the begining

arcs

If an entity has a set of mutually exclusive relationships with other entities, then such relationships are said to be in an arc. For example, a bank account can be issued either for a legal entity or for an individual. A fragment of the ER diagram for this type of relationship is shown in rice. 5.

Rice. 5. Arc

In this case, the OWNER attribute of the ACCOUNT entity has a special meaning for this entity - the entity is divided into types by category: "for an individual" and "for a legal entity". The resulting entities are called subtypes, and the original entity becomes a supertype. To understand whether a supertype is needed or not, it is necessary to establish how many of the same properties have different subtypes. It should be noted that the abuse of subtypes and supertypes is a fairly common mistake. They are depicted as shown in rice. 6.

Rice. 6. Subtypes (right) and supertype (left)

To the begining

Normalization

To prevent anomalies in data processing, normalization is used. The principles of normalization for information model objects are exactly the same as for data models.

Allowed link types. On closer examination, one-to-one relationships ( rice. 7) almost always turns out that A and B are actually different subsets of the same thing or different points of view on it, just having different names and differently described relationships and attributes.

Rice. 7. One-to-one relationships

Many-to-one relationships are shown in rice. 8.

Rice. 8. Many-to-One Relationships

I is a strong enough construct that an entry of entity B cannot be created without simultaneously creating at least one associated entry of entity A.

II is the most common form of communication. It assumes that each and every occurrence of entity A can exist only in the context of one (and only one) occurrence of entity B. In turn, occurrences of B can exist both in connection with occurrences of A, and without it.

III - rarely used. Both A and B can exist without a connection between them.

Many-to-many relationships are shown in rice. 9.

Rice. 9. Many-to-Many Relationships

I - such a construction often takes place at the beginning of the analysis stage and means a connection - either not fully understood and requiring additional permission, or reflecting a simple collective relationship - a doubly linked list.

II - rarely used. Such links are always subject to further detailing.

Consider now the recursive links ( rice. 10).

Rice. 10. Recursive links

I - rare, but occurs. Reflects links of an alternative type.

II - quite often used to describe hierarchies with any number of levels.

III - takes place in the early stages. Often reflects the structure of the "list of materials" (mutual nesting of components). Example: each COMPONENT may consist of one or more (other) COMPONENTS and each COMPONENT may be used in one or more (other) COMPONENTS.

Invalid link types. Invalid relationship types include the following: Mandatory many-to-many relationship ( rice. eleven) and a number of recursive links ( rice. 12).

Rice. 11. Invalid many-to-many relationships

Rice. 12. Invalid recursive links

A mandatory many-to-many relationship is basically impossible. Such a relationship would mean that none of the occurrences of A could exist without B, and vice versa. In fact, each such construction always turns out to be erroneous.

To the begining

Data flow diagrams

Logic DFD ( rice. 13) shows sources and sinks (destinations) of data external to the system, identifies logical functions (processes) and groups of data elements that connect one function with another (streams), and also identifies data storages (accumulators) that are accessed. Data flow structures and their component definitions are stored and parsed in the data dictionary. Each logical function (process) can be detailed using the lower level DFD; when further detail is no longer useful, one moves on to expressing the logic of the function using a process specification (mini-specification). The content of each store is also stored in a data dictionary, and the store data model is exposed using ER diagrams.

Rice. 13. DFD Example

In particular, the DFD does not show the processes that control the actual data flow and does not distinguish between valid and invalid paths. DFDs contain a lot of useful information, and in addition:

allow you to present the system in terms of data;

illustrate external data feed mechanisms that would require special interfaces;

allow to represent both automated and manual processes of the system;

perform data-oriented partitioning of the entire system.

Data flows are used to model the transfer of information (or even physical components) from one part of a system to another. The flows in the diagrams are represented by named arrows, the arrows indicate the direction of information flow. Sometimes information can move in one direction, be processed and returned to its source. Such a situation can be modeled either by two different flows, or by one bidirectional one.

A process transforms an input stream into an output stream according to the action specified by the process name. Each process must have a unique number to reference it within the diagram. This number can be used in conjunction with the diagram number to provide a unique process index throughout the model.

Data storage (data storage) allows you to define data in a number of areas that will be stored in memory between processes. In fact, the storage represents "slices" of data streams in time. The information it contains can be used at any time after it is defined, and the data can be chosen in any order. The name of the repository should identify its contents. In the case when the data flow enters (leaves) into (from) the storage and its structure corresponds to the structure of the storage, it must have the same name, which does not need to be reflected in the diagram.

An external entity (terminator) represents an entity outside the context of the system, which is the source or receiver of system data. Its name must contain a noun, such as "Client". It is assumed that the objects represented by such nodes should not participate in any processing.

To the begining

STD State Transition Diagrams

The life cycle of an entity belongs to the class of STD diagrams ( rice. 14). This diagram reflects the change in the state of an object over time. For example, consider the state of a product in a warehouse: a product can be ordered from a supplier, delivered to a warehouse, stored in a warehouse, undergo quality control, sold, rejected, returned to a supplier. The arrows in the diagram show the allowed state changes.

Fig.14. DFD example

There are several different options for displaying such diagrams, the figure shows only one of them.

To the begining

Some principles for checking the quality and completeness of an information model (source - Richard Barker, Case Method: Entity Relationship Modeling, Addison-Wesley, 1990)

If you want to create a high-quality model, you will have to resort to the help of analysts who are well versed in CASE technology. However, this does not mean that only analysts should be involved in the construction and control of the information model. The help of colleagues can also be very helpful. Involve them in checking the goal and in a detailed study of the built model, both in terms of logic and in terms of taking into account aspects of the subject area. Most people find it easier to find flaws in someone else's work.

Regularly present your information model or its individual fragments about which you have doubts for the approval of users. Pay special attention to exceptions to the rules and restrictions.

To the begining

Entity quality

The main guarantee of the quality of an entity is the answer to the question whether the object is really an entity, that is, an important object or phenomenon, information about which should be stored in the database.

List of verification questions for the entity:

Does the name of an entity reflect the essence of this object?

Is there an intersection with other entities?

Are there at least two attributes?

Are there no more than eight attributes in total?

Are there any synonyms/homonyms for this entity?

Is the entity fully defined?

Is there a unique identifier?

Is there at least one connection?

Is there at least one function for creating, searching, updating, deleting, archiving, and using an entity value?

Is there a history of changes?

Is there compliance with the principles of data normalization?

Does the same entity exist in another application system, perhaps under a different name?

Is the essence too general?

Is the level of generalization embodied in it sufficient?

List of screening questions for the subtype:

Are there any overlaps with other subtypes?

Does the subtype have any attributes and/or relationships?

Do they all have their own unique identifiers, or do they all inherit one from the supertype?

Is there an exhaustive set of subtypes?

Isn't a subtype an example of an entity occurrence?

Do you know of any attributes, relationships, and conditions that distinguish this subtype from others?

To the begining

Attribute Quality

It is necessary to find out whether these are really attributes, that is, whether they describe this entity in one way or another.

List of security questions for an attribute:

Is the name of an attribute a singular noun that reflects the essence of the property denoted by the attribute?

Doesn't the attribute name include the entity name (it shouldn't)?

Does the attribute only have one value at a time?

Are there duplicate values ​​(or groups) missing?

Are the format, length, valid values, derivation algorithm, etc. described?

Could this attribute be an omitted entity that would be useful for another application system (existing or proposed)?

Could it be a missed link?

Is there a need for a history of changes?

Does its value depend only on the given entity?

If the value of an attribute is required, is it always known?

Is there a need to create a domain for this and similar attributes?

Does its value depend only on some part of the unique identifier?

Does its value depend on the values ​​of some attributes not included in the unique identifier?

Introduction

The design of information systems always begins with the definition of the purpose of the project. The main task of any successful project is to ensure that at the time of system launch and during the entire period of its operation it is possible to provide:

• the required functionality of the system and the degree of adaptation to the changing conditions of its functioning;
• required system throughput;
• the required response time of the system to a request;
• trouble-free operation of the system in the required mode, in other words, the readiness and availability of the system to process user requests;
• ease of operation and support of the system;
• the necessary security.

Performance is the main factor that determines the efficiency of a system. Good design is the foundation of a high performance system.

Information systems design covers three main areas:

• designing data objects to be implemented in the database;
• designing programs, screen forms, reports that will ensure the execution of data queries;
• taking into account a specific environment or technology, namely: network topology, hardware configuration, architecture used (file-server or client-server), parallel processing, distributed data processing, etc.

In real conditions, design is a search for a way that satisfies the requirements of the functionality of the system by means of available technologies, taking into account the given restrictions.

Any project is subject to a number of absolute requirements, for example, the maximum project development time, the maximum financial investment in the project, etc. One of the difficulties of design is that it is not as structured as the analysis of project requirements or the implementation of a particular design solution.

It is believed that a complex system cannot be described in principle. This, in particular, concerns enterprise management systems. One of the main arguments is a change in the conditions for the functioning of the system, for example, a directive change in certain flows of information by the new leadership. Another argument is the scope of the terms of reference, which for a large project can be hundreds of pages, while the technical project may contain errors. The question arises: maybe it’s better not to conduct surveys at all and not to make any technical project, but to write the system “from scratch” in the hope that some miraculous coincidence of the customer’s desire with what the programmers wrote, and also that that all this will work stably?

If you look at it, is the development of the system really so unpredictable and is it really impossible to get information about it? It is likely that an idea of ​​the system as a whole and of the ways (management) envisaged for its development can be obtained through seminars. After that, break the complex system into simpler components, simplify the connections between the components, provide for the independence of the components and describe the interfaces between them (so that a change in one component does not automatically entail a significant change in another component), as well as the possibility of expanding the system and "stubs" for unrealizable in one or another version of the system of functions. Based on such elementary considerations, the description of what is supposed to be implemented in the information system no longer seems so unrealistic. You can follow the classical approaches to the development of information systems, one of which - the "waterfall" scheme (Fig. 1) - is described below. Some other approaches to the development of information systems will be briefly considered, where the use of the elements described in the waterfall scheme is also acceptable. Which approach from those described below to follow (and whether it makes sense to come up with your own approach) is to some extent a matter of taste and circumstances.

The software life cycle is a model for its creation and use. The model reflects its various states, starting from the moment the need for this software arises and ending with the moment it is completely out of use for all users. The following life cycle models are known:

• cascade model. The transition to the next stage means the complete completion of the work at the previous stage.
• Staged model with intermediate control. Software development is carried out in iterations with feedback loops between stages. Inter-stage adjustments can reduce the complexity of the development process compared to the waterfall model; the lifetime of each of the stages is stretched for the entire development period.
• spiral model. Particular attention is paid to the initial stages of development - strategy development, analysis and design, where the feasibility of certain technical solutions is checked and justified through the creation of prototypes (prototyping). Each turn of the spiral involves the creation of a certain version of the product or any of its components, while the characteristics and goals of the project are specified, its quality is determined, and the work of the next turn of the spiral is planned.

Below we will consider some of the project development schemes.

"Waterfall" - project development scheme

Very often, design is described as a separate stage of project development between analysis and development. However, in reality, there is no clear division of the project development stages - design, as a rule, does not have a clearly defined beginning and end, and often continues at the testing and implementation stages. Speaking about the testing stage, it should also be noted that both the analysis stage and the design stage contain elements of the work of testers, for example, to obtain an experimental justification for choosing a particular solution, as well as to evaluate the quality criteria of the resulting system. At the stage of operation, it is appropriate to talk about the maintenance of the system.

Below we will consider each of the stages, dwelling in more detail on the design stage.

Strategy

Defining a strategy involves examining the system. The main task of the survey is to assess the real scope of the project, its goals and objectives, as well as to obtain definitions of entities and functions at a high level.

At this stage, highly qualified business analysts are involved, who have constant access to the management of the company; the stage involves close interaction with the main users of the system and business experts. The main task of interaction is to obtain as complete information about the system as possible (a complete and unambiguous understanding of customer requirements) and transfer this information in a formalized form to system analysts for the subsequent analysis stage. As a rule, information about the system can be obtained as a result of conversations or seminars with management, experts and users. Thus, the essence of this business, the prospects for its development and the requirements for the system are determined.

At the completion of the main phase of the system survey, technicians form likely technical approaches and estimate the costs of hardware, purchased software, and development of new software (which, in fact, is assumed by the project).

The result of the strategy definition stage is a document that clearly states what the customer will receive if he agrees to finance the project; when he receives the finished product (work schedule); how much it will cost (for large projects, a schedule of financing at different stages of work should be drawn up). The document should reflect not only the costs, but also the benefits, for example, the payback time of the project, the expected economic effect (if it can be estimated).

The document must describe:

• restrictions, risks, critical factors affecting the success of the project, for example, the response time of the system to a request is a given limitation, and not a desirable factor;
• a set of conditions under which it is supposed to operate the future system: system architecture, hardware and software resources provided to the system, external conditions for its functioning, composition of people and work that ensure the smooth functioning of the system;
• deadlines for completion of individual stages, the form of delivery of work, resources involved in the process of developing the project, measures to protect information;
• description of the functions performed by the system;
• future requirements for the system in the event of its development, for example, the ability of the user to work with the system using the Internet, etc.;
• entities necessary to perform system functions;
• interfaces and distribution of functions between a person and a system;
• requirements for software and information components of software, requirements for DBMS (if the project is supposed to be implemented for several DBMS, then the requirements for each of them, or general requirements for an abstract DBMS and a list of DBMS recommended for this project that satisfy the specified conditions);
• that will not be implemented within the framework of the project.

The work performed at this stage allows us to answer the question of whether it is worth continuing this project and what customer requirements can be met under certain conditions. It may turn out that the project does not make sense to continue, for example, because certain requirements cannot be satisfied for some objective reasons. If a decision is made to proceed with the project, then an idea of ​​the project scope and cost estimate is already available for the next stage of the analysis.

It should be noted that at the stage of choosing a strategy, and at the stage of analysis, and during design, regardless of the method used in the development of the project, one should always classify the planned functions of the system in order of importance. One possible format for representing such a classification, MoSCoW, was proposed in Clegg, Dai and Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

This abbreviation stands for: Must have - necessary functions; Should have - desirable functions; Could have - possible functions; Won't have - missing features.

The implementation of the functions of the second and third categories is limited by the time and financial framework: we develop what is needed, as well as the maximum possible number of functions of the second and third categories in order of priority.

Analysis

The analysis stage involves a detailed study of business processes (functions defined at the strategy selection stage) and the information necessary for their implementation (entities, their attributes and relationships (relationships)). At this stage, an information model is created, and at the next design stage, a data model is created.

All information about the system collected at the strategy definition stage is formalized and refined at the analysis stage. Particular attention should be paid to the completeness of the transmitted information, the analysis of information for the absence of contradictions, as well as the search for information that is not used at all or duplicated. As a rule, the customer does not immediately form the requirements for the system as a whole, but formulates the requirements for its individual components. Pay attention to the consistency of these components.

Analysts collect and record information in two interrelated forms:

• functions - information about events and processes that occur in business;
• entities - information about things that are important to the organization and about which something is known.

The two classic results of analysis are:

• a hierarchy of functions that breaks down the processing into its component parts (what is done and what it consists of);
• entity-relationship model (Entry Relationship model, ER-model), which describes entities, their attributes and relationships (relationships) between them.

These results are necessary but not sufficient. Sufficient results include data flow diagrams and entity life cycle diagrams. Quite often, analysis errors occur when trying to show the life cycle of an entity in an ER diagram.

Below we will review the three most commonly used structural analysis methodologies:

• Entity-Relationship Diagrams (ERD), which serve to formalize information about entities and their relationships;
• data flow diagrams (Data Flow Diagrams, DFD), which serve to formalize the representation of system functions;
• state transition diagrams (State Transition Diagrams, STD), which reflect the behavior of the system, depending on time; Entity life cycle diagrams belong to this class of diagrams.

Normalization

To prevent anomalies in data processing, normalization is used. The principles of normalization for information model objects are exactly the same as for data models.

Allowed link types. Closer examination of the one-to-one relationship (Figure 7) almost always reveals that A and B are actually different subsets of the same subject or different points of view on it, just having different names and described differently. links and attributes.

Many-to-one relationships are shown in Fig. 8 .

I is a strong enough construct that an entry of entity B cannot be created without simultaneously creating at least one associated entry of entity A.

II is the most common form of communication. It assumes that each and every occurrence of entity A can exist only in the context of one (and only one) occurrence of entity B. In turn, occurrences of B can exist both in connection with occurrences of A, and without it.

III - rarely used. Both A and B can exist without a connection between them.

Many-to-many relationships are shown in Fig. 9 .

I - such a construction often takes place at the beginning of the analysis stage and means a connection - either not fully understood and requiring additional permission, or reflecting a simple collective relationship - a doubly linked list.

II - rarely used. Such links are always subject to further detailing.

Let us now consider recursive links (Fig. 10).

I - rare, but occurs. Reflects links of an alternative type.

II - quite often used to describe hierarchies with any number of levels.

III - takes place in the early stages. Often reflects the structure of the "list of materials" (mutual nesting of components). Example: each COMPONENT may consist of one or more (other) COMPONENTS and each COMPONENT may be used in one or more (other) COMPONENTS.

Invalid link types. Invalid relationship types include the following: the mandatory many-to-many relationship (Figure 11) and the set of recursive relationships (Figure 12).

A mandatory many-to-many relationship is basically impossible. Such a relationship would mean that none of the occurrences of A could exist without B, and vice versa. In fact, each such construction always turns out to be erroneous.

Data flow diagrams

Logical DFD (Fig. 13) shows data sources and sinks (destinations) external to the system, identifies logical functions (processes) and groups of data elements that link one function to another (streams), and also identifies data storages (accumulators), to which access is being made. Data flow structures and their component definitions are stored and parsed in the data dictionary. Each logical function (process) can be detailed using the lower level DFD; when further detail is no longer useful, one moves on to expressing the logic of the function using a process specification (mini-specification). The content of each store is also stored in a data dictionary, and the store data model is exposed using ER diagrams.

In particular, the DFD does not show the processes that control the actual data flow and does not distinguish between valid and invalid paths. DFDs contain a lot of useful information, and in addition:

• allow you to present the system in terms of data;
• illustrate external data feed mechanisms that would require special interfaces;
• allow to represent both automated and manual processes of the system;
• perform data-oriented partitioning of the entire system.

Data flows are used to model the transfer of information (or even physical components) from one part of a system to another. The flows in the diagrams are represented by named arrows, the arrows indicate the direction of information flow. Sometimes information can move in one direction, be processed and returned to its source. Such a situation can be modeled either by two different flows, or by one bidirectional one.

A process transforms an input stream into an output stream according to the action specified by the process name. Each process must have a unique number to reference it within the diagram. This number can be used in conjunction with the diagram number to provide a unique process index throughout the model.

Data storage (data storage) allows you to define data in a number of areas that will be stored in memory between processes. In fact, the storage represents "slices" of data flows in time. The information it contains can be used at any time after it is defined, and the data can be chosen in any order. The name of the repository should identify its contents. In the case when the data flow enters (leaves) into (from) the storage and its structure corresponds to the structure of the storage, it must have the same name, which does not need to be reflected in the diagram.

An external entity (terminator) represents an entity outside the context of the system, which is the source or receiver of system data. Her name must contain a noun, such as "Client". It is assumed that the objects represented by such nodes should not participate in any processing.

Some principles for checking the quality and completeness of the information model
(source - Richard Barker, Case Method: Entity Relationship Modeling, Addison-Wesley, 1990)

If you want to create a high-quality model, you will have to resort to the help of analysts who are well versed in CASE technology. However, this does not mean that only analysts should be involved in the construction and control of the information model. The help of colleagues can also be very helpful. Involve them in checking the goal and in a detailed study of the built model, both in terms of logic and in terms of taking into account aspects of the subject area. Most people find it easier to find flaws in someone else's work.

Regularly present your information model or its individual fragments about which you have doubts for the approval of users. Pay special attention to exceptions to the rules and restrictions.

Entity quality

The main guarantee of the quality of an entity is the answer to the question whether the object is really an entity, that is, an important object or phenomenon, information about which should be stored in the database.

List of verification questions for the entity:

• Does the name of an entity reflect the essence of this object?
• Is there an intersection with other entities?
• Are there at least two attributes?
• Are there no more than eight attributes in total?
• Are there any synonyms/homonyms for this entity?
• Is the entity fully defined?
• Is there a unique identifier?
• Is there at least one connection?
• Is there at least one function for creating, searching, updating, deleting, archiving, and using an entity value?
• Is there a history of changes?
• Is there compliance with the principles of data normalization?
• Does the same entity exist in another application system, perhaps under a different name?
• Is the essence too general?
• Is the level of generalization embodied in it sufficient?

List of screening questions for the subtype:

• Are there any overlaps with other subtypes?
• Does the subtype have any attributes and/or relationships?
• Do they all have their own unique identifiers, or do they all inherit one from the supertype?
• Is there an exhaustive set of subtypes?
• Isn't a subtype an example of an entity occurrence?
• Do you know of any attributes, relationships, and conditions that distinguish this subtype from others?

Attribute Quality

It is necessary to find out whether these are really attributes, that is, whether they describe this entity in one way or another.

List of security questions for an attribute:

• Is the name of an attribute a singular noun that reflects the essence of the property denoted by the attribute?
• Doesn't the attribute name include the entity name (it shouldn't)?
• Does the attribute only have one value at a time?
• Are there duplicate values ​​(or groups) missing?
• Are the format, length, valid values, derivation algorithm, etc. described?
• Could this attribute be an omitted entity that would be useful for another application system (existing or proposed)?

We need to find out if the relationships reflect the really important relationships observed between the entities.

List of verification questions for communication:

• Is there a description for each party involved, does it accurately reflect the content of the relationship, and does it fit within the accepted syntax?
• Are there only two parties involved?

Is the connection not portable?

• Is the degree of connection and obligation specified for each party?
• Is the connection structure allowed?

Is the connection design one of the rarely used ones?

• Isn't it redundant?
• Doesn't it change over time?
• If the connection is mandatory, does it always reflect the relationship to the entity representing the opposite side?

For exclusive association:

• Do all link ends covered by an exclusive arc have the same binding type?
• Do all of them refer to the same entity?
rice. 15) such a decomposition. Consider the simplest problem of issuing an invoice to a customer when goods are released from a warehouse, provided that the set of goods that the customer wants to purchase is already known (we will not consider the problem of choosing goods in this example).

Obviously, the operation of selecting and calculating discounts can also be broken down into smaller operations, such as calculating discounts for loyalty (the customer buys goods for a long time) and calculating discounts for the quantity of goods purchased. Atomic functions are described in detail, for example using DFD and STD. Obviously, such a description of functions does not exclude additional verbal description (for example, comments).

It should be noted that at the analysis stage, attention should be paid to the functions of analysis and processing of possible errors and deviations from the expected standard of the system. The most critical processes for the operation of the system should be identified and a particularly rigorous error analysis should be provided for them. DBMS error handling (return codes), as a rule, is a separate set of functions or a single function.

Strategy Refinement

At the analysis stage, the hardware and software selected for the final implementation are refined. For this, testing groups and technical specialists can be involved. When designing an information system, it is important to take into account the further development of the system, for example, an increase in the volume of processed data, an increase in the intensity of the flow of requests, changes in the requirements for the reliability of the information system.

At the analysis stage, sets of task models are determined to obtain comparative characteristics of various DBMS that were considered at the stage of determining the strategy for implementing the information system. At the stage of determining the strategy, one DBMS can be selected. There is already much more data about the system at the analysis stage, and they are more detailed. The data obtained, as well as the characteristics transmitted by the testing groups, may show that the choice of the DBMS at the stage of determining the strategy was incorrect and that the selected DBMS cannot satisfy certain requirements of the information system. The same data can be obtained regarding the choice of hardware platform and operating system. Obtaining such results initiates a change in the data obtained at the stage of determining the strategy, for example, the cost estimate for the project is recalculated.

The choice of development tools is also specified at the analysis stage. Since the analysis phase provides a more complete picture of the information system than it did in the strategy definition phase, the work plan can be adjusted. If the development tool chosen at the previous stage does not allow one or another part of the work to be completed within the specified time, then a decision is made to change the deadlines (as a rule, this is an increase in the development time) or to change the development tool. When choosing one or another tool, one should take into account the presence of highly qualified personnel who own the selected development tools, as well as the presence of administrators of the selected DBMS. These recommendations will also refine the data of the strategy selection stage (the set of conditions under which the future system is supposed to be operated).

Limitations, risks, critical factors are also specified. If any requirements cannot be satisfied in the information system implemented using the DBMS and software tools selected at the stage of determining the strategy, then this also initiates the refinement and change of the data obtained (ultimately, cost estimates and work plans, and possibly change in customer requirements for the system, for example, their weakening). The features that will not be implemented in the system are described in more detail.

ComputerPress 9 "2001