3.1 Defining an AIS life cycle model
under the model life cycle software product development is understood as a structure that determines the sequence of execution and the relationship of processes, actions and tasks performed throughout the life cycle of software product development. 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. Provided Feedback between users and developers during the course of a project. Used requirements are not complete |
| Rapid Application Development Model | Project teams 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. Migration from the current implementation to a new version is not possible while the current partial implementation is being built |
| 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 homogeneous information systems During 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 of the next stage often cause changes in the design decisions developed at earlier stages. Thus, there is a constant need to return to previous stages and clarify or revise earlier decisions taken. 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 given to verification and certification 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 ...
The cascade approach has proven itself well in building ISs, for which at the very beginning of development it is possible to formulate all the requirements quite accurately and completely in order to provide developers with the freedom to implement them technically as best as possible. This category includes complex systems with a large number of tasks of a computational nature of a real-time system, etc.
AIS life cycle model- is a structure that describes the processes, activities and tasks that are carried out during the development, operation and maintenance throughout the entire life cycle of the system.
The choice of a life cycle model depends on the specifics, scale, complexity of the project and the set of conditions in which the AIS is created and operates.
The AIS life cycle model includes:
The results of the work at each stage;
Key events or points of completion and decision making.
In accordance with the well-known software life cycle models, AIS life cycle models are determined - cascade, iterative, spiral.
I. Cascade model describes the classical approach to the development of systems in any subject areas; was widely used in the 1970s and 80s.
The cascade model provides for a sequential organization of work, and the main feature of the model is the division of all work into stages. The transition from the previous stage to the next occurs only after the complete completion of all the work of the previous one.
Allocate five stable development stages, practically independent of the subject area
On the first At the stage, the problem area is studied, the customer's requirements are formulated. The result of this stage is the terms of reference (development task), agreed with all interested parties.
During second stage, according to the requirements terms of reference, certain design solutions are being developed. The result is a set of project documentation.
Third stage - project implementation; in essence, software development (coding) in accordance with the design decisions of the previous stage. Implementation methods are not of fundamental importance. The result of the stage is a finished software product.
On the fourth At the stage, the received software is checked for compliance with the requirements stated in the terms of reference. Trial operation makes it possible to reveal various kinds of hidden shortcomings that manifest themselves in real conditions of AIS operation.
The last step is surrender finished project, and the main thing here is to convince the customer that all his requirements are met in full.
Fig. 1.1 AIS LC cascade model
The stages of work within the waterfall model are often referred to as parts of the AIS project cycle, since the stages consist of many iterative procedures for refining system requirements and design options. The life cycle of AIS is much more complicated and longer: it can include an arbitrary number of cycles of refinement, changes and additions to already adopted and implemented design decisions. In these cycles, the development of AIS and the modernization of its individual components take place.
Benefits of the waterfall model:
1) at each stage, a complete set of design documentation is formed that meets the criteria for completeness and consistency. At the final stages, user documentation is developed, covering all types of AIS support provided for by the standards (organizational, informational, software, technical, etc.);
2) the sequential execution of the stages of work allows you to plan the timing of completion and the corresponding costs.
The cascade model was originally developed to solve various kinds of engineering problems and has not lost its significance for the applied area to date. In addition, the waterfall approach is ideal for the development of AIS, as already at the very beginning of development it is possible to formulate all the requirements quite accurately in order to provide developers with the freedom of technical implementation. Such AIS, in particular, include complex settlement systems and real-time systems.
Disadvantages of the waterfall model:
Significant delay in obtaining results;
Errors and shortcomings at any of the stages appear, as a rule, at subsequent stages of work, which leads to the need for a return;
The complexity of parallel work on the project;
Excessive information overload of each of the stages;
The complexity of project management;
High level of risk and unreliability of investments.
Delay in getting results It is manifested in the fact that in a consistent approach to development, the results are agreed with stakeholders only after the completion of the next stage of work. As a result, it may turn out that the developed AIS does not meet the requirements, and such inconsistencies can occur at any stage of development; in addition, errors can be unintentionally introduced by both analysts and programmers, since they are not required to be well versed in the subject areas for which AIS is being developed.
Return to earlier stages. This drawback is a manifestation of the previous one: the phased sequential work on the project can lead to the fact that errors made at earlier stages are detected only at later stages. As a result, the project returns to the previous stage, is processed and only then transferred to subsequent work. This can cause a disruption in the schedule and complicate the relationship between development teams performing individual stages.
The worst option is when the flaws of the previous stage are found not at the next stage, but later. For example, at the stage of trial operation, errors in the description of the subject area may appear. This means that part of the project must be returned to the initial stage of work.
The complexity of parallel work related to the need to harmonize the various parts of the project The stronger the relationship of individual parts of the project, the more often and more carefully synchronization must be performed, the more dependent on each other development teams. As a result, the advantages of parallel work are simply lost; the lack of parallelism has a negative impact on the organization of the work of the entire team.
Problem information overload arises from the strong dependency between different groups of developers. The fact is that when making changes to one of the parts of the project, it is necessary to notify those developers who used (could use) it in their work. With a large number of interconnected subsystems, the synchronization of internal documentation becomes a separate major task: developers must constantly familiarize themselves with changes and evaluate how these changes will affect the results obtained.
Complexity of project management mainly due to the strict sequence of development stages and the presence of complex relationships between different parts of the project. The regulated sequence of work leads to the fact that some development groups have to wait for the results of the work of other teams, therefore, administrative intervention is required to agree on the timing and composition of the transferred documentation.
In case of detection of errors in the work, a return to the previous stages is necessary; the current work of those who made a mistake is interrupted. The consequence of this is usually a delay in the implementation of both the corrected and the new projects.
It is possible to simplify the interaction between developers and reduce the information overload of documentation by reducing the number of links between individual parts of the project, but not every AIS can be divided into loosely coupled subsystems.
High level of risk. The more complex the project, the longer each stage of development lasts and the more complex the relationship between the individual parts of the project, the number of which also increases. Moreover, the results of the development can actually be seen and evaluated only at the testing stage, i.e. after the completion of the analysis, design and development - stages, the implementation of which requires considerable time and money.
A belated evaluation creates serious problems in identifying analysis and design errors - a return to previous stages and a repetition of the development process is required. However, a return to previous stages can be associated not only with errors, but also with changes that have occurred in the subject area or in customer requirements during development. At the same time, no one guarantees that the subject area will not change again by the time the next version of the project is ready. In fact, this means that there is a possibility of a "cycle" of the development process: the costs of the project will constantly increase, and the deadlines for the delivery of the finished product will be constantly delayed.
II. Iterative model (Staged model with intermediate control) is a series of short cycles (steps) of planning, implementation, study, action.
The creation of complex AIS involves the coordination of design solutions obtained during the implementation of individual tasks. The “bottom-up” approach to design necessitates such iterations of returns, when design solutions for individual tasks are combined into common system ones. In this case, there is a need to revise the previously formed requirements.
Advantage of the iterative model is that inter-stage adjustments provide less labor intensity of development compared to the cascade model.
Flaws iterative model:
· the lifetime of each stage is stretched for the entire period of work;
· due to the large number of iterations, there are discrepancies in the implementation of design decisions and documentation;
the complexity of the architecture;
· Difficulties in the use of project documentation at the stages of implementation and operation necessitate redesigning the entire system.
III. spiral model, in contrast to the cascade, but similar to the previous one, involves an iterative process of developing AIS. At the same time, the importance of the initial stages, such as analysis and design, which checks and justifies the feasibility of technical solutions by creating prototypes, increases.
Each iteration is a complete development cycle leading to the release of an internal or external version of a product (or a subset of the final product) that is improved from iteration to iteration to become a complete system (Figure 1.2).
Rice. 1.2. Spiral model of AIS life cycle
Thus, each turn of the spiral corresponds to the creation of a fragment or version of a software product, it specifies the goals and characteristics of the project, determines its quality, and plans work on the next turn of the spiral. Each iteration serves to deepen and consistently specify the details of the project, as a result of which a reasonable option for the final implementation is selected.
Using the spiral model allows you to move to the next stage of the project without waiting for the current one to be completely completed - the unfinished work can be done at the next iteration. The main task of each iteration is to create a workable product for demonstration to users as quickly as possible. Thus, the process of introducing clarifications and additions to the project is greatly simplified.
The spiral approach to software development overcomes most of the shortcomings of the waterfall model, in addition, it provides a number of additional features making the development process more flexible.
Advantages iterative approach:
Iterative development greatly simplifies the introduction of changes to the project when changing customer requirements;
When using the spiral model, individual elements of the AIS are gradually integrated into a single whole. Since the integration starts with fewer elements, there are far fewer problems during its implementation;
Reducing the level of risks (a consequence of the previous advantage, since risks are detected precisely during integration). The level of risks is maximum at the beginning of the project development, as the development progresses, it decreases;
Iterative development provides greater flexibility in project management by allowing tactical changes to be made to the product under development. So, it is possible to reduce the development time by reducing the functionality of the system or use third-party products as components instead of your own developments (relevant when market economy when it is necessary to resist the promotion of a competitor's product);
The iterative approach makes it easier to reuse components because it is much easier to identify (identify) the common parts of the project when they are already partially developed than to try to isolate them at the very beginning of the project. Analysis of the design after several initial iterations reveals common reusable components that will be improved in subsequent iterations;
The spiral model allows you to get a more reliable and stable system. This is because as the system evolves, bugs and weaknesses are found and fixed at each iteration. At the same time, critical performance parameters are adjusted, which in the case of a waterfall model is available only before the implementation of the system;
An iterative approach allows for process improvement
development - as a result of the analysis at the end of each iteration, an assessment of changes in the development organization is carried out; it improves on the next iteration.
The main problem of the spiral cycle- the difficulty of 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. Otherwise, the development process can turn into an endless improvement of what has already been done.
Involving users in the process of designing and copying the application allows you to receive comments and additions to the requirements directly in the process of designing the application, reducing development time. Representatives of the customer get the opportunity to control the process of creating the system and influence its functional content. The result is a commissioning of a system that takes into account most of the needs of customers.
Life cycle model and design technology
Earlier we said that the design technology sets the sequence of actions necessary to obtain an IP project. Obviously, the execution of each of these actions means the transition of the information system from one state to another. Thus, any design technology unambiguously describes some life cycle model. On the other hand, by building an information system life cycle model, that is, by defining:
tasks, composition and sequence of work performed;
· the results of each performed action;
Methods and means necessary for the performance of work;
the roles and responsibilities of participants;
other information necessary for planning, organizing and managing the collective development of IP,
we will get an unambiguous description of the design technology we have chosen. Thus, the life cycle model is an integral and essential part of information systems design technology.
Stages and stages of design
The concepts of “stage” and “stage” of design are often confused. Sometimes they talk about stages or phases life cycle, steps design. The question arises: what is the right way?
It should be remembered that in different international standards terminology used may vary. We will, if possible, focus on the terminology of domestic GOSTs. Design stage we will call the part of the process of creating an IS, limited by some time frame and ending with the release of a specific product (model, documentation, program text, etc.). According to the commonality of goals, design stages can be combined into stages. For example, the "Technical Design" stage, the "Implementation" stage, etc.
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 stand-alone testing. On average, the development of AIS occupies one third of the entire life cycle of the system.
Rice. Distribution of time in the development of AIS
AIS creation stages (ISO/IEC 15288)
The ISO/IEC 12207 standard defines a life cycle framework containing the processes, activities, and tasks that must be performed during the creation of an information system.
AIS exist, as a rule, for a long period of time, successively going through several stages of combined development in their development. life cycle(LC) systems:
1) pre-project survey (or analysis) of the organization,
2) AIS design,
3) implementation of AIS,
4) introduction of AIS,
5) functioning (operation, use)
6) AIS escort,
7) modernization of the AIS project.
Life cycle - the period of creation and use of an information system, covering its various states, starting from the moment the need for this information system arises and ending with the moment of its complete exit from operation.
It should be noted that AIS is a product of information production, just as a car is a product of machine-building production, a sausage is a product of food production, etc., therefore, the stages of the AIS life cycle with 1 to 5 are similar to the stages of the life cycle of any product.
AIS life cycle, like a car, can end as a result of physical wear and tear, if in the life cycle support phase not worked out, that is, repair and maintenance, for example, of computers and programs that are part of the AIS (without maintenance, the system will not work even for six months). With qualified escort, AIS can exist for a long time, but there is a threat termination of the AIS life cycle due to obsolescence, AIS obsolescence, if there is no upgrade stage AIS (without modernization, the system will not work for more than 2 years).
AIS physical deterioration is the inability to meet the organization's requirements for AIS due to breakdown, failure or failure of the system components.
Obsolescence of AIS - termination of meeting the requirements of the organization and its employees for AIS, as a result of the use of outdated automated information technologies and lack of support for new user requirements.
If your organization approached automation responsibly and comprehensively, organized all stages and stages accordingly, then AIS life cycle limit only the lifetime of your organization, which means that the funds spent on the AIS will not be thrown into the trash along with the physically or morally obsolete AIS.
All stages of the AIS life cycle were listed above, but some of them run in parallel, so they allocate only 5 stages in the AIS life cycle(fig.35):
At the first stage " Pre-project survey» (Fig. 33) it is customary to distinguish two main sub-stages and one additional sub-stage:
1.1. conducting pre-project survey and collection of survey materials;
1.2. analysis of survey materials and development based on the analysis of a feasibility study (FS) and terms of reference (TOR);
1.3. selection and development of a variant of the system concept.
The objectives of the pre-project survey stage are as follows:
· formulate the needs for a new AIS, i.е. identify all the shortcomings of the existing IS;
· choose the direction and determine the economic feasibility of designing AIS.
Survey work begins with the analysis of primary requirements and work planning, which takes from 2 days to 4 weeks. Next, the survey itself of the enterprise is carried out (the duration of the survey is 1-2 weeks.)
First, a description is created and the functioning of the enterprise or organization in question is analyzed in accordance with the requirements (goals) that apply to it. The organizational and topological structures of the enterprise are determined. The functional activities of each of the divisions of the enterprise and the functional interactions between them, information flows within the divisions and between them, objects external to the enterprise and external information interactions are identified. A list of target tasks (functions) of the enterprise is determined and an analysis of the distribution of functions by departments and employees is carried out.
The list of automation means used at the enterprise is determined.
Further, the results of the survey are processed and the following two types of enterprise activity models are built (note that the construction of each of the required models requires intensive work of 6-7 qualified system analysts within 2-4 months).
1. Under construction "as is" model which is a "snapshot" of the state of affairs at the enterprise (organizational structure, interactions between departments, adopted technologies, automated and non-automated business processes, etc.) at the time of the survey and allows you to understand what this enterprise does and how it functions from the standpoint of system analysis, as well as, on the basis of automatic verification, identify a number of errors and bottlenecks and formulate a number of proposals for improving the situation.
2. Formed The "as it should" model integrating promising proposals of the management and employees of the enterprise, experts and system analysts and allowing to form a vision of new rational technologies for the operation of the enterprise. She represents concept of the future AIS.
Creation of the concept of the future system includes the following works:
Detailed study of the automation object;
Required research work (R&D) related to finding ways and assessing the possibility of implementing user requirements;
Development of alternative options for the concept of the created AIS and plans for their implementation;
Grade necessary resources for their implementation and operation;
Evaluation of the advantages and disadvantages of each option;
Comparison of user requirements and characteristics of the proposed system and selection best option;
Determination of the procedure for assessing the quality and conditions for the acceptance of the system;
Evaluation of the effects received from the system;
Preparation of a report containing a description of the work performed;
Description and justification of the proposed version of the system concept.
Based on the constructed concept of the system and the results of the survey of the enterprise in terms of identifying requirements for the future system, a system project is formed (requirements model), which is the first phase of the development of the automation system itself (namely, the phase of the analysis of requirements for the system), on which the customer's requirements are specified, formalized and documented
In fact, at this stage, an answer is given to the question: "What should the future system do?". This is where the key to the success of the entire automation project lies. In the practice of creating large software systems, there are many examples of unsuccessful implementation precisely because of the incompleteness and fuzziness of defining system requirements.
At this stage, the following are determined:
§ architecture of the system, its functions, external conditions of its functioning, distribution of functions between the hardware and software parts;
§ interfaces and distribution of functions between a person and a system;
§ requirements for software and information components of the system, necessary hardware resources, database requirements, physical characteristics of the system components, their interfaces;
§ the composition of people and jobs related to the system;
§ limitations in the development process (directive deadlines for completing individual stages, available resources);
§ organizational procedures that ensure the protection of information.
As part of system design, the following is carried out:
Determination of the composition, structure and characteristics of functional tasks within the framework of the activities of structural divisions;
Determination of the composition and structure of automation software for problem solving technology, taking into account existing tools in structural divisions;
Determination of the structure and characteristics of information support technology for solving problems;
Development of technical solutions for the construction of information support (logical database structures, classifier structures);
§ development of the composition of automated workflow procedures.
System project should include:
a complete functional model of requirements for the future system;
Comments on the functional model (lower-level process specifications in text form);
a package of reports and documents on a functional model, including a description of the modeling object, a list of subsystems, requirements for methods and means of communication for information exchange between components, requirements for the characteristics of the system's interconnections with adjacent systems, requirements for system functions;
· conceptual model of the integrated database (package of diagrams);
system architecture with reference to the conceptual model;
· proposals for the organizational structure to support the system.
Thus, the system project contains functional, informational and, possibly, event models of requirements for the future system. The types and sequence of work in building these requirements models are similar to the corresponding work on building activity models. Additionally, the system project includes terms of reference for the creation of an automated system.
It is necessary to note the following advantage of the system project. Traditional development is characterized by the implementation of the initial stages in artisanal non-formalized ways. As a result, customers and users can see the system for the first time after it has already been largely implemented. Naturally, this system is different from what they expected to see. Therefore, several more iterations of its development or modification follow, which requires additional (and significant) costs of money and time. The key to solving this problem is the system project, which allows:
Describe, "see" and correct the future system before it is implemented physically;
Reduce the cost of developing and implementing the system;
Evaluate the development in terms of time and results;
Achieve mutual understanding between all participants in the work (customers, users, developers, programmers, etc.);
To improve the quality of the developed system, namely: to create an optimal structure of an integrated database, to perform a functional decomposition of typical modules.
A system project is completely independent and separable from specific developers, does not require maintenance by its creators, and can be painlessly transferred to other persons. Moreover, if for some reason the enterprise is not ready to implement the system based on the project, it can be put "on the shelf" until the need arises. In addition, it can be used for independent development or correction of software tools already implemented on its basis by the programmers of the enterprise automation department.
The purpose of the development of the "Feasibility Study" of the AIS project is to assess the main parameters that limit the project, justify the choice and evaluate the main design decisions for individual components of the project. At the same time, there are organizational parameters that characterize the ways of organizing the processes of information transformation in the system, informational and economic parameters that characterize the costs of creating and operating the system, savings from its operation. The main objects of parametrization in the system are tasks, task complexes, economic indicators, information processing processes. After a decision has been made on further work, a series of organizational measures, for example, appropriate work orders must be issued; Responsible for areas should be appointed, etc.
Without such support from the management of the enterprise, it is pointless to start a project at all.
Figure 33. The sequence of work at the pre-design stage of the AIS life cycle.
Next, a terms of reference (TOR) for the project is created, which reflects specifications and requirements for the future AIS, as well as restrictions on design resources. If the project requires scientific study of the components, then the concept of the future AIS is developed based on the TOR.
As part of the formation of the TOR, proposals for automation are developed based on the identified and agreed requirements, which include:
Drawing up a list of automated workplaces of the enterprise and ways of interaction between them;
Analysis of the applicability of existing enterprise management systems (primarily MRP and ERP classes) to solve the required tasks and the formation of recommendations for choosing such a system;
Joint decision-making with the client choosing a specific enterprise management system or developing your own systems.
Development of proposals for technical means;
Development of software proposals;
Development of the topology, composition and structure of the local area network;
Development of proposals for the stages and terms of automation.
If it was decided to choose a specific control system, then some steps are skipped.
Second phase " Design» (Fig. 34) performs the following sub-steps:
1) preliminary design: clarification of the requirements of the TOR, execution and approval of the preliminary design;
2) technical design: selection of design solutions for all aspects of AIS development, description of all AIS components, execution and approval of a technical project;
3) detailed design: selection and development of mathematical methods and program algorithms, adjustment of the structure of databases (DB), creation of documentation for the supply and development of software products, selection of a set of AIS hardware, creation of documentation for the supply and installation of hardware, development of a working draft of AIS .
The objectives of this phase are:
· develop a functional architecture of the AIS, which reflects the structure and composition of functional subsystems, for automated support of certain management functions of the organization;
· to develop the system architecture of the selected AIS variant, that is, the composition of the supporting subsystems.
For complex large-scale AIS, automating large enterprise, holding, bodies state power etc., in sub-step 1 " Preliminary design» preliminary solutions are formulated for the future AIS as a whole and its components, as a result of which preliminary design(EP). Development of preliminary design solutions for the system and its parts includes:
Definition of AIS function;
Definition of the function of subsystems, their goals and effects;
Determination of the composition of task complexes and individual tasks;
Definition of the concept of the information base, its enlarged structure;
Definition of database management system functions;
Determination of the composition of the computer system;
Definition of the function and parameters of the main software tools.
Development of documentation for this part of the project.
If the project being developed is not very complex, suppose a small enterprise is being automated, then the work step is skipped.
At sub-step 2. Engineering design » work on logical development and selection of the best options design decisions, as a result of which a technical project (TP) is created. As part of the creation of a technical project, the following is carried out:
- transformation of a system project into a technical project(implementation model), which includes the following actions: refinement of the logical model (development of detailed logic for each process using data flow diagrams and process specifications), design of a physical database, construction of a hierarchy of module functions to be programmed, estimation of implementation costs.
The listed work should be performed by consultant analysts together with system designers - this is where the border separating consulting and development lies. Nevertheless, it is desirable that at the stage of system implementation the consultant also acts in the interests of the customer, namely: software system systemic and technical projects, and also participated in the work on its expansion and modification, tk. extensions should be planned based on the requirements model.
- technical design work:
Development of general solutions for the system and its parts,
Development of general solutions for functional-algorithmic system structure,
Development of common decisions on personnel functions and organizational structure,
Development of common solutions on the structure of technical means,
Development of general solutions for problem solving algorithms and languages used,
Development of common solutions for organizing and maintaining an information base,
Development of common solutions for the system of classification and coding of information,
Development of common software solutions;
Carry out the development, execution of documentation for all parts of the project, including the document "Formulation of the problem",
Development and execution of documentation for the supply of products for the acquisition of AIS and / or technical requirements(technical specifications) for their development;
Development of design tasks in adjacent parts of the project of the automation object.
Sub-stage 3. " Working design » associated with the physical implementation of the selected project option and the receipt of the detailed design documentation (DP).
This sub-stage is carried out:
Development and execution of working documentation containing all the necessary and sufficient information to ensure the implementation of work on the commissioning of the AIS and its operation, as well as to maintain the level of operational characteristics (quality) of the system in accordance with the adopted design decisions and the coordination and approval of this documentation;
Development of programs and software tools of the system, as well as the selection, adaptation and / or binding of purchased software tools,
Development of software documentation.
Organization of tenders for the supply of AIS components (software and hardware, software and hardware systems, information products).
Figure 34. The sequence of work at the design stage of the AIS life cycle.
In the presence of design experience and a small complexity of the project, all three sub-stages are combined into one, as a result of which a single techno-working project (TDP) is obtained. In this case, the project is consistently, as the sub-stages are completed, transformed from a draft to a detailed design.
The third stage Implementation» (Fig. 35) is the physical design of the system in the following sequence:
1) receipt and installation of technical means;
2) coding, testing and development of programs;
3) obtaining and installing software;
4) creation of information support, including the filling of databases;
5) development of instructions for the operation of software and hardware, as well as job descriptions for staff.
These works can practically be carried out in parallel.
At the fourth stage of the AIS life cycle " Implementation» there are the following sub-steps:
1) pilot implementation:
commissioning of technical equipment,
commissioning of software tools, conducting trial operation of all components and systems as a whole,
· training and certification of personnel.
Pilot implementation consists in checking the operability of elements and modules of the project, eliminating errors at the level of elements and links between them.
At this stage, work is carried out on organizational training automation object to put AIS into operation, including:
Implementation of design decisions on the organizational structure of the AIS;
Providing units of the control object with instructive and methodological materials;
Introduction of information classifiers;
Training,
Checking its ability to ensure the functioning of the AIS.
At the same stage, AIS is completed with supplied products (software and technical means, software and hardware complexes, information products), as well as construction and installation, commissioning, preliminary tests:
Carry out tests of the AIS for performance and compliance with the terms of reference in accordance with the program and methodology of preliminary tests prepared in advance;
Troubleshooting and improvement (if necessary) of the software, making changes to the AIS documentation, including operational documentation in accordance with the test protocol.
Pilot implementation work ends on drawing up an act on the completion of trial operation.
2) industrial implementation (putting into commercial operation):
commissioning,
Signing of acts of acceptance and delivery of works.
Commissioning consists in organizing a project verification at the level of functions and monitoring compliance with its requirements formulated at the pre-project survey stage, i.e.:
Carry out a test for compliance with the terms of reference in accordance with the program and methodology of acceptance tests prepared in advance;
Analysis of the AIS test results and elimination of shortcomings identified during the tests.
Finishing work on drawing up an act on the acceptance of AIS for permanent operation.
At the last fifth stage of the AIS life cycle, operation, maintenance and modernization software, hardware and the entire project.
AIS escort lies in performance of work in accordance with the warranty obligations, implementation of work to eliminate the shortcomings identified during the operation of the AIS within the established warranty period and in the implementation of work to make the necessary changes to the documentation for the AIS.
Post-warranty service consists of:
In the implementation of work on the analysis of the functioning of the system;
In identifying deviations of the actual operational characteristics of the AIS from the design values;
In establishing the causes of these deviations;
In eliminating the identified shortcomings and ensuring the stability of the operational characteristics of the AIS;
In making the necessary changes to the documentation for AIS.
Depending on the specifics of the created AIS and the conditions for their creation, it is allowed to perform individual stages of work before the completion of the previous stages, the parallel execution of work stages in time, the inclusion of new stages of work.
Figure 35. AIS life cycle stages.
The life cycle is usually iterative: completed stages Life cycles, starting from the earliest ones, are cyclically repeated in accordance with new requirements and changes in external conditions. At each stage of the life cycle, a set of documents and technical solutions is formed, which are the starting points for subsequent decisions.
The most widespread three life cycle models:
cascade model (until the 70s) - a sequential transition to the next stage after the completion of the previous one;
· iterative model (70s - 80s) - with iterative returns to the previous stages after the completion of the next stage;
· spiral model (80-90s) - a prototype model, which assumes a gradual expansion of the AIS prototype.
For cascade model of life cycle the automation of separate unrelated tasks is typical, which does not require information integration and compatibility, software, technical and organizational interface. As part of solving individual problems, the cascade model justified itself in terms of development time and reliability. The application of this life cycle model to large and complex projects, due to the long duration of the design process and the variability of requirements during this time, leads to their practical unrealizability.
Iterative life cycle model. The creation of complex AIS involves the linking of design solutions obtained in the implementation of individual tasks. The “bottom-up” design approach necessitates such iterative returns, when design solutions for individual tasks are completed into general system solutions, and at the same time there is a need to revise previously formulated requirements. As a rule, due to a large number of iterations, discrepancies arise in the completed design decisions and documentation. The confusion of functional and system architecture created by AIS, the difficulty in using design documentation causes the need to redesign the entire system at the stages of implementation and operation. The long life cycle of developing an information system ends with the implementation stage, followed by the life cycle of creating a new AIS.
Spiral life cycle model. A top-down approach to the organization of AIS design is used, when the composition of functional subsystems is first determined, and then the setting of individual tasks. Accordingly, first such system-wide issues are developed as the organization of an integrated database, the technology for collecting, transmitting and accumulating information, and then the technology for solving specific problems. Within the framework of task complexes, programming is carried out in the direction from the main program modules to the modules that perform individual functions. At the same time, the issues of interaction between interfaces of software modules and with the database come to the fore, and the implementation of algorithms comes to the background.
Each turn of the spiral corresponds to a step-by-step model for creating an AIS fragment. It clarifies the goals and characteristics of the project, determines its quality, and plans the work of the next turn of the spiral. There is a consistent deepening and concretization of the details of the project, its substantiated version is formed, which is brought to implementation.
The spiral model of the life cycle is based on the use of prototype technology or RAD technology (rapid application development).
According to this technology, AIS is developed by expanding software prototypes, following the path from specification of requirements to specification of program code.
Naturally, with prototype technology, the number of iterations is reduced and there are fewer errors and inconsistencies that need to be corrected at subsequent iterations, and the design itself is carried out at a faster pace, and the creation of project documentation is simplified. To more accurately match the design documentation developed by AIS, more and more importance is attached to maintaining a system-wide repository and design automation, in particular, the use of CASE (Computers Aids System Engineering) technologies.
When using the spiral model:
· there is an accumulation and reuse of design solutions, design tools, models and prototypes of AIS and information technologies;
· Orientation is carried out on the development and modification of the system and technologies in the process of their design;
· a risk and cost analysis is carried out in the system design process.
An interface is a pairing of parts of software and hardware, data, a technology for communicating between a person and a computer, in which all information, logical, physical and electrical parameters meet established standards.
Prototype - the minimum version of the system used to generate or develop the full version
The repository contains information about the objects of the designed AIS and the relationships between them, all subsystems exchange data with it.
AIS Life Cycle Models - A structure that defines the sequential implementation of processes, actions, tasks performed throughout the life cycle and the relationship between these processes.
cascade model. The transition to the next stage means the complete completion of the work at the previous stage. The requirements defined at the requirements formation stage are strictly documented in the form of terms of reference and fixed for the entire duration of the project development. Each stage culminates in the release of a complete set of documentation sufficient for development to be continued by another development team.
Project stages according to the waterfall model:
1. Formation of requirements;
2. Design;
3. Development;
4. Testing;
5. Introduction;
6. Operation and maintenance.
Advantages:
-Full and agreed documentation at each stage;
-Determined order of work sequence;
- Allows you to clearly plan the timing and costs.
Flaws:
-Significant delay in obtaining ready-made results;
-Mistakes at any of the stages are detected at subsequent stages, which leads to the need to return and re-register project documentation;
- Difficulty in project management.
spiral model. Each iteration corresponds to the creation of a fragment or version of the software, at which the goals and characteristics of the project are specified, the quality of the results obtained is assessed, and the work of the next iteration is planned.
Each iteration is a completed development cycle in the form of the 1st version of the AIS.
Iteration steps:
1.Formation of requirements
3.Design
4.Development
5.Integration
At each iteration, the following are evaluated:
The risk of exceeding the terms and cost of the project;
The need to perform another iteration;
The degree of completeness and accuracy of understanding the requirements for the system;
The expediency of terminating the project.
Advantages:
-Simplifies the process of making changes to the project;
- Provides greater flexibility in project management;
- The possibility of obtaining a reliable and stable system, because errors and inconsistencies are found at each iteration;
- Influence of the customer on the work in the process of checking each iteration.
Flaws:
-Complexity of planning;
-Intense mode of work for developers;
-Work planning is based on experience and there are not enough metrics to measure the quality of each version.
Requirements for the technology of design, development and maintenance of AIS
Design technology- defines a combination of three components:
- step by step procedure, which determines the sequence of technological design operations;
- rules used to evaluate the results of technological operations;
- submission of design development for examination and approval.
Technological instructions, which make up the main content of the technology, should consist of a description of the sequence of technological operations, the conditions depending on which one or another operation is performed, and descriptions of the operations themselves.
The technology for designing, developing and maintaining IS must meet the following general requirements:
The technology must support the full software lifecycle;
The technology should ensure the guaranteed achievement of the goals of IS development with a given quality and at a specified time;
The technology should provide the possibility of conducting work on the design of individual subsystems in small groups (3-7 people). This is due to the principles of team manageability and productivity increase by minimizing the number of external links;
The technology should provide for the possibility of managing the project configuration, maintaining versions of the project and its components, the possibility of automatically issuing project documentation and synchronizing its versions with project versions;
The use of any technology for the design, development and maintenance of IS in a particular organization and a particular project is impossible without the development of a number of standards (rules, agreements) that must be observed by all project participants. To such standards include the following:
- design standard;
- standard for the design of project documentation;
- user interface standard.
Development requirement
- Performing work on the creation of software;
Preparation for the introduction of AIS;
Control, testing of the main indicators of the project.
Escort Requirements
Completion of the implementation of the CIS should be accompanied by the publication of a system of administrative regulations and job descriptions that determine the functioning of the organization. From the moment the information system is put into operation, operation takes place on the basis of the "Regulations for the functioning of the information system" and a number of regulations. Maintenance of the system and its uninterrupted operation is carried out by a subdivision of the organization authorized by the relevant order. Refinement of the information system after commissioning is carried out in accordance with individual projects and terms of reference.
In the process of maintaining CIS, the task is to maintain its viability. The viability of the CIS is largely determined by how it corresponds to the real tasks and needs of the university, which are changing during the life cycle of the CIS.
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. Tools development of AIS UP 104
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
The activity of modern enterprises is 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 a short time. The solution to this problem in modern conditions impossible without the use of automated processing of technical 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 automation of 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 communication tools 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. Implementation of global computer networks in economic processes led to the emergence of new concepts: the economics 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. It needs development new concept 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 for many 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 systems that implement the solution of related problems. Under these conditions, the task of synthesizing integrated enterprise management systems by integrating off-the-shelf components from third-party manufacturers, 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, the mechanisms for designing and developing information systems (IS) using component multi-link architectures based on standards and protocols of open systems have not been sufficiently developed.
In this regard, the problem of developing a theoretical platform and developing practical recommendations aimed at building AIS UE, which provides comprehensive automation of all information procedures for managing enterprises and organizations, becomes an urgent one.
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 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 ensure information support through 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 of 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.
In the course of the study, the 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, the Moscow state university 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 functionality 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;
Proposals for the implementation of a unified system for the 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 proposals put forward makes it possible to create AIS UE that provide 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 management IS for 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 training center of Vest-MetaTechnology 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 telecommunication 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);
Conference of specialists in the field of ACS and CIS " Enterprise 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 of 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 the approaches to building AIS UE. This applies not only to purely technological problems of the creation and operation of IS, but also to 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 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 makes high requirements to the 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 a common database if individual IS software components are developed by 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. Schematic architecture with common base 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 enterprise’s functional services are able to perform information procedures within their competence using computers without involving or with minimal support from accompanying technical personnel ;
means of automated support for coordinated joint work groups ("teams") of workers on one project, document, task, etc.;
mechanism of electronic communications, 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 of a particular business process.
Thanks to these solutions, it became possible to automate most of the work processes that take place 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 jobs 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-specific 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 economic entities in XML format, for example, 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 hardware 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, a 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 network diagram, where vertices designate jobs with indication of 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 workers and technological processes, which 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, the technological data generated 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 the AIS UE and available to consumers of information in real 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 dissertation, the system of integrated enterprise management automation "Flagman" of the company "Infosoft" was developed, which is currently implemented in more than a 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 system "Flagship" 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 entry of primary documents, the generation of accounts in functional subsystems based on these documents, and the 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 print forms, as well as rules for the formation of registers and document logs .
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 a 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.
On the this moment IT development 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 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 ".
Only lovers will survive
Features of advertising aimed at children
retouching old photos in photoshop retouching old photos
What is an NPO: decoding, definition of goals, types of activities Does a non-profit organization have the right
Gleb Nikitin First Deputy