The design of information systems is a multi-stage process of their creation and / or modernization by applying an ordered set of methodologies and tools. Design (as opposed to modeling) involves working with a non-existent object and is aimed at creating an information system in the field of:
- processing objects of the future database,
- writing programs (including reporting and screen forms) that ensure the execution of data queries,
- accounting for the functioning of a particular environment (technology).
If we single out the design stage of information systems as a separate stage, then it can be placed between the stages of analysis and development. However, in practice, a clear division into stages, as a rule, is difficult or impossible, since the design, formally starting with the definition project goals, often continues through the testing and implementation stages.
Information system design goal and related concepts
Modern leaders of public and private organizations are aware that the speed of information processing, which is constantly changing and growing in volume, is a matter of the company's survival in the market and competitive advantage. In general, the goals of projects for the creation of information systems are reduced to providing conditions that allow this information to be received, processed and used by creating a functional fail-safe system with sufficient:
- level of adaptability to changing conditions,
- throughput,
- system response time to a request,
- security level,
- degree of ease of use.
An information system (IS) is a set of information contained in a database and technologies (as well as technical tools) that provide information processing. In this case, technologies also include methods for detecting, collecting, processing, storing, disseminating information, and methods that allow these methods to be implemented. information management it comes down to the use of these methods to control the processes of planning, design, operation and analysis of IS. The design technology is based on the methodology chosen for a specific task as a set of principles expressed in a single specific concept.
Organization of IS design
The organization of IS design is usually divided into 2 types:
- Canonical design reflects the technology features of the original (individual) process.
- Typical design, which is characterized by a standard design solution (TPR), is replicated and suitable for repeated use.
Canonical design is distinguished by the reflection of manual design technology, implementation at the level of performers, and the use of universal computer support tools.
Canonical design is used mainly for local and relatively small ICs with minimal use of standard solutions. Adaptation of design solutions occurs only through reprogramming of software modules. 
Canonical design is organized using the cascade life cycle model. This involves dividing the process into the following steps and stages:
- Pre-project stage. Produced and compiled technical specifications. That is, the requirements for IP are formed, its concept is developed, a feasibility study is drawn up and technical specifications are written.
- The project stage provides for the preparation of draft and technical designs, the development of working documentation.
- The post-project stage gives rise to activities for the implementation of IS, staff training, and analysis of test results. Part of this stage is the maintenance of IS and the elimination of identified shortcomings.
Stages, if necessary, can be enlarged or detailed - combine successive stages, exclude "extra" ones, start the next stage before the completion of the previous one.
The typical design method is distinguished by the possibility of decomposing the designed IS with division into components, which include program modules, subsystems, task complexes, etc. To implement the components, you can use standard solutions that already exist on the market and customize them for the needs of a particular organization. At the same time, typical design assumes the mandatory availability of documentation describing in detail the TPR and tuning procedures.
The decomposition can have several levels, which makes it possible to single out the classes of the TPR:
- elemental - for a separate task (element),
- subsystem - for individual subsystems,
- object - industry standard design solutions containing the entire set of subsystems.
The possibility of implementing a modular approach is considered an advantage of elemental TPR. However, in case of incompatibility of different elements, the process of combining them leads to an increase in costs. Subsystem TPR, in addition to implementing a modular approach, make it possible to carry out parametric adjustment to objects of different levels of control. Consolidation problems arise when a product from several different software vendors is involved. In addition, the adaptability of the TPR from the standpoint of continuous process reengineering is considered insufficient. Object TPR, in comparison with the previous classes, have a large number of advantages:
- scalability, which makes it possible to use IS configurations for a different number of jobs,
- methodological unity of components,
- compatibility of IC components,
- architecture openness - the ability to deploy design solutions on platforms of various types,
- configurability - the ability to use the desired subset of IS components.
During the implementation of standard design, parametric-oriented and model-oriented approaches are used.
Basic IC design methodologies
The specific features of the design process make it possible to single out methodologies based on different principles. Among the main modern IS design methodologies are the following:
- SADT. The methodology of functional work modeling, which is based on structural analysis and graphical representation organization as a system of functions. Functional, informational and dynamic models stand out here. The methodology is currently known as the IDEF0 notation (standard). The analyzed process is graphically represented in the form of a quadrilateral, where regulatory and control actions are shown on top, control objects on the bottom, input data on the left, and output data on the right.
- RAD. Rapid Application Development Methodology. In RAD, rapid application development is possible through the use of component-oriented design. The methodology is used on projects with a limited budget, fuzzy IP requirements, and tight deadlines. It is used if the user interface can be demonstrated in a prototype, and the project can be divided into functional elements.
- RUP. The RUP methodology implements iterative and incremental (incremental) approaches. The system is built on the basis of the information system architecture, and planning and project management are based on the functional requirements for IS. The development of a common information system takes place in iterations, as a complex of separate small projects with their own plans and tasks. The iterative cycle is characterized by periodic feedback and adaptation to the IS core.
There are several classifications of methodologies: according to the use of TPR, according to the use of automation tools, etc. For example, according to the degree of adaptability, reconstructions are distinguished (when modules are reprogrammed), parameterizations (when a change in parameters entails the generation of a design solution), restructuring (when a change in the model of the problem area accompanied by automatic generation of the design solution).
Service center - an organization engaged in the provision of services for service support and maintenance of machinery, equipment and other products. The activities of service centers include pre-sales, warranty and after-sales repairs.
Enterprise IP Mikhailov A.O. deals with repair and maintenance household appliances and electronics, as well as computers, phones and tablets that customers bring to the office, as well as refilling cartridges and installing networks and PBXs. If it is not possible to deliver the equipment by the client himself, a visit to the place is carried out, and, if necessary, it is delivered by service center. When the client contacts the service center, the dispatcher draws up an application for acceptance of the order. An analysis of the object is carried out, as a result of which a conclusion is made whether the equipment will be repaired or not. The engineering department draws up a price list for the repair and maintenance of equipment, as it works with suppliers of spare parts and devices for equipment repair. Repairs to be carried out special equipment following the safety rules. The company also sells peripherals for phones, tablets and computers. The enterprise is engaged in purchases of second-hand equipment and the equipment which has failed.
The company is working qualified specialists with many years of experience. The director oversees the entire operation of the enterprise.
Company address:
Perm Territory, Kungur, st. Lenina 66
Working mode:
Mon-Fri: 10 - 19 without lunch
Sun: day off.
By structuring the list of services, the company can increase its profits, expand the boundaries of the enterprise or open another service center in another place, the quality of the services provided can also increase and the number of customers can increase.
The conducted analysis of the subject area provides a complete description of the subject area of the enterprise IP Mikhailov A.O. to create a workable information system for this enterprise. A description of the work of the service center is given, indicating the work of the engineering department. The organizational structure of the enterprise was also created, which shows the interaction of the director and subordinates.
Formation of basic documents for managing an information system project
A project is a set of tasks or activities related to the achievement of a planned goal, which is usually unique and non-repetitive.
Project Management - the use of knowledge, skills, methods, tools and technologies in the implementation of the project in order to achieve or exceed the expectations of project participants.
In order to properly manage an information system project, it is necessary to generate basic project management documents. The basic documents will be the Charter and the Project Management Plan.
Project charter
The project charter is the instrument that formally authorizes the project and is the link that connects the upcoming project to current work organizations.
A project charter documents the initial requirements for a project that meet the needs and expectations of stakeholders.
There is a project charter.
This document usually reflects the situation on the part of the client organization, is issued by a leader external to the project, and appoints the project manager, giving him the authority to use the resources of the organization in the project.
The project charter should contain the following information:
Requirements for the project and the product of the project, in a fairly general form;
Objective of the project;
Information about the appointed project manager and the level of his authority;
Schedule of control events;
Relations between project participants;
Functional organizations and their participation;
Assumptions about the organization and environment, as well as external assumptions;
Restrictions regarding the organization and environment, as well as external restrictions;
A real business case that serves as a justification for the project with data on return on investment;
Project budget.
A project charter increases the likelihood of successful project completion. It documents the intentions of the project participants at the very beginning of the project and can serve as a fundamental point of resolution for disputes between project team members and the performing organization.
During the drafting of the project charter, the charter of the rules for organizing the work of the project was carried out with the help of documentation, strategies, goals, project methodology, role functions and project rules necessary to achieve the business goals of the project. Responsible for management and implementation have been identified.
Developing a charter takes a significant amount of time. When creating the next project, the developed charter can be used as a template, so that the development of the charter takes less time. A project charter helps with project management because some information is required to work in MS Project.
Project management plan
Project Management Plan - a set of approved formal documents that specify how the project will be executed and how the project will be monitored and managed. The plan may be summary or detailed and may include one or more subsidiary management plans and other planning documents.
The project management plan development process is the process of documenting the activities needed to define, prepare, integrate, and coordinate all supporting plans. A well-written project management plan is the main source of information about how the project will be planned, evaluated, controlled and closed. The project management plan is updated and edited as part of the project's integrated change management process.
1 Supporting project management plans, which include:
Project Scope Management Plan;
Project schedule management plan;
Project cost management plan;
Project quality management plan;
Staffing management plan;
Project communications management plan;
Project risk management plan;
Configuration management plan.
2 Project baseline, consisting of:
Basic project schedule;
Basic plan for cost;
Basic plan for quality;
Basic plan for configuration;
Risk register.
3 Results of the analysis carried out by the project team regarding the content, scope and timing of the project.
For the project of the information system "Accounting for the services provided", a project management plan was created. (Appendix B)
The first paragraph of the project management plan indicates the name of the project. The project name cannot be changed throughout the life of the project.
The second paragraph defines the goals and objectives of the project. Goals are formed based on the requirements of the customer, which are to automate the main business processes of the enterprise. Goals were set, such as attracting customers and increasing profits, improving the quality of services provided.
The third paragraph defines the requirements for the design solution and the results of the project. This section is an element of the basic content of the project. To provide a link between customer requirements and project results, it is recommended to use the quality function.
The fourth point defines the boundaries of the project. This is the basic element of the content of the project. The project scope describes what is included in the project to ensure that a project participant does not mistakenly consider a product, service, or result to be part of the project.
The fifth paragraph defines the tools and technologies for the implementation of project management.
In the sixth paragraph, there is a hierarchical work structure - a model that reveals the project level by level to such a degree of detail that is necessary for effective planning and control of the project.
The seventh point describes the need for resources. It is determined by the complexity of the work reflected in the previously developed IBS.
The eighth point of the Plan shows an enlarged calendar plan. It is developed based on milestones, information from the Project Charter, and information from the project management methodology used.
The ninth point is the critical success factors. It describes the conditions, the provision of which on the project can be the key to success.
The tenth and eleventh paragraphs reflect the assumptions and restrictions on the part of the performer. As the project progresses, the restrictions may change.
The twelfth point is the originally formulated risks. Already known risks and main categories of potential risks are indicated.
Risk management is the processes associated with the identification, analysis of risks and decision-making, which include maximizing the positive and minimizing the negative consequences of the occurrence of risk events.
Risk Management Planning - The decision-making process for applying and planning risk management for a specific project. This process may include decisions on organization, staffing of project risk management procedures, selection of preferred methodology, data sources for risk identification, time frame for situation analysis.
Risk management planning - selection of approaches and planning activities for project risk management.
1 Risk identification - identifying risks that can affect the project and documenting their characteristics.
2 Qualitative risk assessment - a qualitative analysis of risks and their conditions of occurrence in order to determine their impact on the success of the project.
3 Quantification - quantitative analysis the likelihood of occurrence and the impact of the consequences of risks on the project.
4 Risk response planning - determination of procedures and methods for mitigating the negative consequences of risk events and using possible benefits.
5 Risk monitoring and control - monitoring risks, identifying remaining risks, implementing the project's risk management plan, and evaluating the effectiveness of risk mitigation actions.
The risk management plan is presented. (Appendix B)
The project management plan of the information system "Accounting for the provided services" allowed to create documents and describe the characteristics and boundaries of the project, the services associated with it, as well as methods of acceptance and content management. The scope statement allowed the desired outcome to be assessed and served as the basis for a baseline scope plan to be followed for all project activities.
The development of basic documentation for the project management of the information system "Accounting for the services provided" made it possible to describe some of the documents for the high-quality and successful implementation of project management in MS Project. The key to success is understanding the need for these documents in the project management process. The result of this work was the developed project charter and project management plan, which will be used in further work.
The result of the first section was the structuring of the IS project "Accounting for the services provided" for the enterprise IP Mikhailov A.O., the charter of the project and the project management plan were also developed, which were used in further work on project management. The process of generating basic documents is the most important part of project management, as it affects the quality, duration and success of the project.
Introduction
Conclusion
Literature
Introduction
Development various areas human activity at the present stage is impossible without widespread use computer science and creation of information systems of various directions. Information processing in such systems has become an independent scientific and technical direction.
After the build phase information model system design begins. At this stage, the choice technological solutions on the basis of which the information system will be built.
Information in modern world has become one of the most important resources, and information systems (IS) have become essential tool in almost all areas of activity.
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.
The variety of tasks solved with the help of IS has led to the emergence of many different types of systems that differ in the principles of construction and the rules of information processing embedded in them.
aim control work is - consider step by step, the process of creating information systems.
The objectives of this work are to find out the main purpose of design, as well as the purpose of creating information systems.
1. Design of information systems
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;
the required throughput of the system;
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;
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 that will 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.
According to modern methodology, the process of creating an IS is a process of building and sequentially transforming a number of consistent models at all stages of the life cycle (LC) of an IS. At each stage of the life cycle, models specific to it are created - organizations, requirements for IP, project IP, requirements for applications, etc. Models are formed by working groups of the project team, saved and accumulated in the project repository. The creation of models, their control, transformation and provision for collective use is carried out using special software tools - CASE-tools.
The process of creating an IP is divided into a number of stages (stages), limited by certain time frames and ending with the release of a specific product (models, software products, documentation, etc.).
Usually, the following stages of creating an IS are distinguished: the formation of system requirements, design, implementation, testing, commissioning, operation and maintenance.
The initial stage of the process of creating an IS is the modeling of business processes that take place in an organization and implement its goals and objectives. The organization model, described in terms of business processes and business functions, allows us to formulate the basic requirements for IS. This fundamental position of the methodology provides objectivity in the development of requirements for system design. The set of models for describing the requirements for IS is then converted into a system of models that describe the conceptual design of IS. Models of IS architecture, requirements for software (SW) and information support(AND ABOUT). Then the software and IO architecture is formed, corporate databases and individual applications are identified, application requirements models are formed and their development, testing and integration are carried out.
The purpose of the initial stages of the creation of IS, performed at the stage of analysis of the organization's activities, is the formation of requirements for IS that correctly and accurately reflect the goals and objectives of the customer organization. To specify the process of creating an IS that meets the needs of the organization, you need to find out and clearly articulate what these needs are. To do this, it is necessary to determine the requirements of customers for IS and display them in the language of models in the requirements for the development of an IS project in such a way as to ensure compliance with the goals and objectives of the organization.
The task of forming requirements for IP is one of the most responsible, difficult to formalize and the most expensive and difficult to correct in case of an error. Modern tools and software products allow you to quickly create IS according to ready-made requirements. But often these systems do not satisfy customers, require numerous improvements, which leads to a sharp increase in the actual cost of IS. The main reason for this situation is the incorrect, inaccurate or incomplete definition of IP requirements at the analysis stage.
At the design stage, first of all, data models are formed. Designers receive the results of the analysis as initial information. Building logical and physical data models is a major part of database design. The information model obtained during the analysis is first converted into a logical and then into a physical data model.
In parallel with the design of the database schema, the design of processes is carried out in order to obtain specifications (descriptions) of all IS modules. Both of these design processes are closely related because some of the business logic is usually implemented in the database (constraints, triggers, stored procedures). The main goal of process design is to map the functions obtained at the analysis stage into the modules of the information system. When designing modules, program interfaces are defined: menu layout, window appearance, hot keys and related calls.
The end products of the design phase are:
database schema (based on the ER model developed at the analysis stage);
A set of specifications for system modules (they are built on the basis of function models).
In addition, at the design stage, the development of the IS architecture is also carried out, including the choice of platform (platforms) and operating system ( operating systems). In a heterogeneous IS, several computers can operate on different hardware platforms and running different operating systems. In addition to the choice of platform, the following characteristics of the architecture are determined during the design phase:
whether it will be a "file-server" or "client-server" architecture;
Will it be a 3-tier architecture with the following layers: server, middleware (application server), client software;
Whether the database will be centralized or distributed. If the database is distributed, then what mechanisms will be used to maintain data consistency and relevance;
• whether the database will be homogeneous, that is, whether all database servers will be from the same manufacturer (for example, all Oracle-only servers, or all DB2 UDB-only servers). If the database is not homogeneous, then what software will be used to exchange data between DBMS of different manufacturers (already existing or developed specifically as part of the project);
· whether parallel database servers (eg Oracle Parallel Server, DB2 UDB) will be used to achieve proper performance.
The design stage ends with the development of a technical design of the IS. During the implementation phase, the creation software operational documentation.
After the development of a single module of the system is completed, an autonomous test is performed, which has two main goals:
detection of module failures (hard failures);
Compliance of the module with the specification (the presence of all necessary functions, the absence of unnecessary functions).
After the autonomous test successfully passes, the module is included in the developed part of the system and the group of generated modules passes the link tests, which should track their mutual influence.
Next, a group of modules is tested for reliability, that is, they pass, firstly, tests of simulating system failures, and secondly, tests of the time between failures. The first group of tests shows how well the system recovers from software failures, hardware failures. The second group of tests determines the degree of system stability during normal operation and allows you to evaluate the system uptime. The stability test suite should include tests that simulate the peak load on the system.
Then the entire set of modules passes a system test - a test of internal acceptance of the product, showing the level of its quality. This includes functionality tests and system reliability tests.
The last test of the information system is acceptance testing. Such a test involves showing the information system to the customer and should contain a group of tests simulating real business processes to show that the implementation meets the customer's requirements.
1The 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, a set of initial indicators are divided into groups that characterize individual parties financial condition organizations. 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 not directly related to the financial condition of the organization participating in the competition.
Information system
structure
technique
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 Technology project management - M.: INFRA-M, 2012. - 144 p.
7. Shuremov E. Computer business analysis. // PC world. - 1998. - No. 1. - P. 80–83.
Acceptance efficiency management decisions for 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 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 the 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 the parameters that are priority for 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”. This module generates different scenarios analysis, definition additional rules and criteria that reflect the interests of the city and the administration, setting critical values of financial ratios.
"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 tools 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 any direction, for example, in the field of production food products 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 // Basic 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"
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 cycles feedback 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. Special attention is given 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.
Upon completion of the main stage 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, the external conditions for its functioning, the composition of people and works 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 the software, requirements for the DBMS (if the project is supposed to be implemented for several DBMS, then the requirements for each of them, or General requirements to an abstract DBMS and a list of recommended ones for this project DBMS that satisfy the specified conditions);
that will not be implemented within the framework of the project.
Made on this stage The work allows answering 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 diagrams life cycles entities. 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 individual. A fragment of the ER diagram for this type of relationship is shown in rice. 5.
Rice. 5. Arc
In this case, the attribute OWNER of the ACCOUNT entity has a special meaning for this entity - the entity is divided into types by categories: "for an individual" and "for 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 different subtypes have. It should be noted that the abuse of subtypes and supertypes is a fairly common mistake. 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 connection?
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?
