Physical modeling of ais. Life cycle of automated information systems (LC AIS)
The stage of physical modeling should provide at the experimental level a verification of the real performance of the created AIS models and their adequacy. To implement this stage, a physical (natural) model of the AIS is being developed. Physical model of AIS- this is a set of structure, methods and means of a reduced full-scale implementation of AIS, designed to test the performance of a future system and the adequacy of its models in real conditions.
In a certain respect, the physical model of AIS has the properties of a real system. For its construction, computers, peripheral devices, documents, files, databases, data processing programs and other components necessary for the creation of AIS are involved. The physical model of AIS is reduced, i.e. this is a reduced representation of it. The reduction here is not mechanical, not arbitrary, but harmonized. It presents only those properties that the developers classified as basic, essential.
3. AIS design
Based on the developed principles, provisions, models, methods and tools for constructing AIS obtained at the research stage, the system is being designed.
The design stage consists of the following stages:
1) subject survey (PRO) of the existing (traditional) IP;
2) development of technical specifications for the creation of the system;
3) development of a technical project for the creation of the system;
4) development of a working draft for the creation of the system.
Provided that the existing IS is automated, there are two ways of designing: modernization of the existing AIS or its complete replacement with a newly created AIS. With relatively small volumes of design work, stages 2 and 3 can be combined.
PRO stage is carried out in order to study and analyze the features of the object - the existing traditional IS. Collection of materials for design is carried out - the definition of requirements, the study of the design object. The conditions for the functioning of the future AIS are being studied, certain restrictions on the development conditions are being established - the timing of the design stages, the available and missing resources, procedures and measures to ensure the protection of information, etc. Taking into account the preliminary studies, the development and selection of the AIS concept variant is being carried out.
Stage of development of technical specifications- a logical continuation of the missile defense stage. Materials obtained at the ABM stage are used to develop the ToR. Here, the analysis and development of the fundamental requirements for AIS by a particular customer or potential consumer group are carried out. The requirements for hardware, software, information and organizational-legal components of the AIS, etc. are formulated.
On the stage of technical design the search for the most acceptable solutions for all AIS design tasks is carried out. The purpose of this design stage is to concretize general, sometimes fuzzy knowledge about the requirements for the future system. At this stage, the following are determined:
purpose, tasks, functions of AIS are also considered external conditions functioning of the system, distribution of functions between its components;
AIS system parameters - interfaces and distribution of functions between the operator and the system;
configuration of all AIS subsystems forming its structure - documentary-informational, technical, software-mathematical and organizational-legal components of the system structure;
structure and database management system, linguistic tools, composition of information retrieval languages, classifiers and codifiers, methods for indexing documents and queries;
configuration sheet of the complex of technical means of AIS and their specification;
composition and characteristics of mathematical models, algorithms and AIS programs;
scheme of functioning of AIS, technological process of data processing, etc.;
job and work instructions for AIS personnel;
updated feasibility study of the project.
The main part of the labor intensity of detailed design is the work on the development of algorithms and related programs.
On the detailed design stage the final refinement of those issues that at the stage of technical design for certain reasons could not be fully resolved is carried out. At this stage, a set of programs is being developed based on algorithms compiled at the stage of technical design. The structure of the database is being specified, the unified formats of documents processed in AIS technology are being adjusted.
At this stage, the programs are tested, a series of control tests with the processing of real documents, the results of testing and experimental processing, and the necessary adjustments to the programs are analyzed.
Methods and tools for designing AIS. AIS design can be performed:
third party developer. This firm has a staff of highly qualified professionals. The work is carried out on the basis of an agreement between the developer and the customer;
by staff specialists of the customer company.
A compromise solution is also possible: the customer firm can invite a consultant for the development of AIS on a contract basis.
The specific choice is determined by many factors, in particular financial condition of the customer firm, the availability of full-time specialists of the appropriate profile and level, the timing of the creation of AIS, the presence in the given or nearby region of the corresponding developer firm, specialist consultants, the firm's secrecy regime, etc.
Appropriate methods and tools are used to solve design problems. Among them, one should find such methods that would radically solve the problems of developing AIS. One such method is structural analysis. It is a method of studying a system that considers the system as hierarchical structure from its general level to the required lowest.
At the stage of pre-project survey, methods for studying the actual state of the existing (traditional) IP are used:
oral or written questioning;
written survey;
observation, measurement and evaluation;
discussion of intermediate results;
task analysis;
analysis of production, management and information
processes.
Methods for the formation of a given state are associated with the theoretical substantiation of all constituent parts AIS taking into account the goals, requirements and conditions of the customer. These include:
modeling of data processing processes;
structural design;
decomposition;
information technology analysis.
For a visual representation of AIS objects and processes, methods of graphical display of the actual and specified states are used - flowcharts, graphs, drawings, drawings, sketches, diagrams, etc.
4. AIS design automation
Computer-aided design systems - effective remedy improvement of AIS design indicators. In the field of design, a special direction has been formed - software engineering or CASE-technologies (Computer-Aided Software / System Engineering - a system for computer software development). CASE-technologies are a set of methods for analysis, design, development and implementation of AIS, supported by a set of interconnected automation tools. CASE-technologies is a tool for system analysts, developers and programmers that provides automation of AIS design processes of various classes and values.
The main goal of CASE-technology is to automate the development process as much as possible and to separate the design process from the coding of AIS software.
Structural methods for building enterprise models. It is customary to call a structural method such a method of studying a system or process that begins with a general overview of the object of study, and then involves its consistent detailing. Structural methods have three main features:
The division of a complex system into parts, presented as "black boxes", each "black box" implements a certain function of the control system;
Hierarchical ordering of selected elements of the system with the definition of relationships between them;
Using a graphical representation of the relationship of system elements.
A model built using structural methods is a hierarchical set of diagrams that graphically depict the functions performed by the system and the relationships between them.
As part of the methodologies of structural analysis, the most common include the following:
SADT is a structural analysis and design technology, and its subset is the IDEFO standard.
DFD - Data Flow Diagrams.
ERD - entity-relationship diagrams.
STD - state transition diagrams.
AT IDEFO methodology four basic concepts are used: functional block, interface arc, decomposition, glossary.
The IDEFO model always begins with a process representation of a single functional block with interface arcs extending beyond the considered area. Sometimes such diagrams are provided with context help.
The goal highlights those areas of activity of the enterprise that should be considered first of all. The goal sets the direction and level of decomposition of the developed model.
AT DFD methodology the process under study is divided into subprocesses and presented as a network connected by data flows. Externally, DFD is similar to SADT, but differs in the set of elements used. These include processes, data flows, and storage.
ERD methodology used to build database models, provides a standardized way to describe data and define relationships between them. The main elements of the methodology are the concepts of "essence", "relationship" and "relationship". An entity defines basic information types, and relationships specify how these data types interact with each other. Relationships connect entities and relationships.
STD methodology is most convenient for modeling certain aspects of the system operation, due to time and response to events, for example, to implement a user request to AIPS in real time. The basic elements of STD are the concepts of "state", "initial state", "transition", "condition" and "action". By means of concepts, a description of the functioning of the system in time and depending on events is carried out. The STD model is a graphic representation - a diagram of the system's transitions from one state to another.
Object-oriented methods for constructing control system models. These methods differ from structural methods by a higher level of abstraction. They are based on the representation of the system as a set of objects interacting with each other by exchanging data. Specific objects or abstract entities - an order, a client, etc. can serve as objects of the subject area. The most significant method is G. Buch. This is an object design technique with elements of object analysis, which has four stages:
1) development of a hardware diagram showing processes, devices, networks and their connections;
2) definition of a class structure that describes the relationship between classes and objects;
3) development of diagrams of objects that show the relationship of an object with other objects;
4) development of software architecture that describes the physical design of the system being created.
The vast majority of existing methods of object-oriented analysis and design include both a modeling language and tools for describing modeling processes.
The object-oriented approach is not opposed to the structural approach, but can serve as its complement.
5. Construction and implementation of AIS
After the complete completion of the design work, the stage of building the AIS begins. Building AIS is a set of organizational and technical measures for the implementation of the AIS project. Among such measures are financial, informational, technical, programmatic, legal, organizational measures:
Identification of funding sources and allocation of funds for procurement necessary equipment provided by the project - "AIS equipment specification sheet";
Selection of suppliers and conclusion of contracts for the supply of equipment;
Allocation of premises for deployment of AIS and its preparation for installation of equipment;
Placement, assembly, installation, configuration of AIS equipment in accordance with the project;
Selection, organization and training of categories of regular AIS personnel to perform relevant work to ensure the functioning of AIS;
Performance of work on quality control of equipment (control, testing). If defects are found - registration and presentation of complaints to suppliers;
Software installation and performance of work on testing the AIS software package. Subject to detection of defects - taking measures to eliminate them;
Filling the database, solving test cases for the entire range of AIS tasks in accordance with the project. If deficiencies are found, measures are taken to eliminate them. If no deficiencies are found - preparation of documents for putting the AIS into trial operation.
The composition of measures and their sequence reflect the main control points in the construction of AIS. The construction of each specific system will have its own specifics both in terms of the nature of the tasks and their sequence. Features of the construction are determined by the nature of the AIS, the organizational level of the AIS application, the mode of operation, the amount of funding, etc.
One of the important conditions for the effectiveness of AIS is the implementation of a complex of works for its implementation. The introduction of AIS begins with the fact that the head of the customer firm issues an order for the implementation of the system indicating the main stages, the timing of their implementation, responsible executors, resource support, the form for presenting the results of implementation, the person responsible for monitoring the execution of the order, etc. The order may contain an implementation plan with indicating the work in the following stages:
1) documenting results of commissioning of equipment, as well as control tests of a set of system tasks;
2) training of personnel in AIS technology and study of relevant sections project documentation;
3) carrying out trial operation of the system, analysis and correction of design errors and execution of documentation based on the results of trial operation;
4) delivery of AIS to production operation with the relevant documentation.
Thus, at the first stage, a program of control tests of the AIS as a whole is being developed. At the second stage, the developer and the customer organize training for personnel involved in the operation of the AIS. At the third stage, the pilot operation of the system is carried out. Depending on the content and scope of AIS tasks, trial operation lasts from three to six months.
The introduction of AIS is a rather difficult task both in organizational and technical aspects. The customer must prepare the implementation of the system. This condition requires certain organizational, professional and psychological efforts on the part of the personnel of the customer company, to some extent involved in the operation of the AIS. The administration of the company must provide such conditions under which the team of the company will have a positive attitude towards the implementation of the system and help its implementation, development and development. Then it will be possible to assume that the goal of introducing and operating AIS at the enterprise will be achieved.
6. The technique for calculating the technical economic efficiency automated information processing
One of the principal sections of the AIS project is the feasibility study of the AIS in general and the processes of automated processing of economic information in particular. This requires appropriate calculations of technical and economic efficiency.
The economic efficiency of automated data processing is ensured by the following main factors:
High speed of operations for the collection, transmission, processing and issuance of information, speed of technical means;
Maximum reduction of time to perform individual operations;
Improving the quality of data processing and information received.
The overall efficiency of automated problem solving is directly dependent on the reduction in data processing costs and is a direct economic efficiency. Achieving the effect of system-wide solutions to improve the quality of user information service provides indirect economic efficiency.
Direct economic efficiency indicators are determined by comparing the costs of data processing for several design options. In essence, this is a comparison of two options - basic and designed. The existing system of automated or traditional (manual) data processing is taken as the basic version, and the result of the modernization of the existing system or a newly developed AIS is taken as the designed version.
The absolute indicator of the economic efficiency of the developed AIS project is the reduction in annual cost and labor costs for the technological process of data processing compared to the basic version of the TPOD.
Saving financial costs due to automation of data processing is determined based on the calculation of the difference in costs of the basic and projected data processing options using the formula:
C e \u003d C b - C p (1)
where C e - the amount of cost reduction for data processing;
C b - costs for the base case;
C n - costs for the projected option.
The relative indicator of the economic efficiency of the AIS project is the cost efficiency ratio (K e) and the cost change index (I c).
K e \u003d C e / C b * 100% (2)
The cost efficiency ratio shows what part of the costs will be saved with the projected AIS option, or by how many percent the costs will be reduced.
The value of the cost change index can be determined by the formula:
I s \u003d C e / C b. (3)
This index indicates how many times the cost of data processing will be reduced during the implementation of the AIS project.
When implementing an AIS project, it is necessary to take into account additional capital costs, the value of which (K 3) can be determined by the formula:
K 3 \u003d K p - K b (4)
where K p and K b - capital costs, respectively, of the designed and basic data processing systems.
Efficiency capital costs is determined by the payback period (T) of additional capital costs for the modernization of IS:
T \u003d K 3 / C e (5)
E \u003d C e / K 3 \u003d 1 / T. (6)
Along with the calculation of cost costs, it is useful to obtain indicators of the reduction in labor costs for data processing. The absolute indicator of labor cost reduction (t) is the difference between the annual labor costs of the basic and designed data processing options:
t = T b. – T p (7)
where T b. and T p - the annual labor intensity of operation, respectively, of the basic and designed options for data processing.
The value of the relative indicator of labor cost reduction can be displayed by the labor cost reduction coefficient (K):
K t \u003d t / T b. (eight)
The index of change in labor costs (I t) characterizes the growth in labor productivity due to the development of a more labor-saving version of the data processing project, it can be determined by the formula:
I t \u003d T b / T p. (9)
The absolute labor cost reduction (P) is used to determine the potential release labor resources(performers) from the data processing system:
P \u003d (t / T f) * f (10)
where T f is the annual fund of time of one performer employed in data processing technology;
f is a coefficient reflecting the possibility of a complete release of workers, at the expense of the time fund of which the value of t was calculated.
The definition of direct savings from the implementation of the projected (modernized) data processing system is carried out on the basis of a comparison of indicators that reflect labor and cost costs for operations of both the traditional and the projected data processing system.
Saving labor costs (E tz) in the automated processing of information on the project can be determined by the formula
E tz \u003d T o6sch - T owls (11)
where T o6sh is the complexity of data processing in the traditional way with the base case;
T owls - the complexity of automated data processing in the design version.
The financial cost savings from the implementation of a project data processing option compared to a manual base case can be determined in a similar way.
The collection of initial data for substitution into the above formulas and the performance of calculations to determine the economic efficiency is carried out by registering and measuring the relevant parameters at the stages of the technological process of data processing. In addition, initial data for a long period can be obtained by analyzing the registration (technological) logs of the AIS controller and other forms of registration.
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 a short time. The solution of 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 various forms 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 they proposed became the basis for the application computer science at 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 economy information society 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 last years An approach is becoming 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 systems that implement 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 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 developing 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., methodological materials from leading domestic and international consulting and audit companies, research results of the Association 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 UE 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 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", the 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 concerns not only purely technological problems of creating and operating IS, but also approaches to business management in the information society economy.
AIS UP should meet the needs for automation and informatization throughout the organization, which sets the software developers the task of: developing a platform capable of supporting 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 operation 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, in different networks) and are used by standalone modules (Figure 1-15), maintaining logical data integrity is even more of a challenge. 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 DB synchronization. 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
To beginning of XXI century in the IT industry, the following solutions have been developed and mastered at the industrial level, 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 of 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 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 located in 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.) are used in the financial and production area 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, 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 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 business process modeling software tools process management.
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 the autonomous use of systems of this kind, we here assume the presence common card process, a general module for processing process steps, common mechanism assignment of executors and routing of jobs and data.
Thus, the technological data generated technical devices, factual data entered into the IS by users at the workplace (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 budgetary organizations in 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 with reference to functional modules, templates and print forms, 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 the functions of logistics, personnel records and payroll, however, for full implementation, the need for a scripting language (script) remains.
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 previewing 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.
However, numerous examples of successful implementation and industrial operation of the Flagman system, the growth in the number of its sales in 2001-2002 testifies to the economic efficiency of the solution for automating 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), CIES "Business Programs-Service", the journal "Accounting" and "Financial newspaper ".
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, it clarifies the goals and characteristics of the project, evaluates the quality of the results obtained, and plans the work of the next iteration.
Each iteration - completed development cycles 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:
- a step-by-step procedure that 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 specific organization and a specific 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.
Accompanying 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. The completion 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.
Description of the presentation Stages of creating AIS Models of the life cycle of AIS by slides
Life cycle 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). Preparation of a 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 it appears to 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 Assumes 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 determination 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 the shortcomings of the formulation, correct the input and output information, the forms for issuing results and the execution of documents.
User participation in the creation of AIS provides prompt and high-quality problem solving, reduces the time for the introduction of new technologies
The cascade approach has proven itself 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. Complex systems fall into this category. large quantity 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 famous models Software life cycle define AIS life cycle models - 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. result this stage is the terms of reference (development task), agreed with all interested parties.
During second stage, according to the requirements of the terms of reference, certain design solutions are 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 stage is the delivery of the finished project, and the main thing here is to convince the customer that all his requirements are fully met.
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.
Advantages 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 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 subsequent 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 negatively affects 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; current work those who made a mistake are 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. How harder 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 is also increasing. 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. However, no one guarantees that 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;
intricacies of the architecture
Difficulties in using 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 on to the next stage of the project without waiting for the current one to be 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 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 the terminology used may differ in different international standards. 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 that contains the processes, activities, and tasks that must be performed during the creation of an information system.