3.1 Defining an AIS life cycle model
A software product development life cycle model is understood as a structure that determines the sequence of execution and interrelationships of processes, actions and tasks performed throughout the software product development life cycle. The following software product development life cycle models are most widely used (Table 1. Brief characteristics AIS life cycle models): waterfall model, or waterfall (waterfall model); v-shaped model (v-shaped model); prototyping model (prototype model); rapid application development model, or RAD-model (RAD-rapid application development model); multi-pass model (incremental model); spiral model.
Table 1. Brief characteristics of each of the listed models
| Name | characteristics |
| Cascade model | Straightforward and easy to use. Constant strict control over the progress of work is necessary. Developed software is not available for modification |
| v-shaped model | Easy to use. Emphasis is placed on testing and comparing the results of the testing and design phases |
| Prototyping Model | A "fast" partial implementation of the system is created before the final requirements are drawn up. Provides feedback between users and developers in the process of project implementation. Used requirements are not complete |
| Rapid Application Development Model | Project teams are small (3…7 people) and are made up of highly qualified specialists. Reduced development cycle time (up to 3 months) and improved performance. Code reuse and development process automation |
| Multi-pass model | A working system is quickly created. Reduces the possibility of making changes during the development process. It is not possible to switch from the current implementation to new version during the construction of the current partial implementation |
| spiral model | Covers the waterfall model. Breaks the phases into smaller parts. Allows for flexible design. Analyzes and manages risks. Users get to know the software product at an earlier stage thanks to prototypes |
3.2 Cascade model
In the homogeneous information systems of the 1970s and 1980s, application software products were a single entity. To develop this type of software product, a cascade model, or “waterfall”, was used.
The cascade model of a software product is similar to the model of an automated control system (see Chapter 1, Fig. 1).
This process is, as a rule, iterative in nature: the results next stage often cause changes in design decisions made at earlier stages. Thus, there is a constant need to return to previous stages and clarify or revise previously made decisions. As a result, the actual development process takes on a different form (see Chapter 1, Figure 2)
3.3 V-model
This model (Fig. 5) was developed as a variation of the waterfall model, in which special attention is paid to the verification and validation of the software product. The model shows that product testing is discussed, designed, and planned early in the development life cycle.
From the waterfall model, the v-shaped model inherited a sequential structure, according to which each subsequent phase begins only after the successful completion of the previous phase.
This model is based on a systematic approach to the problem, for which four basic steps are defined: analysis, design, development and review. Analysis involves project planning and requirements. Design is divided into high-level and detailed (low-level). Development includes coding, review - different kinds testing.
The model clearly shows the relationship between the analytical phases and the design phases that precede coding and testing. Dashed arrows show that these phases should be considered in parallel.
The model includes the following phases:
Drafting of project requirements and planning - system requirements are determined and work planning is carried out;
Preparation of requirements for the product and their analysis - a complete specification of requirements for the software product is compiled;
High-level design - the structure is defined software, the relationship between its main components and the functions they implement;
Detailed design - the algorithm of operation of each component is determined;
Coding - the transformation of algorithms into finished software is performed;
Unit testing - each component or module of the software product is tested;
Integration testing - integration of the software product and its testing are carried out;
System testing - the operation of the software product is checked after it is placed in the hardware environment in accordance with the requirements specification;
Operation and maintenance - launching a software product into production. During this phase, the software product can be amended and upgraded.
Fig.5 V-shaped model
Advantages of the v-shaped model:
1) A great role is given to the verification and certification of the software product, starting from the early stages of its development, all actions are planned;
2) Attestation and verification of not only the software product itself, but also all received internal and external data are supposed;
3) The progress of the work can be easily tracked as the completion of each phase is a milestone.
In addition to these advantages, the model also has a number of disadvantages:
iterations between phases are not taken into account; it is impossible to make changes at different stages of the life cycle; requirements testing happens too late, so making changes affects the schedule.
It is expedient to use this model in the development of software products, the main requirement for which is high reliability.
The product and the creation of convenient cards for filling in the attributes of the database: the simplicity of creating links and their modernization. Chapter II. Development of a program to automate the activities of the taxi fleet 2.1 Analysis of customer requirements Program Automated workplace taxi dispatcher is developed according to the spiral model of the life cycle of automated information systems. At every stage of creation...
Systems. Main normative documents, regulating the process of creating any IS and IT project, are GOSTs and their complexes for the creation and documenting information technology, automated systems, software, organization and data processing, as well as the governing documents of the State Technical Commission of Russia on the development, manufacture and operation of software and ...
Topic 1.2 Life cycle AIS and AIS life cycle models
AIS life cycle -it is a continuous process from the moment a decision is made on the need to make a decision on the need for its creation until the full completion of its operation.
The life cycle of modern AIS is about 10 years, which significantly exceeds the obsolescence and physical obsolescence of technical and system software used in the implementation of AIS. Therefore, as a rule, during the life cycle of the system, its modernization is carried out, after which all the functions of the system should be performed with no less efficiency.
To achieve this throughout the life cycle of AIS is a rather difficult task for a number of objective and subjective reasons, as a result, the vast majority of AIS projects are implemented with violations of quality, deadlines or estimates; almost a third of projects cease to exist unfinished. According to the Standish Group in 1996, 84% of AIS projects were not completed on time, in 1998 this number dropped to 74%, after 2000 it does not fall below 50%. main reason This situation is that the level of technology for analyzing and designing systems, methods and project management tools does not correspond to the complexity of the systems being created, which is constantly increasing due to the complication and rapid change business.
It is known from world practice that the cost of maintaining AIS application software is at least 70% of its total cost throughout the life cycle, so it is extremely important to provide the necessary methods and means of support, including configuration management methods, even at the design stage.
The AIS design process is regulated by the following documentation (standards, methodologies, models):
GOST 34.601-90- a standard for the stages and stages of creating AIS, corresponding to the cascade model of the software life cycle (discussed below). A description of the content of work at each stage is given;
180/1EC 12207:1995- standard for processes and organization of the life cycle; applies to all types of custom software; does not contain a description of phases, stages and steps;
Custom Development Method(Oracle methodology) - technological material on the development of applied AIS, detailed to the level of blanks of project documents based on the use of Oracle. It is used for the classical model of the life cycle (all works, tasks and stages are provided), as well as for "fast development" (Fast Track) or "lightweight approach" technologies, recommended for small projects.
Rational Unified Process(methodology RUP) - technological material for the implementation of an iterative development model, which includes four phases (development cycle): initiation, research, construction and implementation. Each phase is divided into stages (iterations), the results of which are versions for internal or external use. Each cycle ends with the generation of the next version of the system. If after that the work on the project does not stop, then the resulting product continues to develop and goes through the same phases again. The essence of work within the framework of the RUP methodology is the creation and maintenance of models based on UML;
Microsoft Solution Framework(methodology MSF) - technological material for the implementation of an iterative development model, similar to RUP includes four phases: analysis, design, development, stabilization; involves the use of object-oriented modeling. MSF is more focused on business application development than RUP;
Extreme Programming (XP)- extreme programming (the newest among the considered methodologies); was formed in 1996. The basis of the methodology is teamwork, effective communication between the customer and the contractor throughout the entire project; the development of AIS is carried out using successively refined prototypes.
The ISO/IEC 12207 standard in the life cycle framework defines the processes that are performed when creating AIS software. These processes are divided into three groups:
main(acquisition, supply, development, operation and maintenance);
auxiliary(documentation, configuration management, quality assurance, verification, validation, evaluation, auditing and problem solving);
organizational(project management, creation of project infrastructure, definition, evaluation and improvement of the life cycle itself, training).
Among main processes life cycle the most important are development, operation and accompaniment. Each process is characterized by certain tasks and methods for solving them, the initial data obtained at the previous stage, and the results.
Development AIS includes all work on the creation of software and its components in accordance with the specified requirements. This process also includes:
Preparation of design and operational documentation;
Preparation of materials necessary for testing the developed software products;
Development of materials necessary for staff training.
Typically, the components of the development process are strategic planning, analysis, design and implementation (programming).
To process exploitation relate:
Configuring the database and user workstations;
Providing users with operational documentation;
Training.
Major operational activities include:
Direct operation;
Localization of problems and elimination of their causes;
Software modification;
Preparation of proposals for improving the system;
Development and modernization of the system.
Professional, competent escort- necessary condition solving tasks performed by AIS. Services technical support play a very prominent role in the life of any AIS. Errors at this stage can lead to obvious or hidden financial losses comparable to the cost of the system itself.
To preliminary actions in organizing Maintenance AIS include:
Identification of the most critical nodes of the system and determination of the criticality of downtime for them (this will allow us to identify the most critical components of the AIS and optimize the allocation of resources for maintenance);
Definition of maintenance tasks and their division into internal, solved by the forces of the service department, and external, solved by specialized service organizations (thus, the range of functions performed is clearly limited and responsibility is distributed);
Conducting an analysis of the available internal and external resources necessary for the organization of maintenance within the framework of the described tasks and the division of competencies (the main criteria for analysis: the availability of a guarantee for equipment, the state of the repair fund, the qualifications of personnel);
Preparation of a plan for the organization of maintenance with the definition of the stages of the actions to be performed, the timing of their execution, the costs at the stages, the responsibility of the performers.
Ensuring high-quality maintenance of the loop system requires the involvement of highly qualified specialists who are able to solve not only daily administrative tasks, but also quickly restore the system's performance in case of failures and accidents.
Among support processes one of the main ones is configuration management, which supports the main processes of the AIS life cycle, primarily the development and maintenance processes.
The development of complex AIS involves the independent development of system components, which leads to the emergence of many options and implementation versions of both individual components and the system as a whole. Thus, there is a problem of ensuring the preservation of a single structure during the development and modernization of the AIS. Configuration management allows you to organize, systematically take into account and control changes to various components of the AIS at all stages of its life cycle.
Organizational processes are of great importance, since modern AIS are large complexes, in the creation and maintenance of which many people of different specialties are employed.
| Process (process executor) | Actions" | Entrance | Result |
| Acquisition (customer) | Initiation. Preparation of application proposals. Contract preparation. Supplier activity control. AIS acceptance | The decision to start work on the implementation of AIS. The results of a survey of the customer's activities. Results of the analysis of the AIS/tender market. Delivery/development plan. Comprehensive AIS test | Feasibility study for the introduction of AIS. Terms of Reference for AIS. Supply/development contract. Acts of acceptance of stages of work. Acceptance test report |
| Delivery (AIS developer) | Initiation. Response to bids. Contract preparation. Execution planning. Supply of AIS | Terms of Reference for AIS. The decision of the management to participate in the development. tender results. Terms of Reference for AIS. Project management plan. Developed AIS and documentation | The decision to participate in the development. Commercial offers/bid. Supply/development contract. Project management plan. Implementation/adjustment. Acceptance test report |
| Development (AIS developer) | Training. Analysis of requirements for AIS. AIS architecture design. Development of software requirements. Software architecture design. Detailed software design. Software coding and testing. Software integration and software qualification testing. IS integration and AIS qualification testing | Terms of Reference for AIS. Terms of reference for AIS, model of life cycle. Terms of Reference for AIS. AIS subsystems. Requirements specifications for software components. Software architecture. Materials for detailed software design. Software integration plan, tests. IS architecture, software, IS documentation, tests | Used life cycle model, development standards. Work plan. The composition of subsystems, equipment components. Requirements specifications for software components. The composition of the software components, interfaces with the database, software integration plan. Database design, interface specifications between software components, test requirements. Tests of software modules, acts of autonomous testing. Assessment of compliance of the software complex with the requirements of the TOR. Assessment of compliance of software, database, technical complex and documentation set with the requirements of the TOR |
Project management is related to the issues of planning and organizing work, creating teams of developers, monitoring the timing and quality of work. Technical and organizational support of the project includes:
Choice of methods and tools for project implementation;
Definition of methods for describing the state of the development process;
Development of methods and means of testing the created software;
Training.
Design quality assurance is related to the problems of verification, verification and testing of AIS components.
Verification - the process of determining whether the current state of development achieved at a given stage meets the requirements of that stage.
Examination- the process of determining the conformity of development parameters with the initial requirements. Verification overlaps somewhat with testing, which is carried out to determine the differences between actual and expected results, as well as to assess the conformity of the AIS performance with the original requirements.
In 2002 A standard for life cycle processes for automated systems (ISO/IEC 15288 System Life cycle processes) has been published. Experts from various areas activities; practical experience in creating systems in government, commercial, military and academic organizations was taken into account. According to the ISO/IEC 15288 series, the following process groups are included in the LC structure.
1. Contractual processes:
Acquisition (in-house solutions or external provider solutions);
Delivery (in-house solutions or solutions from an external supplier).
2. Enterprise processes:
Control environment enterprises;
Investment management; in the management of the life cycle of IP;
Resource management;
Quality control.
3. Design processes:
Project planning;
Project evaluation;
Project control;
Management of risks;
Configuration management;
Information flow management;
Making decisions.
4. Technical processes:
Definition of requirements;
Requirements analysis;
Architecture development;
implementation;
Integration;
Verification;
Transition;
Certification;
Exploitation;
Escort;
Disposal.
5. Special processes:
Definition and establishment of interrelations proceeding from tasks and the purposes.
In table. 1.4 shows the list of stages and the main results by the time they are completed in accordance with the specified standard.
In the 1970s IBM has proposed the Business System Planning (BSP) methodology or organizational planning methodology.
A method of structuring information using intersection matrices of business processes, functional divisions of data processing systems (IS), information objects, documents and databases, proposals in BSP, their sequence (get top management support, define enterprise processes, define processes, data classes, bring interviews, process and organize interview data) can be found in almost all formal methods, as well as in projects implemented in practice.
Table 1.4.AIS creation stages (ISO/IEC 15288)
According to published data, each stage of AIS development requires a certain amount of time. Most of the time (45-50%) is spent on coding, complex and offline testing(Fig. 14). On average, the development of AIS takes one third of the entire life cycle of the system (Figure 1.5).
Fig.1.4. Distribution of time in the development of AIS
Description of the presentation Stages of creating AIS Models of the life cycle of AIS by slides
The life cycle of AIS is a set of stages and stages that AIS goes through in its development from the moment a decision is made to create a system to the moment it ceases to function.
Life cycle stages 1 Planning and analysis (pre-project stage) - determining what the system should do. Registration of a feasibility study (feasibility study) and terms of reference (TOR).
2 Design (technical and logical design) – defining how the system will function (specification* of subsystems, functional components and how they interact). Decor technical project. * Specification - an accurate, complete, clearly articulated description of the requirements for a given task.
3. Implementation (detailed design, programming) - Creation of functional components and separate subsystems, connection of subsystems into a single whole. Filling the database. Creation of instructions for personnel. Making a working draft
4 Implementation (testing, trial operation) - installation and commissioning of the system, debugging of subsystems, personnel training. Registration of the act of acceptance tests.
Remarks 1. Stages 2 and 3 can be combined into one: techno-detailed design or system synthesis. 2. At each stage of the life cycle, a certain set of technical solutions and related documents are used
3. For each stage, the documents and decisions taken at the previous stage are the initial ones. 4. Life cycle models determine the order of execution of stages in the process of creating a system and the criteria for moving from stage to stage.
The life cycle model is a model for the creation and use of AIS, which reflects the various states of the system from the moment of its inception until the moment it is completely out of use.
The main models of the life cycle Cascade - involves the transition to the next stage after the completion of the previous one. This model is used in the construction of AIS for which all requirements are precisely and completely formulated from the very beginning. Disadvantages: rigid scheme - the impossibility of returning to the previous stages and the use for complex systems.
Stepwise iterative model feedback between cycles. The advantage is that inter-stage adjustments provide more flexibility and less effort. The disadvantage is that the lifetime of each of the stages can stretch for the entire period of the system creation. Difficulties and disadvantages of the spiral model of the life cycle The main problem is the definition of the transition to the next stage: to solve it, time limits are introduced for each of the stages. The transition is carried out in accordance with the plan drawn up on the basis of statistical data from previous projects and the experience of developers. Disadvantages: Mistakes made during the analysis and design phases can lead to problems in the following phases and the failure of the entire project.
The AIS user role is created to meet the information needs of a particular user. He is directly involved in its work. .
The user participates in the formulation of the problem and conducts trial operation, during which he can detect shortcomings in the formulation, correct the input and output information, forms for issuing results and paperwork.
User participation in the creation of AIS provides prompt and high-quality problem solving, reduces the time for the introduction of new technologies
Introduction
1. Architecture of automated information systems and problems of its improvement 13
1.1. Models of architecture and main components of AIS 13
1.2. AIS development problems 47
1.3. Platforms for the implementation of the new architecture of AIS UP 53
1.4. Chapter 1 Conclusions 57
2. AIS UE architecture model 58
2.1. Basic requirements for AIS UP 59
2.2. Architecture AIS UP 66
2.3. AIS UP 89 components
2.4. Chapter 2 Conclusions 102
3. Methods for the practical implementation of AIS UE 104
3.1. AIS UP 104 development tools
3.2. Experience in practical implementation of the AIS UP 111 model
3.3. Chapter 3 Conclusions 123
4. Conclusion 125
5. Terminology and abbreviations 128
6. Literature
Introduction to work
Activity modern enterprises associated with the movement of interdependent and volumetric flows of material, financial, labor and information resources. Managing the processes of the production and commercial cycle in a dynamically changing political and economic environment requires prompt decision-making in short time. The solution to this problem in modern conditions is impossible without the use of automated processing of technical and economic information.
Over the past 40 years, automated information technologies (IT) have been actively used to solve the problems of accounting, planning and analysis economic activity enterprises of various forms of ownership, industry affiliation, organizational structure and scale of activity. During this time, a lot of practical experience has been accumulated in creating automated information systems for enterprise management (AIS UE), management methodologies have been developed and received universal recognition, the application of which is impossible outside the computer environment. It can be said with full responsibility that AIS UE has become an integral part of the business infrastructure. Theoretical and practical problems of automating economic processes are deeply studied in the works of Glushkov V.M., Volkov S.I., Isakov V.I., Ostrovsky O.M., Podolsky V.I., Ratmirov Yu.A., Romanov A.N. , Hotyashova E.N., Brady R., Zachman J., Cook M., Finkelstein K., Hammer M. and other authors. The approaches proposed by them became the basis for the use of computer technology in enterprises in solving problems of accounting, planning and analysis of financial and economic activities. However
the models they proposed did not take into account the realities of the information society economy and the current level of IT development.
The development of means of communication contributes to ever closer interaction between producers and consumers, suppliers and buyers, increases competition in the market, expands the boundaries of local markets to national and transnational ones, and speeds up the time of economic transactions and financial transactions. The introduction of global computer networks in economic processes has led to the emergence of new concepts: the economy of the information society, e-business(e-business), electronic commerce (e-commerce), electronic trading floor(e-marketplace);
The existing concepts of AIS UE organization are based on a functional approach to the distribution of tasks between its subsystems. However, AIS, built as a complex of subsystems focused on individual management functions, does not best meet the requirement of the continuity of end-to-end business processes of an enterprise. Therefore, in recent years, an approach has become increasingly popular, in which business processes are put at the forefront, and not individual functions of the management system services that perform them. This requires the development of a new concept of AIS UE architecture. At the same time, it is obvious that the transition to a new AIS UE architecture cannot be carried out at once, since over the years, enterprises and organizations have put into operation a large number of software tools that implement the solution of important management tasks, the use of which cannot be abandoned immediately. Unfortunately, most of them are focused on autonomous functioning, which significantly complicates the complex integration of information flows. Many existing software products that provide support for solving new problems of enterprise management that have arisen in the context of the globalization of the economy are also developed without sufficient elaboration of interfaces for interaction with software complexes, realizing the solution of related problems. Under these conditions, the task of synthesizing integrated enterprise management systems by integrating off-the-shelf third-party components, custom solutions, and in-house developments is of particular importance.
In the publications of scientists and practitioners, the idea of implementing standards for system integration of software tools supplied by various manufacturers has long been discussed. The progress of system tools has led to the emergence of object-oriented and component software development technologies that allow you to build large-scale systems from ready-made blocks. Leading suppliers of hardware and system software (Intel, Microsoft, Sun, Oracle, IBM, etc.), communication tools (Cisco, Nortel, Ericsson, Motorola), applied solutions (SAP, PeopleSoft, Siebel, etc.), authoritative state, international, commercial and non-profit organizations and associations (ISO, IEEE, ASCII, APICS, RosStandard, etc.) have by now developed and are actively implementing in practice technologies for integrating hardware and software that allow creating open systems based on standards and protocols for data exchange and interaction of components in a heterogeneous environment in real time mode.
However, these proposals provide only a system-wide platform, which requires significant refinement in relation to a specific subject area. In the context of the practical implementation of AIS UE, mechanisms for designing and developing information systems (IS) using component multi-link architectures based on standards and protocols open systems not worked out enough.
In this regard, the problem of developing a theoretical platform and developing practical advice aimed at building AIS UE, providing comprehensive automation of all information procedures for managing enterprises and organizations.
The need to develop a holistic approach to solving the issues of system integration of AIS PM and end-to-end automation of microeconomic processes based on modern IT determined the choice of the topic and direction of this study.
The aim of the study is to develop a model of the AIS UE architecture that provides comprehensive automation and information support for end-to-end business processes, and to substantiate the choice of tools for its system integration from the standpoint of modern information technologies.
Based on the intended goal, the following scientific and practical tasks were set and solved:
To analyze and generalize existing approaches to the design, development and implementation of AIS UP software;
Classify the types of software used in the practice of enterprise management;
Explore existing technologies and standards that provide integration of heterogeneous software tools;
To identify problems that arise during the integration of software tools used in AIS UE;
To systematize the requirements set by enterprises for AIS UE software to provide information support for end-to-end economic processes;
Develop a model of AIS UE architecture and highlight its main components;
Develop the principles of interaction and data exchange of AIS UE components;
The subject of the research is the methods and tools for the development of economic information systems.
The object of the study is enterprise management IS.
The research methodology is based on specific applications of the methodology of scientific knowledge in the applied areas of informatics and mathematics.
The goals and objectives of the study were formulated in accordance with the main direction of work on the further development and improvement mathematical methods and computer technology used in economic subject areas.
Along with a general scientific approach based on systems theory, the dissertation summarizes the experience of developing, implementing and operating software tools of domestic and foreign manufacturers, methods
implementation of international open standards for building information systems. On this basis, a set of methodological and practical recommendations are proposed that have been tested at Russian and foreign enterprises.
The paper uses the theoretical provisions of the works of domestic and foreign authors in the field of:
Automated processing of economic information and modeling of economic processes;
Methodologies for planning and operational management of production and inventories;
Reengineering and computer design of business processes;
Modern standards in information technology.
The study analyzed and used developments made by research teams and individual scientists at the Financial Academy under the Government of the Russian Federation, the All-Russian Correspondence Institute of Finance and Economics, Moscow State University of Economics, Statistics and Informatics, St. Petersburg University of Economics and Finance. Voznesensky, Research Financial Institute and other organizations.
The information base of the study consisted of software products of Russian and foreign manufacturers, publications in economic and computer publications, research by international research groups Gartner Group, Aberdeen, IDC, MetaGroup, DataQuest, etc. teaching materials leading domestic and international consulting and audit companies, research results of the Association of Software Developers in the field of economics,
research of the software market in Russia and the CIS countries TSIES "Business-Programs-Service" .
The scientific novelty of the dissertation lies in the development of an AIS UE architecture model focused on the integrated automation of end-to-end business processes, and proposals for its implementation through system integration of heterogeneous software tools in a distributed heterogeneous network environment based on object and component technologies.
Scientific novelty contains the following results obtained in the dissertation:
Definition and classification of requirements for the functionality of the software for organizational and economic management of enterprises;
AIS UE architecture model focused on integrated automation of end-to-end business processes;
Principles of integration of software tools for solving problems of the functional services of an enterprise with basic software for managing business processes, data exchange and document management;
Proposals for organizing a single information space of the enterprise, available to employees and partners of the enterprise through the corporate web portal;
Implementation proposals unified system formation and classification of reporting using analytical tools;
Principles for implementing the interaction of AIS UE subsystems based on object-oriented and component technologies and the interaction of software components in a distributed network
environment in accordance with industry standards and Internet protocols;
A mechanism for implementing the adaptive properties of the architecture model of the AIS PM software in accordance with the requirements of a particular enterprise, based on the ability to configure the basic subsystems to existing and projected work processes.
The practical significance of the dissertation work is that the implementation of the proposed proposals allows you to create AIS UE, providing effective support for information procedures for managing the activities of an enterprise in the context of a globalized economy and the formation of an information society.
The proposed AIS UE architecture model and recommendations for its application have sufficient flexibility and versatility, which ensures their applicability in building IS management of enterprises of various forms of ownership, industry specifics and scale of activity.
Independent practical value have:
Proposals for the selection and application of standards, protocols and other mechanisms used in the system integration of AIS UE;
Offers for integrated automation end-to-end business processes and workflow;
Proposals for the creation of a single information space of the enterprise using the mechanism of web portals;
Proposals for adapting the spiral-iterative approach in the development and implementation of AIS UP software.
The practical significance of the work was evaluated in specific projects for the implementation of the proposed problem-oriented model of an enterprise automation system:
Integrated enterprise management system "Flagman" of the company "Infosoft",
eRelationship customer relationship management systems of Pivotal Software Corporation (Canada),
Monarch ES corporate reporting systems of DataWatch company (USA),
The project of integration of information systems of Sovintel and Tele Ross companies.
The Vest-MetaTechnology training center uses materials prepared by the author based on the approach proposed in the course of this study when conducting courses on the development of enterprise management information systems (see http://www.vest.msk.ru).
Dissertation research materials are used in research and practical activities executive bodies of the Association of Software Developers in Economics (AREP) and its members.
The main provisions of the work were reported and discussed at:
Conference "IBM Solutions in the field of business integration for telecommunications companies", representative office of IBM in Eastern Europe (Moscow, June 18, 2002);
Symposium "Call Center CRM Solutions 2002/Call Centers and Customer Relationship Management" (Moscow, March 2002);
Conferences of developers of information systems based on the tools of the corporation Centura Software Corp. (Berlin, Germany, November 17-19, 1999);
Conference "InfoCity: practice and problems of informatization of cities" (Moscow, October 1999);
Scientific and practical conferences of the company "Infosoft" (Moscow, 1995-1999);
Conferences of specialists in the field of ACS and CIS "Corporate Systems" (Moscow, April 1998 and April 28-30, 1997, organizers: SoftService company and representative offices of Oracle, Informix, Sybase, Borland and Centura);
3rd annual conference "Corporate databases 98" (Moscow, March 31-April 3, 1998 and March 26-29, 1996, organized by the Center for Information Technologies with the participation of the Open Systems Publishing House);
Conference "Tekhnikom-97" (Moscow, November 24-26, 1997, organizers: SoftService, Russian Association Oracle Users, Representative Offices of Microsoft, Borland, Computer Associates, Lucent Software).
AIS development problems
The introduction of information technologies into the economy, the penetration of computer and communication tools into enterprise management at all levels, the growing interest in the interaction of companies via the Internet require conceptual changes in approaches to building AIS UE. This concerns not only purely technological problems of creating and operating IS, but also approaches to business management in the information society economy.
AIS UE should meet the needs for automation and informatization throughout the organization, which sets the software developers the task of: developing a platform that can support the work of a large number of users; support for communication tools and industry standards for data exchange and component interaction protocols; integration of existing developments into a single system.
Integration of heterogeneous applications within a single AIS should provide support for: end-to-end business processes; single user interface (portal); common information space.
In our opinion, the essence of the problems posed is not so much in the technical aspects of implementation, but in the need to use a fundamentally new model of AIS UE architecture.
Let us summarize the pros and cons of various IS architecture options in terms of the possibilities of building an integrated solution.
The centralization of data processing places high demands on servers. With an increase in the number of concurrent users (which is inevitable when automating processes throughout the enterprise), the loads become excessive for the hardware platform and the software used. Using various hardware solutions (clustering, multiprocessing and other forms of combining computing resources), as well as distributed processing using transaction monitors, application servers and powerful industrial DBMS, you can create truly scalable solutions, offloading central nodes not only by increasing the power of hardware, but also due to the appropriate construction of the software components of the system.
However, even if the central database server is capable of providing the required performance, with such an IS construction, problems inevitably arise in maintaining a single structure of the general database if individual IS software components are developed different companies or even development teams within the same organization. Installing a common database with access from programs for solving various applied problems makes it possible to provide a common information space, the technologies listed above allow a large number of users to access the database, but this does not guarantee correct work with shared data. There remains the problem of logical data integrity. When using programs from different manufacturers, it becomes inevitable to separate data into subsystems, possibly by denormalizing them and creating redundant structures. The common-base architecture is schematically shown in the following figure (Figure 1-14). As follows from the above diagram, the modules do not interact, that is, there is no call from one module to another in real time, there is no operational support for an end-to-end process. The data is stored in the database, from which it is available to other modules that need to contain the functions of tracking changes in it, and the relevance of the data depends on the frequency of checking for updates. An example of an end-to-end process would be an invoicing by an employee of the sales department. If he uses a CRM system for this, the generated invoice must be processed in parallel with the statement in the logistics module of the ERP system to reserve the goods, and immediately after that - in the financial module to increase the buyer's debt. To do this, the relevant modules must check for the existence of a new account. If this is not done in a timely manner, an invoice may be issued for the item actually reserved.
In order for different modules to work with a common database structure, they must be initially developed with a view to a specific data structure or use an agreed metadata mechanism (repository).
When using a different architecture, when heterogeneous databases are maintained on different computers (and, possibly, on different networks) and used by autonomous modules (Figure 1-15), maintaining the logical integrity of the data is an even more time-consuming task. In this case, it is necessary to regulate and implement data replication (synchronization), unification of directories, coding and classification rules, develop or implement the replication mechanism itself. All this requires organizational measures to synchronize the database. There remains the problem of automatic continuation of the process (an example with an invoice).
Platforms for the implementation of the new AIS UE architecture
By the beginning of the 21st century, the following solutions were developed and mastered at the industrial level in the IT industry, which ensured the widespread introduction of IT into economic processes:
personal computing tool, consisting in the fact that in many types of work the need for intermediaries between the task statement and its executor has disappeared, that is, employees of the functional services of the enterprise are able to perform those within their competence information procedures using computers without the involvement or with minimal support of accompanying technical personnel;
means of automated support for the coordinated joint work of a group ("team") of employees on one project, document, task, etc.;
electronic communications mechanism, which in many cases made it possible to eliminate the need to transfer paper documents, to minimize the need for meetings, which is especially important when the participants in a particular business process are geographically remote.
Thanks to these solutions, it became possible to automate most of the work processes occurring both within the enterprise in its financial, economic, production and commercial activities, and related to external functions. The combination of software and hardware tools that automate various functions and workplaces makes it possible to link technological (based on equipment and technical devices) and work processes (with the participation of employees from all departments of enterprises) into end-to-end business processes. Thus, there is a fundamental possibility of solving the problem of isolation of points of origin of data from the centers of their storage and processing, separation of workplaces from each other.
Solving the problem of integrating AIS modules and choosing a centralized or decentralized approach to organizing their interaction is also possible thanks to the latest developments of leading manufacturers of system software: operating systems, web servers, application servers, DBMS and middleware platforms. Application integration is made possible through the use of object-oriented development technology and component-based multi-tier architecture. The key principle here is the concept of programming interfaces and the rules for changing and extending them (IDL).
To work in a distributed heterogeneous environment, such as the Internet, web services specifications are being actively developed, each of which can implement one or more business procedures or functions (business procedures, functions). OASIS, BPMI, and IBM, Microsoft, and BEA have published the BPEL4WS (Business Process Execution Language for Web Services), XLANG and WSFL (Web Services Flow Language) workflow regulation specifications, and the WfML coalition - XPDL (XML Process Definition Language).
The trend is to combine components with open web service interfaces into subsystems that execute logically complete business process cycles. In this case, the components can be located on various application servers distributed over the network and work with one or more databases. By varying the number and relationships of components, the number and location of network servers, the possibility of replacing components or moving them around the network without loss of compatibility, it is possible to build an AIS that maintains a balance of centralization and decentralization in enterprise management.
There are no technical obstacles to the implementation of such an architecture. Modern industrial application servers (for example, MTS / COM + / .Net, ONE or J2EE / EJB) allow you to build multi-tier systems, provide a common platform for accessing various web services, provide transactional integrity of operations, load balancing with competitive access of tens of thousands of users in real time, as well as guarantee fault tolerance and recovery after failures.
An important achievement of the IT industry are the standards that have become widespread and recognized by leading software manufacturers: component interaction protocols (COM / DCOM, CORBA, Java RMI) and data exchange formats (EDI, XML,).
The EDI standard and its industry variants (EDIFACT, XI2, HIPAA, etc.) have been used in the financial and industrial sectors of North America and Europe since the mid-1970s and dominate today throughout the world. With the growing popularity of XML on the Internet, EDI was translated into XML.
On the basis of XML (DTD and XDR), data has been developed, structured and formatted in various economic areas in the form of so-called subject dictionaries or document types, for example, WIDL, OFX, FpML, IFX, XBRL, CRML and numerous others in the West, as well as CommerceML.ru and XML Partnership/ARB in Russia. The American Society for Production and Inventory Management APICS, which certifies ERP/MRP class systems, publishes specifications of economic entities in XML format, such as the structure and format of customer or invoice data. Self-documenting XML provides an unambiguous understanding of data by both humans and programs.
AIS UE architecture
To build a model of AIS UE architecture, we will consider an enterprise as a set of labor, financial, material and information resources involved in business processes to achieve the business goals of an enterprise. Here, the term business goals refers to the strategic long-term goals set by the owners and top managers, as well as the current goals assigned by top and middle managers. A business process or business process is a sequence of actions of employees, operations at workplaces, as well as functions performed by software and technical means in automatic mode. Let's call each action or their sequence a stage of the process. Synonyms for actions can also be operations, procedures. If a stage requires the actions of an employee (a role group, a representative or head of a department, as well as a person holding an official position), then it is also called a task, and the employee is called an executor. The sequence of actions in a business process may be ambiguous, that is, the description of the process in the form of a directed graph may include branching with conditions for transition from one stage to another. Typical chains of stages can be divided into sub-processes. The movement of tasks by specified stages of the process is called a route. If the process cannot be described due to arbitrary transitions between stages, the decision about which is made by the performer during the execution of the task at the current stage, then this case is called free routing.
AIS PM should allow to formally describe business processes in a graphical form in the form of a directed graph (digraph), the vertices of which are the stages, and the edges are the transitions between the stages. In a particular case, the business process graph looks like a network graph, where the vertices represent jobs with their duration, and oriented edges (arrows) show the sequence of jobs. In accordance with the description of the process, called the process map, AIS UE must manage resources (or, more precisely, help the managers of the enterprise manage them), assign tasks and their executors, and also call (activate) software and hardware to run automated procedures.
The parameters of the scale of the enterprise affect the organization of management at a particular enterprise, which is reflected in the requirements for AIS UE. On the other hand, AIS UE affects the scale of the enterprise, for example, contributing to business growth. Changing one of the parameters entails updating the AIS in the same way as the introduction of AIS can change the organization of management.
The purpose of focusing on business processes when building AIS UE is to find a common platform on the basis of which it will be possible to adequately modify the AIS without requiring a complete reorganization of the system. This platform is the modeling of business processes by process management software.
As the core of AIS PM, it is necessary to develop a system that combines several functions discussed in the review of process management systems (paragraphs "1.1.7 Document management systems" on page 31 and "1.1.8 Process management systems" on page 34). Among them: Workflow - a subsystem for managing work and technological processes that provides predefined and free routing of tasks between performers; Docflow - a subsystem for managing document flow and routing documents with tracking their states; Groupware - a subsystem for supporting the functions of operational assignment of tasks and free routing (ad hoc) of tasks between members of a group of performers; Dataflow - routing data, data packets, messages between applications.
In contrast to the accepted practice of autonomous use of systems of this kind, we here assume the presence of a common process map, a common module for processing process stages, a common mechanism for assigning executors and routing tasks and data.
Thus, technological data generated by technical devices, factual data entered into IS by users at workplaces (including primary documents), as well as data generated by software applications, will be entered into AIS UE and available to consumers of information in real time. time.
Schematically, the life cycle of data processing in AIS UE is presented in the following figure (Figure 2-2). Data entered manually or received from software components is formalized as a document, which is further processed by the workflow module in accordance with the process map. Along the processing route (if the system setup requires it), the document management subsystem calls the modules of functional subsystems for processing financial, business and other types of transactions. As a result, credentials are stored in structured databases. In turn, the documents themselves are stored in a storage or unstructured data base. All these databases must be available to the analytical modules of the reporting subsystem to generate the necessary reports.
Experience in practical implementation of the AIS UE model
From 1995 to 1999, under the guidance of the author of the thesis, the Flagman enterprise management system of the Infosoft company was developed, which is currently implemented in more than one hundred large and medium-sized industrial, construction, commercial, agricultural enterprises and budget organizations Russia and CIS countries. The system continues to develop on the basis of the kernel developed by the author, and by 2002 the "Flagship" includes more than ten main subsystems, shown in the following figure (Figure 3-2):
The basis of the "Flagman" system is the basic module "Document Management", which is responsible for the input, processing, routing and printing of all primary documents. Other basic modules are "Administration" and "Tools", common to all functional modules. They allow you to configure role groups and access rights, workstations up to menu items, document layouts and report templates.
The advantages of the implemented model were a single input of primary documents, generation accounts in functional subsystems based on these documents, unification of work with primary documents.
The rapid development of subsystems and the lack of standardization of their interaction has led to the fact that the integration was carried out around a central database and common tables. If we do not take into account the two-tier architecture, the choice of which was determined by the level of development of development tools in 1995, then the cross-dependency of modules became the main problem for the development of the system. Its first implementations revealed the insufficiency of workflow automation functions by document routing alone and raised the question of the need to implement a process management module (workflow).
If we consider the implementation in more detail, then the document management module is a library of objects included in all subsystems, and also compiled as a standalone module. The library includes tools for setting up types and variants of documents, the composition of fields, input and editing forms, a list of states, possible combinations of transitions from state to state, a list of operations linked to functional modules, templates and forms for printing, as well as rules for the formation of registers and journals of documents .
Operations with documents change their state and also call the functions of application subsystems. The list of functions is embedded in each subsystem and is specific to it. For accompanying programmers involved in setting up the system, function parameters and the ability to bind document fields to them using formulas are available. This allows you to automate most financial transactions, as well as logistics functions, personnel records and payroll, but full implementation still requires a scripting language.
The system has a built-in report generator common to all subsystems. Since the system is based on the principle of integration around a central database, the generator has access to all data, regardless of whether they belong to modules. Reports are classified into hierarchical structure, each of the report layouts contains a template for preview and printing, and SQL queries for generating the resulting data set. The generated reports can be further processed as documents.
It should also be noted that the Flagship system implements a unified appearance subsystems. The general administration module for user interface elements, AWP functions, including menus and toolbars, allows you to customize the appearance in a uniform way.
At the moment, the development of IT requires updating the platform of the Flagman system. First of all, it is necessary to transfer it to a three-tier architecture and develop the document management module to a fully functional process management system. It is also necessary to develop mechanisms for integrating external applications, since the system has only the means of importing and exporting data.
Nevertheless, numerous examples of the successful implementation and commercial operation of the Flagman system, the growth in the number of its sales in 2001-2002 testify to economic efficiency solutions for automation of enterprises of various fields of activity, industries and scale.
In February 1999, the Flagman system of the Infosoft company, created under the guidance of the author, was recognized as the best Russian development based on the Centura Team Developer toolkit by the Centura Software Corp. (USA) and the company "Interface" (Russia). In 1999, 2000 and 2001 CIS "Flagman" was certified as an enterprise-wide information system by the experts of the jury of the "Business-Soft" competition, held by the Association of Software Developers in the Field of Economics (AREP), TSIES "Business Programs-Service", the journal "Accounting" and "Financial newspaper ".
Canonical AIS Design
Development and design AIS begins with the creation of a conceptual model for using the system. First of all, the feasibility of creating a system, its specific functions and tasks to be automated should be determined. An assessment should be made not only of the goals, but also of the possibilities of creating a system. Further, the analysis of requirements for AIS, detailed design, the relationship of stages, programming and testing, minimization of losses during the transition from one level of information presentation to another, integration into the existing system, implementation and support are carried out.
There are three classes of design methodologies AIS:
· conceptual modeling of the subject area;
Identification of requirements and specification of the information system through its prototyping;
· system architecture of software tools supported by CASE-technology tools (CASE - Computer Aided Software Engineering - technology for creating and maintaining software for various systems).
The stage of creating an automated system - part of the NPP creation process, established by regulatory documents and ending with the release of documentation for the NPP, which should contain a system model at the level of this stage, the manufacture of non-serial components or the acceptance of the NPP into operation.
Each stage is singled out for reasons of rational planning and organization of work and must necessarily end with a certain result. The content of the documentation at each stage is determined by the composition and specifics of the work.
GOST 34.601-90 defines eight stages for creating automated systems:
- Formation of requirements for AS.
- Development of the AS concept.
- Technical task.
- Preliminary design.
- Technical project.
- Working documentation.
- Commissioning.
- AC support.
Stages 1, 2, 3 refer to the first period, stages 4, 5, 6 - to the second period, stages 7, 8 - to the third.
In the pre-project period, a feasibility study (FS) is developed and technical task(TOR) for system design. During this period, at the stage of formation of requirements for the NPP, three stages of work are carried out:
- examination of the object of the subject area and justification of the need to create a system;
- formation of user requirements for the system;
- drawing up a report on the work performed and an application for the development of the system.
- study of the object;
- carrying out research work;
- selection of a variant of the system concept from several developed ones;
- preparation of a report on the work performed.
Terms of Reference (TOR) - this is a list of the main operational, technological, economic and other requirements that the designed object must satisfy at all stages of its existence. After the approval of the TOR, the second period of the creation of the NPP begins - the period of system design.
Design - the process of a reasonable choice of system characteristics, the formation of logical-mathematical and economic-mathematical models, the development of documentation.
At the stage of creating a draft design, at the 1st stage, preliminary design solutions for the system and its parts are developed, at the 2nd stage, the documentation for the NPP and its parts.
At the 5th stage, when creating a technical project, development is carried out in four stages:
- design solutions for the system and its parts;
- documentation for the NPP and its parts;
- documentation for the supply of products for the acquisition of nuclear power plants and technical specifications for their development;
- tasks n# design in adjacent parts of the project of the automation object.
At the 7th stage, the system is put into operation in eight stages:
- preparation of the automation object for the input of the AU;
- staff training;
- completing the AU with software, hardware, information tools and products;
- construction and installation works;
- commissioning works;
- preliminary tests;
- trial operation;
- acceptance tests.
In order to improve the management of the design process, each stage is detailed, that is, it is divided into stages.
The stage of creating an automated system is part of the stage of creating the AS, determined by the nature of the work, its result or the specialization of the performers.
Modern system design methodologies should provide a description of automation objects, a description of the functionality of the AIS, a project specification that guarantees the achievement of the specified system characteristics, a detailed plan for creating a system with an assessment of the development time, and a description of the implementation of a particular system.
AIS life cycle
At the core of creation and use AIS lies the concept of life cycle (LC).
The life cycle is a model for the creation and use of AIS, which reflects the various states of the system from the moment it appears in a given set of tools to the moment it is completely out of use.
For AIS, the following main stages of their life cycle are conditionally distinguished:
1. analysis - determining what the system should do;
2. design - determining how the system will function: first of all, the specification of subsystems, functional components and how they interact in the system;
3. development - the creation of functional components and individual subsystems, the connection of subsystems into a single whole;
4. testing - checking the functional and parametric compliance of the system with the indicators determined at the analysis stage;
5. implementation - installation and commissioning of the system;
6. support - ensuring the regular process of operating the system at the customer's enterprise.
The stages of development, testing and implementation of AIS are denoted by a single term - implementation.
At each stage of the life cycle, a certain set of technical solutions and documents reflecting them are generated, while for each stage the documents and decisions made at the previous stage are the initial ones.
Existing life cycle models determine the order of execution of stages in the process of creating a system, as well as the criteria for moving from stage to stage. The most widespread are the following models.
Cascade model involves the transition to the next stage after the completion of the work of the previous stage. This model is used in the construction of AIS, for which at the very beginning of development it is possible to formulate all the requirements quite accurately and completely. This gives developers the freedom to implement them as best they can from a technical point of view. This category includes complex settlement systems, real-time systems, and others. However, this approach has a number of disadvantages, primarily due to the fact that the actual process of creating a system never fully fits into a rigid scheme. For example, in the process of creating software, there is a need to return to previous stages and clarify or revise previously made decisions.
spiral model relies on the initial stages of the life cycle: analysis, preliminary and detailed design.
Each turn of the spiral corresponds to a step-by-step model for creating a fragment or version of the system, on which the goals and characteristics of the project are specified, its quality is determined, and the work of the next turn of the spiral is planned. The main problem is determining the moment of transition to the next stage. To solve it, it is necessary to introduce time limits for each of the stages of the life cycle. The transition is carried out in accordance with the plan, which is compiled on the basis of statistical data obtained in previous projects, and personal experience developers. The disadvantage of this approach is the unresolved issues and errors made at the stages of analysis and design. They can lead to problems in subsequent stages and even to the failure of the entire project. For this reason, analysis and design must be carried out with particular care.
How to disable ads on Android: remove pop-up ads
The Russian received a term and a million fine for "piracy Negative consequences of the law
Identification of key factors
The criteria for classifying organizations and individual entrepreneurs as small and medium-sized businesses have changed
See what "Royalty" is in other dictionaries Pitfalls of legislation