Draft Decree of the Government of the Russian Federation "On the creation, development and commissioning, operation of an automated information system for project activities" Cloud solution for automating the project activities of bodies state power"and amendments to some acts of the Government of the Russian Federation" (prepared by the Ministry of Telecom and Mass Communications of Russia on February 15, 2018)

Project dossier

Explanatory note

In order to implement the Regulations on the organization of project activities in the Government of the Russian Federation, approved by the Decree of the Government of the Russian Federation of October 15, 2016. N1050, The Government of the Russian Federation decides:

1. Approve the attached:

Regulations on the automated information system for project activities "Cloud solution for automating the project activities of public authorities";

Action plan ("road map") for the creation, development and commissioning, operation of the automated information system for project activities "Cloud solution for automating the project activities of public authorities" for 2018-2020 (hereinafter referred to as the Action Plan);

Changes that are made to some acts of the Government of the Russian Federation.

2. Determine:

The Ministry of Telecom and Mass Communications of the Russian Federation - the state customer and operator of the automated information system for project activities "Cloud solution for automating the project activities of public authorities" (hereinafter, respectively - AISPD);

The Federal Project Office is the authorized body for the maintenance of AISPD.

3. Federal project office, federal executive authorities to ensure:

a) implementation of the Action Plan;

b) connection of information systems of federal executive authorities within the framework of project activities with AISPD and electronic interaction of these information systems with AISPD;

c) use of AISPD in project activities.

4. Recommend to the executive authorities of the constituent entities of the Russian Federation and authorities local government ensure the use of AISPD or the integration of own information systems with AISPD within the framework of project activities.

5. The Ministry of Telecom and Mass Communications of the Russian Federation quarterly, before the 15th day of the month following the reporting quarter, submit to the Government of the Russian Federation a report on the implementation of the Action Plan.

6. Establish that the measures provided for by this resolution are carried out by federal executive bodies within the established powers and within the budgetary allocations provided for federal law on the federal budget for the relevant financial year and planning period, on leadership and management in the field of established functions.

7. Provide for the allocation in 2018 of budget allocations from reserve fund Government of the Russian Federation to finance activities for the creation of AISPD.

8. Provide for the allocation of federal budget allocations from 2019 for the implementation of measures for the development and operation of AISPD.

Approved
Government Decree
Russian Federation

Position
on the automated information system of project activities "Cloud solution for automation of project activities of public authorities"

1. Automated information system for project activities "Cloud solution for automation of project activities of public authorities" (hereinafter referred to as AISPD) provides the solution of the following tasks:

a) information support for project activities in the Government of the Russian Federation, including the federal project office, federal executive authorities, executive authorities of the constituent entities of the Russian Federation, local governments, as well as other organizations (hereinafter referred to as state authorities and organizations) participating in project activities;

b) information support of permanent and temporary management bodies of project activities of state authorities and organizations engaged in the initiation and implementation of projects (programs);

c) information interaction of information providers and users of information contained in AISPD;

d) operational and objective monitoring of the implementation of projects (programs);

e) interaction with citizens on the implementation of projects (programs) and project initiatives;

f) maintaining electronic forms reporting;

g) information support of the incentive system for participants in project activities, including accounting for performance indicators.

2. The fulfillment of the tasks specified in paragraph 1 of these Regulations is carried out through the following functions of AISPD:

a) support for the adoption of managerial decisions based on prompt and objective monitoring of the implementation of projects (programs);

b) management of projects (programs), a portfolio of projects (programs) in authorities at various levels according to a single methodology, including:

accounting and maintenance (maintenance) of project proposals;

initiation of projects (programs), ranking and formation of a portfolio of projects (programs);

preparation of the project (program);

project (program) implementation and project (program) change management;

completion of the project (program);

monitoring the implementation of projects (programs);

analysis, evaluation and other control measures for the implementation of projects (programs);

c) obtaining information on the implementation of projects (programs) from various external sources;

d) use of electronic reporting on project activities;

e) formation of statistically reliable information on the status of implementation of projects (programs);

f) accounting and calculation of personal and project performance indicators, motivation of permanent and temporary management bodies and participants in project activities;

g) information interaction of public authorities and organizations and information systems used by them in the process of project management and obtaining information for objective monitoring of the implementation of projects (programs);

h) interaction and work with documents of permanent and temporary management bodies of project activities within a single information space;

i) interaction with citizens, organizations and other interested persons and on the implementation of projects (programs) and project initiatives;

j) formation of a single source of reliable information about project activities in authorities at various levels, the availability of information about projects (programs) for public authorities and organizations.

3. Participants of information interaction are:

a) AISPD operator;

b) information providers in AISPD;

c) users of information contained in AISPD.

4. Information providers in AISPD are:

a) public authorities and organizations carrying out project activities;

b) public authorities and organizations that collect, process and analyze information necessary for objective monitoring of the implementation of projects (programs).

5. The users of information processed in AISPD are the federal project office, permanent and temporary bodies for managing project activities of state authorities and organizations engaged in project activities.

6. The authorized body for maintaining AISPD performs the following functions:

a) coordinates the formation and development of an automated information system for project activities;

b) monitors the implementation and operation of AISPD;

c) approves, in agreement with the AISPD operator, the requirements for the AISPD software;

d) determines, in agreement with the AISPD operator, the directions for the development of AISPD;

e) provides methodological support for the functioning and development of AISPD.

7. AISPD operator provides:

a) functioning of the AISPD, including the operability of the software and hardware of the AISPD;

b) creation, development and commissioning, operation of AISPD, including in terms of support and development of technical and software AISPD for different types of projects in agreement with the Authorized body for maintaining AISPD;

c) reception, storage, provision of AISPD data;

d) the integrity and availability of AISPD data for participants in information interaction;

e) protection of information and data created and processed within the framework of the functioning of AISPD;

f) differentiation of access rights of participants in information interaction;

g) connection and (or) provision of access to AISPD;

h) obligatory accounting and registration of all actions and identification of all participants;

i) technological and other interaction of AISPD with external information systems;

j) methodological support on the technical use and content of AISPD;

k) uploading and updating classifiers, reference books and other reference information used in AISPD into the Federal State Information System "Unified System of Reference Information".

8. Information providers in AISPD provide:

a) providing information to AISPD in the prescribed manner;

b) the relevance and reliability of the information provided in the AISPD;

c) performance of own software and hardware used when working with AISPD;

d) providing the Authorized body for the maintenance of AISPD with proposals for the development of AISPD.

9. Providing access to AISPD is carried out in relation to the responsible executors of permanent and temporary project management bodies who have passed the identification and authentication procedure through the federal state information system "Unified Identification and Authentication System" in the infrastructure that provides information and technological interaction of information systems used to provide state and municipal services in electronic form.

10. AISPD software and hardware must meet the following requirements:

a) are located on the territory of the Russian Federation;

b) ensure the placement of information in the state language of the Russian Federation;

c) have valid certificates issued by Federal Service security of the Russian Federation and (or) the Federal Service for Technical and Export Control in relation to their information security tools, including software and hardware, anti-virus and cryptographic information protection tools and information protection tools from unauthorized access, destruction, modification and access blocking to it, as well as from other illegal actions in relation to such information;

d) provide automated maintenance of electronic logs of transactions carried out in AISPD, with fixation of the placement, change and deletion of information, the exact time of such transactions, the content of the changes and information about the AISPD participants who performed these actions;

e) provide access for responsible executors of permanent and temporary project management bodies to AISPD, uninterrupted maintenance of databases and protection of information contained in AISPD from unauthorized access;

f) provide the possibility of information interaction of AISPD with other information systems, including through the use of infrastructure elements that provide information and technological interaction of information systems used to provide state and municipal services in electronic form;

g) ensure the identification and authentication of responsible executors of permanent and temporary project management bodies in AISPD using unified system identification and authentication;

h) provide the possibility of obtaining information from AISPD in the form of files and electronic messages;

i) ensure the safety of all versions of created documents and the history of changes.

11. AISPD ensures the unity of the reference information used.

12. Information interaction of AISPD with federal state information systems, information systems of state authorities is carried out using a unified system of interdepartmental electronic interaction, with other organizations using a secure data transmission network, the organization of which is provided by the AISPD operator.

13. Technical standards and requirements for technological compatibility of AISPD with external information systems, requirements for standards and protocols for the exchange of documents of AISPD with external information systems are established by the AISPD operator in accordance with the requirements of the legislation of the Russian Federation in the field of information technology.

14. Determination and clarification of the composition of information, formats for their provision, suppliers and consumers of information generated in AISPD, is carried out by the federal project office, taking into account the decisions of the working group under the presidium of the Council under the President of the Russian Federation for strategic development and priority projects (hereinafter referred to as the Council) and may be considered by the Council's presidium at the suggestion of the federal project office.

15. The information contained in AISPD is subject to protection in accordance with the legislation of the Russian Federation on information, information technologies and information protection, the legislation of the Russian Federation on personal data.

16. The protection of information contained in AISPD is ensured through the application of organizational and technical measures for protecting information, as well as monitoring the operation of AISPD.

17. In the manner and cases established by the legislation of the Russian Federation, the provision of information about projects (programs) in electronic form using AISPD is carried out using an enhanced qualified electronic signature.

18. Public authorities and organizations, as well as responsible persons involved in project activities, are responsible for the completeness and accuracy of information about projects (programs), information about the status of implementation of projects (programs), as well as for compliance with the procedure and deadlines for their submission to AISPD.

Approved
Government Decree
Russian Federation
dated "__" _______ 2018 N _______

Plan
activities ("road map") for the creation, development and commissioning, operation of the automated information system for project activities "Cloud solution for automating the project activities of public authorities" for 2018-2020

I. General provisions

1. Implementation of the action plan ("road map") for the creation, development and commissioning, operation of the automated information system for project activities "Cloud solution for automating the project activities of public authorities" for 2018-2020 (hereinafter referred to as the "road map") is aimed at improving the effectiveness and efficiency of project management in the Government of the Russian Federation, federal bodies executive authorities, executive authorities of the constituent entities of the Russian Federation, local governments, as well as other organizations, including through the introduction automated system to manage projects (programs) according to a unified methodology, create a single information space for the interaction of permanent and temporary project management bodies, transition to electronic document management in project activities.

Standardization of approaches to project management, the use of a cloud solution for automating the project activities of public authorities will reduce the administrative burden on public authorities while increasing the level of project management efficiency.

In this regard, it is necessary to introduce modern information technologies in terms of automating the project activities of public authorities.

2. The purpose of the "road map" is to optimize the labor, material and financial resources used in the planning, implementation and monitoring of projects (programs).

II. General characteristics and main results

Efficiency booster government controlled is the transition to project management using a unified methodology and automation of project management processes.

The results of the implementation of the "road map" are:

creation, development, commissioning and operation of the automated information system for project activities "Cloud solution for automating the project activities of public authorities";

adoption of relevant regulatory legal acts in order to introduce automation of project management in public authorities and organizations.

Based on the results of the implementation of the road map, it is planned to provide on the basis of common standards and methodological approaches the necessary level of information interaction between public authorities and organizations of information systems used by them in the process of project management, automate constant and monotonous processes, increase the validity of decisions made, automate the collection and analysis of summary information on the results of the implementation of projects (programs), switch to electronic reporting on projects (programs), as well as to increase the availability of this information for public authorities.

III. Action Plan

Approved
Government Decree
Russian Federation
dated "__" _______ 2018 N _______

changes,
which are included in some acts of the Government of the Russian Federation

1. Subparagraph "a" of paragraph 2 of the Regulation on the infrastructure that provides information and technological interaction of information systems used to provide state and municipal services and perform state and municipal functions in electronic form, approved by Decree of the Government of the Russian Federation on June 8, 2011 N 451 " On the infrastructure providing information and technological interaction of information systems used to provide state and municipal services and perform state and municipal functions in electronic form" (Sobraniye Zakonodatelstva Rossiyskoy Federatsii, 2011, No. 24, Art. 3503; No. 44, Art. 6274; No. 49, article 7284; 2012, No. 39, article 5269; No. 53, article 7938; 2013, No. 27, article 3612; No. 41, article 5188; No. 45, article 5827; No. 52, article 7218; 2014, N 30, item 4318; N 48, item 6876; N 50, item 7113; 2016, N 34, item 5247; 2017, N 41, item 5981; N 44, item 6523 ) add the following paragraph:

"automated information system for project activities "Cloud solution for automation of project activities of public authorities.""

2. In subparagraph "b" of paragraph 4 of the Regulations on the state automated information system "Management", approved by Decree of the Government of the Russian Federation of December 25, 2009 N 1088 "On the state automated information system" Management "(Collected Legislation of the Russian Federation, 2010, N 1, item 101; 2011, N 38, item 5380; 2013, N 1, item 65; N 48, item 6259; 2015, N 2, item 459, 460; N 10, item 1524; N 49, item 6972) the words "and the implementation of priority national projects" shall be deleted.

3. In the position regarding the main event 4.2, Appendix No. 4 to the state program of the Russian Federation "Information Society (2011 - 2020)", approved by the Decree of the Government of the Russian Federation of April 15, 2014 N 313 "On Approval of the State Program of the Russian Federation" Information Society (2011 - 2020) "Collected Legislation of the Russian Federation, 2014, N 18, Art. 2159; 2015, N 9, Art. 1341; N 26, Art. 3896; 2016, N 44, Art. 6139; 2017, N 9, item 1366; N 11, item 1573; N 15, item 2214; N 34, item 5289; N 45, item 6661; N 47, item 7007; 2018, N 4, item 623 ), in the column "Main directions of implementation":

a) after paragraph thirty-two "development of the federal state information system" Federal Situation Center e-government";" add the following paragraph:

"creation and development of an automated information system for project activities "Cloud solution for automating the project activities of public authorities";"

b) after paragraph thirty-four "operation of the federal state information system "Federal Situational Center for Electronic Government";" add the following paragraph:

"commissioning and operation of the automated information system for project activities "Cloud solution for automating the project activities of public authorities";".

Document overview

Proposed Regulations on AIS project activities "Cloud solution for automating the project activities of state authorities."

Tasks - information support of permanent and temporary management bodies of project activities of authorities and organizations that initiate and implement projects (programs); information support of project activities; information interaction of providers and users of information contained in the AIS; operational and objective monitoring of the implementation of projects (programs); interaction with citizens on the implementation of projects (programs) and project initiatives; maintenance of electronic reporting forms; information support of the incentive system for project participants.

An Action Plan ("road map") for the creation, development and commissioning, operation of AIS for 2018-2020 is given.

Nbsp; AIS life cycle models

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 sustainable development stages, practically independent of the subject area (Fig. 1.1).

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 of the terms of reference, certain design solutions are developed. The result is a set project documentation.

The 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 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 of risk and unreliability of investments.

Delay in getting results 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 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; 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 consists in 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 solutions. 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.

disadvantages 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 increases. technical solutions by creating prototypes.

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 each iteration - as soon as possible to create a workable product for demonstration to users. 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 the products of third-party companies instead of their own developments as components (relevant in a market economy, when it is necessary to resist the promotion of competitors' products);

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.

Modern methodologies and AIS design technologies that implement them are supplied in in electronic format together with CASE-tools and include libraries of processes, templates, methods, models and other components intended for building software of that class of systems to which the methodology is oriented. Electronic methodologies and technologies form the core of a set of harmonized AIS development tools. Features of modern methodological solutions for the design of AIS cannot be implemented without certain design technologies that correspond to the scale and specifics of the project.

AIS design technology- this is a set of methods and tools for designing AIS, as well as methods and tools for organizing design (managing the process of creating and modernizing an AIS project).

According to the design TP, AIS is a set of series-parallel, connected and subordinate chains of actions, each of which can have its own subject. The actions that are performed during the design of AIS can be defined as indivisible technological operations or as sub-processes. technological operations. All actions can be design, that shape or modify design results, and appraisal, which are developed according to the established criteria for evaluating the results of design.

Thus, the design technology is set by a regulated sequence of technological operations performed in the process of creating a project based on a particular method.

The subject of the chosen design technology should be the reflection of interrelated design processes at all stages of the AIS life cycle.

The main requirements for the selected design technology are as follows:

The project created using this technology must meet the requirements of the customer;

The technology should maximally reflect all stages of the project life cycle;

The technology should provide minimum labor and cost costs for design and project maintenance;

technology should contribute to the growth of labor productivity of designers;

The technology must ensure the reliability of the design and operation of the project;

The technology should facilitate the simple maintenance of project documentation.

AIS design technology implements a certain design methodology. In turn, the design methodology presupposes the existence of a certain concept, design principles and is implemented by a set of methods and tools.

AIS design methods can be classified according to the degree of use of automation tools, standard solutions projects, and adaptability to expected changes.

According to the degree of automation, there are:

manual design, in which the design of AIS components is carried out without the use of special software tools; programming is done in algorithmic languages;

computer design, in which the generation or configuration (setting) of design solutions is carried out using special software tools.

According to the degree of use of standard design solutions, there are:

original (individual) design, when design solutions are developed from scratch in accordance with the requirements for AIS;

standard design, which assumes the configuration of AIS from ready-made standard design solutions (software modules).

original design AIS assumes the maximum consideration of the features of the automated object.

Typical design is carried out on the basis of ready-made solutions and is a generalization of the experience gained earlier when creating related projects.

According to the degree of adaptability of design solutions The following methods are distinguished:

reconstruction- adaptation of design solutions is carried out by processing the relevant components (reprogramming of software modules);

parameterization- design solutions are adjusted in accordance with the specified and changeable parameters;

model restructuring- the domain model changes, which leads to automatic re-formation of design solutions.

The combination of various features of the classification of design methods determines the nature of the AIS design technology used. There are two main classes of design technology: canonical And industrial. Industrial design technology is divided into two subclasses: automated(using CASE technologies) and typical(parametric-oriented or model-oriented) design.

Table 1.1.Characteristics of design technology classes

Canonical AIS Design focused on the use of mainly cascade model of the AIS life cycle.

Depending on the complexity of the automation object and the set of tasks that need to be solved when creating a specific AIS, the stages and stages of work may have different complexity. It is allowed to combine successive stages and exclude some of them at any stage of the project. It is also allowed to start the work of the next stage before the end of the previous one.

The stages and stages of the creation of AIS, performed by participating organizations, are prescribed in contracts and terms of reference for the performance of work.

Stage 1 Formation of requirements for AIS:

survey of the object and justification of the need to create an AIS;

Formation of user requirements for AIS;

preparation of a report on the work performed and a tactical and technical assignment for development.

Stage 2 Development of the AIS concept:

study of the object of automation;

Carrying out the necessary research work;

· development of variants of the AIS concept that meet the requirements of users;

preparation of the report and approval of the concept.

Stage 3 Technical task:

Development and approval of terms of reference for the creation of AIS.

Stage 4 Preliminary design:

development of preliminary design solutions for the system and its parts;

development sketch documentation on AIS and its parts.

Stage 5 Technical project:

development of design solutions for the system and its parts;

development of documentation for AIS and its parts;

development and execution of documentation for the supply of components;

· development of tasks for designing in adjacent parts of the project.

Stage 6 Working documentation:

· development of working documentation for AIS and its parts;

development and adaptation of programs.

Stage 7 Commissioning:

preparation of the automation object; staff training;

· complete set of AIS with supplied products (software and hardware, software and hardware complexes, information products);

construction and installation works; commissioning works;

Carrying out preliminary tests;

carrying out trial operation;

Conducting acceptance tests.

Stage 8 Accompanying AIS:

performance of work in accordance with warranty obligations;

post-warranty service.

Survey is the study and analysis of the organizational structure of the enterprise, its activities and existing system information processing.

The materials obtained as a result of the survey are used for:

Rationale for the development and phased implementation of systems;

Preparation of terms of reference for the development of systems;

Development of technical and working projects of systems.

At the survey stage, it is advisable to distinguish two components: the definition of an AIS implementation strategy and a detailed analysis of the organization's activities.

The main task of the first stage of the survey is to assess the real scope of the project, its goals and objectives based on the identified functions and information elements of a high-level automated object. These tasks can be implemented either by the AIS customer independently or with the involvement of consulting organizations. The stage involves close interaction with the main potential users of the system and business experts. The main task of interaction is to get a complete and unambiguous understanding of the customer's requirements. As a rule, the necessary information can be obtained as a result of interviews, conversations or seminars with management, experts and users.

At the end of the survey stage, it becomes possible to determine the likely technical approaches to the creation of the system and to estimate the costs of its implementation (for hardware, for purchased software and for the development of new software).

The result of the strategy definition stage is a document (feasibility study - feasibility study - project), which clearly states what the customer will receive if he agrees to finance the project, when he will receive the finished product (work schedule) and how much it will cost (for large projects - this is a schedule of financing at different stages of work). It is desirable to reflect in the document not only the costs, but also the benefits of the project, for example, the payback time of the project, the expected economic effect (if it can be estimated).

Limitations, risks, critical factors that may affect the success of the project;

The set of conditions under which it is supposed to operate the future system - system architecture, hardware and software resources, operating conditions, service staff and users of the system;

Deadlines for the completion of individual stages, the form of acceptance / delivery of work, attracted resources, measures to protect information;

Description of the functions performed by the system;

Opportunities for development and modernization of the system;

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

requirements for software and database management systems (DBMS).

At the stage of a detailed analysis of the organization's activities, activities that ensure the implementation of management functions, organizational structure, staffing and content of work on enterprise management, as well as the nature of subordination to higher management bodies are studied. Here it is necessary to outline instructive, methodological and directive materials, on the basis of which the composition of subsystems and the list of tasks are determined, as well as the possibilities of applying new methods for solving problems.

Analysts collect and record information in two interrelated forms:

Functions - information about events and processes that occur in an automated organization;

Entities - information about classes of objects that are important to the organization and about which data is collected.

When studying each functional task of management, the following are determined:

Task name; terms and frequency of its decision;

The degree of formalizability of the task;

Sources of information necessary to solve the problem;

Indicators and their quantitative characteristics;

The procedure for correcting information;

Operating algorithms for calculating indicators and possible methods of control;

Operating means of collecting, transmitting and processing information;

Operating means of communication;

Accepted accuracy of the problem solution;

The complexity of solving the problem;

The current forms of presentation of the initial data and the results of their processing in the form of documents;

Consumers of the resulting information on the task.

One of the most time-consuming, although well formalized, tasks of this stage is the description of the organization's workflow. When examining the document flow, a diagram of the document movement route is drawn up, which should reflect:

Number of documents;

Place of formation of indicators of documents;

The relationship of documents in their formation;

The route and duration of the movement of the document;

Place of use and storage of this document;

Internal and external information communications;

The volume of the document in characters.

Based on the results of the survey, a list of tasks I of management to be automated is established, and the sequence of their development.

During the survey phase, the planned functions of the system should be classified in order of importance. One possible format for representing such a classification is MuSCoW. This abbreviation stands for: Must have - necessary functions; Should have - desirable functions; Could have - I possible functions; Won "t have - missing functions.

The functions of the first category provide critical for I successful work opportunity systems. The implementation of the functions of the second and third categories is limited by the time and financial framework: the necessary, as well as the maximum possible number of functions of the second and third categories, in order of priority, are being developed. The last category of features is especially important because you need to be clear about the boundaries of Project I and the set of features that will be missing from the system.

Organization activity models are created in two types 1 :

The “as is” model reflects the business processes existing in the op-I organization;

The “to be” model reflects the necessary changes in business processes, taking into account the introduction of AIS. j

Already at the analysis stage, it is necessary to involve testing groups in the work to solve the following tasks:

Obtaining comparative characteristics of hardware platforms, operating systems, DBMS, etc. intended for 1 use;

Development of a work plan to ensure the reliability of AIS and its testing.

Involving testers in the early stages of development is appropriate for any project. The later errors in design decisions are discovered, the more expensive their correction is; the worst option is their detection at the implementation stage. Thus, the sooner testing teams begin to identify errors in the AIS, the lower the cost of working on the system. Time for testing the system and correcting the detected errors should be provided not only at the development stage, but also at the design stage.

Special bug tracking systems are designed to facilitate and increase the efficiency of testing. Using them allows you to have a single repository of errors, track their reappearance, control the speed and efficiency of fixing errors, see the most unstable components of the system, and also maintain communication between the development team and the testing team.

The results of the survey represent an objective basis for the formation of the terms of reference for the AIS.

Technical task is a document that defines the goals, requirements and basic input data necessary for the development of an automated control system.

When developing the terms of reference (TOR), it is necessary to solve the following tasks:

· install common goal creation of AIS;

Establish general requirements for the system being designed;

· develop and substantiate the requirements for information, mathematical, software, technical and technological support;

determine the composition of subsystems and functional tasks;

develop and justify the requirements for subsystems;

determine the stages of creating the system and the timing of their implementation;

carry out a preliminary calculation of the costs of creating a system and determine the level economic efficiency implementation;

determine the composition of the performers.

Typical requirements for the composition and content of the terms of reference are given in Table. 1.6.

Table 1.6. The composition and content of the terms of reference (GOST 34.602-89)

Exclusive project provides for the development of preliminary design solutions for the system and its parts. The implementation of preliminary design is not a strictly mandatory stage. If the main design decisions are defined earlier or are sufficiently obvious for a specific AIS and automation object, then this stage can be excluded from the overall sequence of work.

AIS functions;

Functions of subsystems, their goals and expected effect from implementation;

The composition of task complexes and individual tasks;

Concept information base and its enlarged structure;

Functions of the database management system;

The composition of the computer system and other technical means;

Functions and parameters of the main software tools.

Based on the results of the work done, documentation is drawn up, agreed and approved in the amount necessary to describe the full set of design decisions made and sufficient for further work to create the system.

In accordance with GOST 19.102-77, the preliminary design stage contains two stages: development of a preliminary design; approval of the draft design.

The first stage of development consists of:

Preliminary development of the structure of input and output data;

Refinement of methods for solving the problem;

Developments general description problem solving algorithm;

Development of a feasibility study;

Development of an explanatory note.

At the same time, it is allowed to combine and exclude some works.

Below is a set of documents that should and can be prepared at the end of the draft design.

Required Documents:

1) revised terms of reference for the design and development
AIS operation;

2) specification qualification requirements on AIS;

3) a set of requirements specifications for functional software components and data descriptions;

4) specification of requirements for the internal interfaces of the components and interfaces with the external environment;

5) description of the database management system, structure and distribution of program and information objects in the database;

6) draft guidelines for information security and ensuring the reliability of the functioning of the AIS;

7) draft AIS administrator's manual;

8) draft version of the AIS user manual;

9) updated project implementation plan;

10) an updated AIS quality assurance management plan;

11) explanatory note of the preliminary draft AIS;

12) specified contract (agreement) with the customer for details
new design of AIS.

Documents drawn up in agreement with the customer:

1) a preliminary description of the functioning of the AIS;

2) scheme of data flows between the functional components of the AIS;

3) a refined scheme of the AIS architecture, the interaction of software and information components, the organization of the computing process and the allocation of resources;

4) a description of the quality indicators of the components and requirements for them according to the stages of AIS development;

5) report on technical and economic indicators, project implementation schedule, allocation of resources and budget;

6) table of distribution of specialists by components and by stages of work;

7) certificates of developers for the right to use technology and automation tools for the development of AIS;

8) description of the requirements for the composition and forms of the resulting documents by stages of work;

9) a plan for debugging software components, providing it with methods and means of test automation;

10) preliminary guidance for detailed design
vaniya, programming and debugging AIS components;

11) preliminary sales and implementation plan;

12) description of the preliminary structure of the database.

Technical project systems are technical documentation containing system-wide design solutions, problem solving algorithms, as well as an assessment of the economic efficiency of AIS. At this stage, a set of research and experimental work is carried out to select the main design solutions and calculate the economic efficiency of the system. The composition and content of the technical project are given in table. 1.7

Table 1.7. Content of the technical project

At the stage of "Working documentation" the creation of a software product and the development of all accompanying documentation are carried out. The documentation must contain 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. The developed documentation must be properly executed, agreed and approved.

At the "Commissioning" stage for AIS, the following main types of tests are established: preliminary tests, pilot operation and acceptance tests. If necessary, additional tests of the system and its parts are allowed.

Depending on the relationship between the AIS components and the automation object, tests can be autonomous and complex. Autonomous tests involve system components. They are carried out as parts of the system are ready for commissioning for trial operation. Comprehensive tests are carried out for groups of interconnected components (subsystems) or for the system as a whole.

To plan all types of tests, the document "Program and Test Methods" is being developed. The developer of the document is established in the contract or TK. As an appendix, tests or test cases may be included in the document.

Debugging is the most time-consuming design process. Hidden errors sometimes appear after many years of operation of the system. It is impossible to completely avoid errors, due to the astronomical number of options for the system. It is almost impossible to check them all for correct operation in the foreseeable future.

The cost of identifying and fixing bugs at later stages of design increases roughly exponentially (Figure 1.10).

Researchers count 169 types of errors, summarized in 19 large classes:

1) logical;

2) data manipulation errors;

3) input-output errors;

4) errors in calculations;

Rice. 1.10. Relative cost of finding and fixing a single bug

5) errors in user interfaces;

6) errors in the operating system and auxiliary programs;

7) layout errors;

8) errors in interprogram interfaces;

9) errors in the interfaces "Program - system software";

10) errors when handling external devices;

11) errors in pairing with the database (DB);

12) database initialization errors;

13) errors of changes upon request from outside;

14) errors related to global variables;

15) repeated mistakes;

16) mistakes in documentation;

17) violation technical requirements;

18) unidentified errors;

19) operator errors.

Not all bugs come from the developer. According to various researchers, from 6 to 19% of errors are generated by errors in the documentation.

The ratio of development and testing at various stages of AIS design is shown in fig. 1.11.

This chain is only conditionally “stretched” into a line. Inside it there are always return cycles. To identify errors, developers create special tests and conduct a debugging stage. If no errors are found, this does not mean that there are none - maybe the test turned out to be too weak.

Rice. 1.11. Ratio of development and testing by AIS design stages

The debugging technique takes into account the symptoms of possible errors:

Incorrect processing (wrong answer, result) - up to 30%;

Incorrect transfer of control - 16%;

Incompatibility of programs with the data used - 15%;

Incompatibility of programs on the transferred data - up to 9%.

When developing debugging tasks, the following tasks are solved:

Compilation of tests;

Selection of points, zones and control routes;

Determination of the list of controlled values ​​and the procedure for fixing their values;

Setting the order of testing;

Assessment of the reliability and complexity of debugging.

The program being debugged must go through each branch of the algorithm at least once and at the same time assign a series of values ​​to the variables, capturing the boundaries of the range, several values ​​within it, zero values ​​and special points (if any). For specialized systems develop special debugging languages. They may contain a relatively small number of commands (20-30) with additional settings for solving the following tasks:

output management;

Modeling the execution process of the debugged program;

Issuing the state of the memory components in the process of executing programs;

Checking the conditions for achieving certain states in the process of program execution;

Establishment of test values ​​of initial data;

Implementation of conditional transitions in testing depending on the results of execution of other macros or various tests;

Performing office operations to prepare the program for testing.

The debugging process cannot be attributed to a fully formalized one, so there are empirical recommendations for its implementation, which are given below.

1. Take a semantic, premeditated approach to debugging, plan your debugging process, and carefully design your test datasets from the simplest options, eliminating the most likely sources of bugs.

2. To streamline the testing process, collect and analyze information:

About the features and statistics of errors;

About the specifics of the initial data and the sequence of changing variables in the program and their mutual influence;

On the structure of the algorithm and the features of its software implementation.

3. Locate only one error at a time.

Use tools for recording and displaying information about errors, including special debugging code in the program to print out sample values ​​of variables, messages about the end of individual sections of the program, tracing, logical conditions, etc.

5. Carefully study the received output data and compare them with the expected, pre-calculated results.

6. Pay attention to the data, carefully analyze the operation of the program when using boundary values ​​and with incorrect input; control data types, ranges, field sizes, and precision.

7. Use data and control flow analysis to validate and define data domains for different program execution paths.

8. Use various debugging tools at the same time, without stopping at one possibility. Involve automated tools and simultaneously manual debugging and testing, checking the program text from the point of view of functioning, taking into account the most likely errors.

9. Document all bugs found and fixed, their differences, location and type. This information will be useful in preventing future errors.

10. Measure the complexity of programs. Programs of high complexity are more likely to have specification and design errors, while those of low complexity are more prone to coding and clerical errors.

11. To increase experience and practice debugging, artificially place errors in programs. After a certain period of debugging, the programmer should point out the remaining and undetected errors. Such "seeding" is widely used to estimate the number of undetected errors (if both artificial and real errors are uniformly detected and corrected, then by the percentage of detected introduced and real errors, one can assume how many of them are left).

Preliminary tests are carried out to determine the operability of the system and decide whether it is possible to accept it for trial operation. Preliminary tests should be carried out after the developer has debugged and tested the supplied software and hardware of the system and submitted the relevant documents on their readiness for testing, as well as after familiarizing the AIS personnel with the operational documentation.

Trial operation of the system is carried out in order to determine the actual values ​​of the quantitative and qualitative characteristics of the system and the readiness of personnel to work in the conditions of its operation, as well as to determine the actual effectiveness and adjust, if necessary, documentation.

Acceptance tests are carried out to determine the compliance of the system with the terms of reference, assess the quality of trial operation and decide whether the system can be accepted for permanent operation.

Stages of development of CASE-systems

Over the past decade, a new direction in the design of information systems has emerged - computer-aided design using CASE-tools. The term CASE (Computer Aided System/Software Engineering) originally referred only to software development automation; it now covers the development of complex AIS in general.

Initially, CASE technologies were developed in order to overcome the shortcomings of the structural design methodology (complexity of understanding, high labor intensity and cost of use, difficulty in making changes to design specifications, etc.) through automation and integration of supporting tools.

CASE-technologies do not exist by themselves, they are not independent. They automate and optimize the use of the relevant methodology, and make it possible to increase the efficiency of its application.

In other words, CASE technologies are a set of methodologies for the analysis, design, development and maintenance of complex software systems, supported by a set of interconnected automation tools that allow you to visually model the subject area, analyze this model at all stages of development and maintenance of AIS and develop applications in accordance with the information needs of users .

Modern CASE tools cover a wide range of support for numerous AIS design technologies - from simple analysis and documentation tools to full-scale automation tools covering the entire AIS life cycle. The greatest need for the use of CASE-systems is experienced at the initial stages of development - at the stages of analysis and specification of requirements for AIS. The mistakes made here are almost fatal, their cost far exceeds the cost of errors in the later stages of development.

The main objectives of CASE tools are to separate the initial stages (analysis and design) from subsequent ones and not burden developers with the details of the development environment and system operation.

Most modern CASE systems use methodologies structural and/or object-oriented analysis And design, based on the use of visual diagrams, graphs, tables and diagrams.

With proper use of CASE-tools, a significant increase in labor productivity is achieved, amounting (according to foreign companies using CASE technologies) from 100 to 600%, depending on the volume, complexity of work and experience with CASE. At the same time, all phases of the AIS life cycle change, but the greatest changes relate to the analysis and design phases (Tables 2.5, 2.6) .

Table 2.5. Estimates of labor costs by phases of the AIS life cycle

Table 2.6. Comparison of using CASE and traditional development

The use of CASE-tools not only automates the structural methodology and makes it possible to use modern methods of system and software engineering, but also provides other advantages (Fig. 2.22), in particular:

1. improves the quality of the software being developed by means of automatic generation and control;

2. allows to reduce the time of creating an AIS prototype, which makes it possible to assess the quality and effectiveness of the project at an early stage;

3. accelerates the design and development process;

4. allows you to reuse the developed components;

5. supports AIS tracking;

6. frees from the routine work of documenting the project, as it uses the built-in documenter;

7. Facilitates teamwork on a project.

Rice. 2.22. Advantages of AIS development using CASE-technologies: but- coefficient of project cost reduction; b - development time reduction factor

Most CASE tools are based on four main concepts: methodology, method, notation, tool [ 11,15, 16].

Methodology defines guidelines for the evaluation and selection of solutions in the design and development of AIS, stages of work, their sequence, rules for the distribution and assignment of methods.

Methods - procedures for generating components and their descriptions.

Notations intended to describe overall structure systems, data elements, processing steps, may include graphs, charts, tables, flowcharts, formal and natural languages.

Facilities- tools to support and enhance methods; supports the work of users when creating and editing a project in interactive mode, helps to organize the project in the form of a hierarchy of abstraction levels, checks the conformity of components.

Classification of CASE tools

Until now, there is no stable classification of CASE-tools, only approaches to classification depending on various classification features have been defined. Below are some of them.

Orientation to the technological stages and processes of the AIS life cycle:

1. means of analysis and design. Used to create system specifications and design. They support well-known design methodologies;

2. database design tools. Provide logical data modeling, generation of database structures;

3. requirements management tools;

4. software configuration management tools. Support programming, testing, automatic generation of software from specifications;

5. means of documentation;

6. testing tools;

7. project management tools. Support planning, control, interaction;

8. reverse engineering tools designed to transfer an existing system to a new environment.

Supported design methodologies[ 11, 12, 15, 16]:

1. functionally oriented (structurally oriented);

2. object-oriented;

3. complex-oriented (a set of design methodologies).

Supported graphical charting notations:

1. with fixed notation;

2. with separate notations;

3. with the most common notations.

Degree of integration:

1. auxiliary programs (Tools), independently solving an autonomous task;

2. development packages (Toolkit), which are a set of tools that provide assistance for one of the classes of software tasks;

3. sets of integrated tools linked by a common design database - a repository, automating all or part of the work of different stages of creating AIS (Workbench).

Collective development of the project:

1. without the support of collective development;

2. focused on the development of the project in real time;

3. focused on the mode of combining subprojects.

Types of CASE tools:

1. analysis tools (Upper CASE); among specialists are called means of computer planning. With the help of these CASE-tools, a model is built that reflects all the existing specifics. It is aimed at understanding the general and particular mechanisms of functioning, available opportunities, resources, project goals in accordance with the purpose of the company. These tools allow you to analyze various scenarios, accumulating information for making optimal decisions;

2. analysis and design tools (Middle CASE); are considered to support the requirements analysis and design phases of AIS specifications and structure. The main result of using the middle CASE tool is a significant simplification of system design, as the design becomes an iterative process of working with AIS requirements. In addition, medium CASE tools provide fast documentation of requirements;

3. software development tools (Lower); support AIS software development systems. They contain system dictionaries and graphical tools that eliminate the need to develop physical specifications - there are system specifications that are directly translated into program codes of the system being developed (up to 80% of codes are automatically generated). The main advantages of the lower CASE-tools are a significant reduction in development time, facilitation of modifications, support for the ability to work with prototypes.

CASE tools also classify by type and architecture computer science, as well as type operating system .

Currently the market software products It is represented by a wide variety of software, including CASE-tools of almost any of the listed classes.

Characteristics of CASE tools

silver run. The Silverrun CASE tool of the American company Computer Systems Advisers, Inc. (CSA) is used for the analysis and design of business class AIS and is focused more on the spiral life cycle model. It is applicable to support any methodology based on the separate construction of functional and information models (data flow diagrams and entity-relationship diagrams).

Tuning to a specific methodology is provided by choosing the required graphical notation of models and a set of rules for checking design specifications. The system has ready-made settings for the most common methodologies: DATARUN (the main methodology supported by Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. For each concept introduced in the project, it is possible to add your own descriptors. The Silverrun architecture allows you to grow your development environment as needed.

Silverrun has modular structure and consists of four modules, each of which is an independent product and can be purchased and used separately.

1. Module for building business process models in the form of data flow diagrams, Business Process Modeler (BPM) allows you to model the functioning of an automated organization or an AIS being created. The ability to work with models of great complexity is provided by the functions of automatic renumbering, working with the process tree (including visual drag and drop of branches), detaching and attaching parts of the model for collective development. Charts can be drawn in several predefined notations, including Yourdon/DeMarco and Gane/Sarson. It is also possible to create your own notations, for example, add user-defined fields to the number of descriptors displayed on the diagram.

2. Conceptual data modeling module Entity-Relationship eXpert (ERX) enables the construction of entity-relationship data models that are not implementation-specific. The built-in expert system allows you to create a correct normalized data model by answering meaningful questions about the relationship of data. Automatic construction of a data model from descriptions of data structures is provided. Analysis of the functional dependencies of attributes makes it possible to check the compliance of the model with the requirements of the third normal form and ensure their implementation. The validated model is passed to the Relational Data Modeler module.

3. Relational Modeling Module Relational Data Modeler (RDM) allows you to create detailed entity-relationship models designed to be implemented in a relational database. This module documents all the structures related to building a database: indexes, triggers, stored procedures, etc. The flexible notation and extensibility of the repository allow you to work with any methodology. The ability to create subschemas is consistent with the ANSI SPARC approach to representing a database schema. In the language of subcircuits, both distributed processing nodes and user views are modeled. This module provides design and complete documentation of relational databases.

4. Workgroup Repository Manager Workgroup Repository Manager (WRM) is used as a data dictionary for storing information common to all models, and also provides integration of Silverrun modules into a single design environment.

The advantage of the Silverrun CASE tool is its high flexibility and variety of pictorial tools for building models, and the disadvantage is the lack of strict mutual control between the components of different models (for example, the ability to automatically propagate changes between DFDs of different decomposition levels). It should be noted, however, that this shortcoming can be significant only if the cascade life cycle model is used.

Tools included in Silverrun:

1. automatic generation of database schemas for the most common DBMS: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase;

2. data transfer to application development tools: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi.

Thus, it is possible to fully define the database engine using all the features of a particular DBMS: triggers, stored procedures, referential integrity constraints. When you create an application, the data migrated from the Silverrun repository is used either to automatically generate interface objects or to quickly create them manually.

To exchange data with other design automation tools, create specialized procedures for analyzing and verifying design specifications, and compiling specialized reports in accordance with various standards, Silverrun provides three ways to issue design information to external files.

1. Reporting system. Reports are output to text files.

2. Export/import system. Not only the contents of the export file are set, but also the delimiters of records, fields in records, markers of the beginning and end of text fields. Such export files can be generated and uploaded to the repository. This makes it possible to exchange data with various systems: other CASE tools, DBMS, text editors and spreadsheets.

3. Storing the repository in external files with access using ODBC drivers. To access repository data from the most common DBMS, it is possible to store all project information directly in the format of these DBMS.

Silverrun supports two ways to group work:

1) in the standard single-user version there is a mechanism for controlled separation and merging of models. The model can be divided into parts and distributed among several developers. After a detailed study, the parts are again assembled into a single model;

2) the network version of Silverrun allows parallel group work with models stored in a network repository based on Oracle, Sybase or Informix DBMS. At the same time, several developers can work with the same model, since the blocking of objects occurs at the level of individual elements of the model.

JAM. JYACC's Application Manager (JAM) is a JYACC product. Main Feature is the compliance with the RAD methodology, since JAM allows you to quickly implement the application development cycle, which consists in generating the next version of the application prototype, taking into account the requirements identified in the previous step, and presenting it to the user.

JAM has a modular structure and consists of the following components:

1. system core;

2. JAM/DBi - specialized DBMS interface modules (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC, etc.);

3. JAM/RW - report generator module;

4. JAM/CASEi - specialized interface modules for CASE tools (JAM/CASE-TeamWork, JAM/CASE-Inno-vator, etc.);

5. JAM/TPi - specialized interface modules for transaction managers (for example, JAM/TPi-Server TUXEDO, etc.);

6. Jterm - a specialized X-terminal emulator.

The core of the system is a finished product and can be independently used for application development. All other modules are optional and cannot be used independently.

The core of the system includes the following main components:

1. screen editor. The screen editor includes a screen development environment, a visual object repository, its own JAM DBMS - JDB, a transaction manager, a debugger, a style editor;

2. menu editor;

3. a set of auxiliary utilities;

4. means of manufacturing an industrial version of the application.

When using JAM, the development of the external interface of an application is a visual design and comes down to creating screen forms by placing interface structures on them and defining on-screen information input / output fields. Interface design in JAM is done using screen editor. Applications developed in JAM have a multi-window interface. The development of the screen consists in placing interface elements on it, grouping them, setting the values ​​of their properties.

Menu editor allows you to develop and debug menu systems. Implemented the ability to build pictographic menus. Assigning menu items to application objects is done in the screen editor.

The JAM kernel has a JDB single-user relational DBMS built into it. The main purpose of JDB is to prototype applications in cases where working with a standard DBMS is impossible or impractical. JDB implements the necessary minimum of relational DBMS capabilities, which does not include indexes, stored procedures, triggers, and views. Using JDB, you can build a database that is identical to the target database (up to the features missing in JDB) and develop a significant part of the application.

The debugger allows you to carry out complex debugging of the developed application. All events that occur during application execution are traced.

Utilities JAM includes three groups:

1) Converters of JAM screen files to text. JAM saves screens as binary files of its own format;

2) configuring I/O devices. JAM and applications built with it do not work directly with I/O devices. Instead, JAM accesses logical I/O devices (keyboard, terminal, report);

3) maintenance of screen libraries.

One of the optional JAM modules is report generator. The layout of the report is carried out in the JAM screen editor. Description of the report is carried out using a special language. The report generator allows you to define the data to be output to the report, the grouping of output information, output formatting, etc.

Applications developed using JAM can be made into executable modules. To do this, developers must have a C compiler and a linker.

JAM contains built-in programming language JPL (JAM Procedural Language), with which, if necessary, modules that implement specific actions can be written. This language is interpreted. It is possible to exchange information between the visually built application environment and such modules. In addition, JAM implements the ability to connect external modules written in languages ​​that are compatible in function calls with the C language.

Jam is event driven system consisting of a set of events - opening and closing windows, pressing a keyboard key, triggering a system timer, receiving and transferring control over each element of the screen. The developer implements the application logic by defining a handler for each event.

event handlers JAM can have both built-in JAM functions and functions written by the developer in C or JPL. The set of built-in functions includes more than 200 functions for various purposes; they are available for calls from functions written in both JPL and C.

Industrial version of the application, developed with JAM, consists of the following components:

1. executable module of the application interpreter;

2. screens that make up the application (delivered as separate files, as part of screen libraries, or built into the body of the interpreter);

3. external JPL modules (supplied as text files or precompiled; precompiled

4. external JPL-modules - as separate files and as part of screen libraries);

5. application configuration files - keyboard and terminal configuration files, system messages file, general configuration file.

Direct interaction with the DBMS is implemented by the JAM/DBi (Database interface) modules. Ways to implement interaction in JAM are divided into two classes: manual and automatic.

At manual way the developer independently writes SQL queries, in which the sources and destinations for receiving the results of the query execution can be both interface elements of a visually designed external level, and internal variables invisible to the end user.

Auto mode implemented by the JAM transaction manager. It is feasible for typical common types of database operations, the so-called QBE (Query By Example - queries according to the model), taking into account the rather complex relationships between database tables and automatic control attributes of on-screen I/O fields depending on the type of transaction (read, write, etc.) in which the generated request participates.

JAM allows you to build applications to work with more than 20 DBMS: ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, ODBC-compatible DBMS, etc.

A distinctive feature of JAM is a high level of application portability between different platforms (MS DOS/MS Windows, SunOS, Solaris (i80x86, SPARC), HP-UX, AIX, VMS/Open VMS, etc.); perhaps a requirement to "redraw" static text fields on screens with Russian text when porting between DOS-Windows-UNIX environments. In addition, portability is facilitated by the fact that in JAM, applications are developed for virtual I/O devices rather than physical ones. Thus, when porting an application from platform to platform, as a rule, it is only necessary to determine the correspondence between physical I / O devices and their logical representations for the application.

Using SQL as a means of interfacing with the DBMS also helps ensure portability between DBMSs. In the case of a database structure transfer, applications may not require any modification, except for session initialization. This is possible if the application did not use DBMS-specific SQL extensions.

With an increase in the load on the system and the complexity of the tasks being solved (distribution and heterogeneity of the resources used, the number of simultaneously connected users, the complexity of the application logic), three-tier architecture model"client - server" using transaction managers. The JAM/TPi-Client and JAM/TPi-Server components make it quite easy to switch to a three-tier model. In this case, the JAM/TPi-Server module plays a key role, since the main difficulty in implementing the three-tier model lies in the implementation of application logic in transaction manager services.

The JAM/CASE interface allows information to be exchanged between the JAM object repository and the CASE tool repository. The exchange is similar to how the database structure is imported into the JAM repository directly from the database. The difference is that the exchange between repositories is bidirectional.

In addition to the JAM / CASEi modules, there is also a JAM / CASEi Developer "s Kit module. Using this module, you can independently develop an interface (i.e., a specialized JAM / CASEi module) for a specific CASE tool, if there is a ready-made JAM / CASEi module for it does not exist.

There is an interface that implements the interaction between the Silverrun CASE tool and JAM. It transfers the database schema and application screen forms between the Silverrun-RDM CASE tool and JAM version 7.0; has two modes of operation:

1) direct mode (Silverrun-RDM->JAM) is designed to create CASE dictionary objects and JAM repository elements based on schema representation in Silverrun-RDM. Based on the representation of interface data models in Silverrun-RDM, screens and elements of the JAM repository are generated. The bridge converts the RDM relational schema tables and relationships into a sequence of JAM objects of the appropriate types. The technique for building interface data models in Silverrun-RDM involves the use of a subscheme mechanism for prototyping application screens. Based on the description of each of the RDM subcircuits, the bridge generates a JAM screen;

2) the reverse mode (JAM->Silverrun-RDM) is designed to transfer modifications of CASE-dictionary objects to the Silverrun-RDM relational model.

The reengineering mode allows you to transfer modifications of all properties of JAM screens previously imported from RDM to the Silvcrrun schema. To control the integrity of the database, schema changes in the form of adding or deleting tables and table fields are not allowed.

The JAM kernel has a built-in interface to configuration management tools (PVCS on the Windows platform and SCCS on the UNIX platform). Screen libraries and/or repositories are transferred under the control of these systems. In the absence of such systems, JAM independently implements some of the functions to support team development.

On the MS-Windows platform, JAM has a built-in interface to PVCS and the fetch/revert actions are done directly from the JAM environment.

Vantage Team Builder (Westmount I-CASE). Vantage Team Builder is an integrated implementation-oriented software product with full support for the Waterfall Lifecycle Model.

Vantage Team Builder provides the following features:

1. designing data flow diagrams, entity-relationship diagrams, data structures, block diagrams programs and sequences of screen forms;

2. designing system architecture diagrams - SAD (designing the composition and connection of computing facilities, distributing system tasks between computing facilities, modeling client-server relationships, analyzing the use of transaction managers and real-time system functioning features);

3. generation of program code in the language of the target DBMS with full software environment and generation of SQL code for creating database tables, indexes, integrity constraints and stored procedures;

4. programming in C with embedded SQL;

5. versioning and project configuration management;

6. multi-user access to the project repository;

7. generation of design documentation for standard and individual templates;

8. export and import of project data in CDIF format (CASE Data Interchange Format).

Vantage Team Builder comes in various configurations depending on the database management system (ORACLE, Informix, Sybase, or Ingres) or application development tools (Uniface) used. The configuration of Vantage Team Builder for Uniface differs from the rest by partially focusing on a spiral life cycle model due to rapid prototyping capabilities. A large set of diagrams is used to describe the AIS project.

When constructing all types of diagrams, control is provided for the conformity of models to the syntax of the methods used, as well as control for the correspondence of elements of the same name and their types for various types of diagrams.

When constructing diagrams of DFD data flows, control over the conformity of diagrams of different levels of decomposition is provided. The top-level DFD is validated using the ELM event list matrix. To control the decomposition of composite data streams, several options for their description are used: in the form data structure diagrams DSD or in notations BNF (form of Backus - Naur).

To build SAD, an extended DFD notation is used, which makes it possible to introduce the concepts of processors, tasks, and peripheral devices, which provides clarity of design decisions.

When building a data model in the form of ERD, it is normalized and the definition of the physical names of data elements and tables is introduced, which will be used in the process of generating the physical data schema of a particular DBMS. It provides the ability to determine alternative keys of entities and fields that make up additional entry points to the table (fields of indexes), and the cardinality of relationships between entities.

The presence of a universal code generation system based on the specified means of access to the project repository allows maintaining a high level of execution of the project discipline by developers: a strict procedure for generating models; rigid structure and content of the documentation; automatic generation of program source codes, etc.; all this ensures an increase in the quality and reliability of the developed IS.

Publishing systems such as FrameMaker, Interleaf or Word Perfect can be used to prepare project documentation. The structure and composition of project documentation are configured in accordance with the specified standards. Adjustment is carried out without changing the design decisions.

When developing large AIS, the entire system as a whole corresponds to one project as a category of Vantage Team Builder. The project can be decomposed into a number of systems, each of which corresponds to some relatively autonomous AIS subsystem and is developed independently of the others. In the future, project systems can be integrated.

The AIS design process using Vantage Team Builder is implemented in four consecutive phases (stages) - analysis, architecture, design And implementation, at the same time, the completed results of each stage are fully or partially transferred (imported) to the next phase. All diagrams, except for ERD, are converted to another type or change their appearance in accordance with the features of the current phase. Thus, DFDs are converted in the architecture phase to SAD, DSDs to DTDs. After the import is completed, the logical connection with the previous phase is broken, i.e., all necessary changes can be made to the diagrams.

The Vantage Team Builder for Uniface configuration provides the sharing of two systems within a single technological design environment, while the database schemas (SQL models) are transferred to the Uniface repository, and vice versa, application models generated by Uniface tools can be transferred to the Vantage Team Builder repository . Possible discrepancies between the repositories of the two systems are eliminated using a special utility. Development of screen forms in the Uniface environment is performed on the basis of FSD form sequence diagrams after importing the SQL model. The AIS development technology based on this configuration is shown in fig. 2.23.

The structure of the repository stored in the target DBMS and the Vantage Team Builder interfaces are open, which in principle allows integration with any other tools.

Uniface. The Compuware product is a large-scale application development environment in the client-server architecture and has the following component architecture:

1. Application Objects Repository (repository of application objects) contains metadata automatically used by all other components throughout the life cycle of AIS (application models, data descriptions, business rules, screen forms, global objects and templates). The repository can be stored in any of the databases supported by Uniface;

Rice. 2.23. Interaction between Vantage Team Builder and Uniface

2. Application Model Manager supports application models (E-R models), each of which is a subset of the overall database schema from the point of view of this application, and includes the corresponding graphics editor;

3. Rapid Application Builder - Tool quick creation screen forms and reports based on application model objects. Includes a graphical form editor, prototyping, debugging, testing and documentation tools. Implemented an interface with various types of window controls Open Widget Interface for existing graphical interfaces - MS Windows (including VBX), Motif, OS/2. The Universal Presentation Interface allows you to use the same version of the application in the environment of different graphical interfaces without changing the program code;

4. Developer Services (developer services) are used to support large projects and implement version control (Uniface Version Control System), access rights (delimitation of powers), global modifications, etc. This provides developers with the means of parallel design, input and output control, searching, viewing, maintaining and issuing reports on the data of the version control system;

5. Deployment Manager (application distribution management) - tools that allow you to prepare the created application for distribution, install and maintain it (the user's platform may differ from the developer's platform). They include network and DBMS drivers, application server (polyserver), application distribution and database management tools. Uniface supports interface with almost all known hardware and software platforms, DBMS, CASE-tools, network protocols and transaction managers;

6. Personal Series (personal tools) are used to create complex queries and reports in graphical form (Personal Query and Personal Access - PQ / PA), as well as to transfer data to systems such as WinWord and Excel;

7. Distributed Computing Manager - integration tool with Tuxedo, Encina, CICS, OSF DCE transaction managers.

The Uniface 7 version fully supports the distributed computing model and the three-tier client-server architecture (with the ability to change the application decomposition scheme at runtime). Applications created using Uniface 7 can be executed in heterogeneous operating environments using various network protocols, simultaneously on several heterogeneous platforms (including the Internet).

Uniface 7 components include:

1. Uniface Application Server - application server for distributed systems;

2. WebEnabler - server software for operating applications on the Internet and intranet;

3. Name Server - server software that ensures the use of distributed application resources;

4. PolyServer - a means of accessing data and integrating various systems.

Supported DBMS include DB2, VSAM, and IMS; PolyServer also provides interoperability with the MVS OS.

Designer/2000 + Developer/2000. ORACLE's Designer/2000 2.0 is an integrated CASE tool that, in conjunction with the Developer/2000 application development tools, provides full software lifecycle support for systems using the ORACLE DBMS.

Designer/2000 is a family of methodologies and their supporting software products. Basic methodology Designer/2000 (CASE*Method) is a structural system design methodology that fully covers all stages of the AIS life cycle. At the planning stage, the goals of creating the system, priorities and limitations are determined, the system architecture and the AIS development plan are developed. In the process of analysis, the following are built: an information needs model (an entity-relationship diagram), a functional hierarchy diagram (based on the AIS functional decomposition), a cross-reference matrix and a data flow diagram.

At the design stage, a detailed AIS architecture is developed, a relational database schema and program modules are designed, cross-references are established between AIS components to analyze their mutual influence and control changes.

At the implementation stage, a database is created, application systems are built, they are tested, quality checked, and compliance with user requirements is checked. Created system documentation, training materials and user manuals. At the stages of operation and maintenance, the performance and integrity of the system are analyzed, support and, if necessary, modification of the AIS is performed.

Designer/2000 provides a graphical interface for developing various domain models (diagrams). In the process of building models, information about them is entered into the repository. Designer/2000 includes the following components.

Send your good work in the knowledge base is simple. Use the form below

Students, graduate students, young scientists who use the knowledge base in their studies and work will be very grateful to you.

Posted on http://www.allbest.ru/

Ministry of Education and Science of the Russian Federation

federal state budgetary educational institution higher professional education

Saint Petersburg State University technology and design

Course work

By discipline: "Architecture of information systems"

On the topic: "Design of automated information systems"

INTRODUCTION

At present, computer technology is becoming more widespread both in production and in the workflow of enterprises, and the list of tasks covered by it is becoming ever wider. The volume and complexity of processed information is constantly growing, and new types of its presentation are required.

Here are just some of the benefits that the use of computing technology provides in the work of an organization:

* Possibility of operational control over the reliability of information;

* Reducing the number of possible errors when generating derived data;

* Possibility of fast access to any data;

* Ability to quickly generate reports;

ѕ Saving labor costs and time spent on information processing.

All these advantages are currently appreciated by many organizations, so today there is a process of rapid development of automated information systems and their introduction into the work of various institutions. In this regard, the topic I have chosen is very relevant at the present time.

The main feature of the industry of automation systems of various enterprises and institutions, characterized by a wide range of input data with different routes for processing this data, is the concentration of complexity at the initial stages of requirements analysis and design of system specifications with relatively low complexity and labor intensity of subsequent stages. In fact, this is where the understanding of what the future system will do and how it will work in order to satisfy the requirements presented to it takes place. Namely, the fuzziness and incompleteness of system requirements, unresolved issues and errors made at the stages of analysis and design, give rise to difficult, often insoluble problems at subsequent stages and, ultimately, lead to the failure of the whole work. Simple replication of even a very good enterprise management system will never fully satisfy the customer, since it cannot take into account its specifics. Moreover, in this case, there is a problem of choosing exactly the system that is most suitable for a particular enterprise. And this problem is further complicated by the fact that the keywords characterizing various information systems are practically the same:

ѕ Unified information environment of the enterprise;

* Real time mode;

ѕ Independence from legislation;

ѕ Integration with other applications (including systems already running at the enterprise);

* Phased implementation, etc.

In fact, the problem of integrated automation has become relevant for every enterprise. And to engage in complex automation, you need structured knowledge in this area.

The purpose of this work: To get acquainted with the concept of automated information systems, to consider the design process.

To achieve the goal, it is necessary to solve the following tasks:

§ Formulate definitions of basic concepts and terms;

§ Consider the goals and objectives of design;

§ Get acquainted with the main stages of design;

§ Identify the phases of development of automated information systems;

§ Consider the composition and structure of the terms of reference and the technical project.

1. DEFINITION OF THE CONCEPTS AUTOMATED INFORMATION SYSTEM (AIS), INFORMATION SYSTEM (IS), PROJECT AND DESIGN

When structuring processes in the sphere of human activity, different methods of isolating components (subprocesses) are used and various results are obtained, such as research and development, analysis and synthesis, etc.

It is entirely acceptable to consider design as a generalizing concept for many intellectual tasks that are solved in the process of thinking and distinguished in different ways.

The root of the word design emphasizes the connection between the process with this name and the main results of this process, these are:

a) projection - that which is obtained by analyzing complex phenomena in order to obtain simplified representations, and

b) design - what is obtained by synthesizing complex representations from a set of simpler images.

The above two reasons have justified the current choice of the word design as a term denoting the essence of the main activity that is carried out in computer science.

In the design of information systems, the design objects are information systems, and this is quite natural for computer science (since IS are considered its main objects).

As you know, information systems are capable of reflecting the most diverse phenomena of the universe, and, therefore, all phenomena also turn out to be potential design objects.

Information systems in many cases turn out to be the subjects of design, i.e. those performers who carry out the design process itself. By studying the design process, we are thus largely engaged in the study of information systems.

A system is understood as any object that is simultaneously considered both as a single whole and as a set of heterogeneous elements united in the interests of achieving the set goals. Systems differ significantly from each other both in composition and in main goals.

In computer science, the concept of a system is widespread and has many semantic meanings. Most often it is used in relation to a set of hardware and software. The addition of the word information system to the concept reflects the purpose of its creation and functioning. Information systems ensure the collection, storage, processing, search, and issuance of information necessary in the process of making decisions on tasks from any area. They help analyze problems and create new products.

Information system (IS) - an interconnected set of tools, methods and personnel used to store, process and issue information in order to achieve the goal.

Modern information technologies provide a wide range of ways to implement IS, the choice of which is based on the requirements of the intended users, which, as a rule, change during the development process.

The addition of the term "automated" to the concept of "system" reflects the ways in which such a system is created and operated.

An automated system (according to GOST) is a system consisting of an interconnected set of organizational units and a set of automation tools that implements automated functions for certain types activities.

Automated information system (AIS) is a complex of software, technical, information, linguistic, organizational and technological tools and personnel designed to solve the problems of reference and information services and (or) information support users.

An automated information system is a collection of information, economic and mathematical methods and models, technical, software, technological tools and specialists designed to process information and make management decisions.

The main purpose of automated information systems is not just to collect and store electronic information resources, but also to provide users with access to them. One of the most important features of AIS is the organization of data search in their information arrays (databases).

Under the AIS project we will understand the design and technological documentation, which provides a description of the design solutions for the creation and operation of the IS in a specific software and hardware environment.

The following main distinguishing features of the project as a management object can be distinguished:

Limitation of the final goal;

limited duration;

limited budget;

limited resources required;

novelty for the enterprise for which the project is being implemented;

complexity;

legal and organizational support.

Considering the planning of projects and their management, it is necessary to clearly realize that we are talking about the management of a certain dynamic object. Therefore, the project management system must be flexible enough to allow modification without global changes in work program. The performance of work is ensured by the availability of the necessary resources: materials; equipment; human resources. From the point of view of the theory of control systems, the project as a control object must be observable and manageable, that is, some characteristics are distinguished by which it is possible to constantly monitor the progress of the project. In addition, mechanisms are needed to influence the progress of the project in a timely manner.

AIS design is understood as the process of converting input information about an object, methods and experience in designing objects of a similar purpose in accordance with GOST into an IS project.

From this point of view, AIS design is reduced to a consistent formalization of design decisions at various stages of the AIS life cycle: planning and analysis of requirements, technical and detailed design, implementation and operation of AIS.

The scale of the systems being developed determines the composition and number of participants in the design process. With a large volume and tight deadlines for the implementation of design work, several design teams (developing organizations) can take part in the development of the system. In this case, a parent organization is allocated, which coordinates the activities of all co-executing organizations.

AIS design technology is a set of methodology and AIS design tools, as well as methods and tools for organizing it (managing the process of creating and modernizing an AIS project).

The design technology is based on a technological process that determines the actions, their sequence, the required composition of performers, tools and resources.

The technological process of AIS design as a whole is divided into a set of series-parallel, connected and subordinate chains of actions, each of which can have its own subject. Thus, the design technology is set by a regulated sequence of technological operations performed on the basis of a particular method, as a result of which it becomes clear not only what must be done to create a project, but also how, by whom and in what sequence.

The subject of any chosen design technology should be the reflection of interrelated design processes at all stages of the AIS life cycle. The main requirements for the selected design technology include the following:

The created project must meet the requirements of the customer;

maximum reflection of all stages of the project life cycle;

ensuring minimum labor and cost costs for design and project maintenance;

technology should be the basis of communication between design and project maintenance;

· growth of labor productivity of the designer;

Reliability of the design and operation of the project;

Simple maintenance of project documentation.

The basis of AIS design technology is a methodology that defines the essence, the main distinctive technological features.

The design methodology presupposes the existence of a certain concept, design principles, implemented by a set of methods, which, in turn, must be supported by some means.

The design organization involves the definition of methods for the interaction of designers with each other and with the customer in the process of creating an AIS project, which can also be supported by a set of specific tools.

information system computer-aided design

2. PURPOSE AND OBJECTIVES OF DESIGN

The design of information systems always begins with the definition of the purpose of the project. The purpose of the design is the selection of technical and the formation of information, mathematical, software and organizational and legal support.

The selection of technical support should be such as to ensure the timely collection, registration, transfer, storage, filling and processing of information.

Information support should provide for the creation and operation of a single information fund of the system, represented by a variety of information arrays, a data set or a database.

The formation of mathematical software for systems includes a set of methods and algorithms for solving functional problems. When forming the system software, special attention is paid to the creation of a set of programs and user instructions and the choice of effective software products.

The main task of any successful project is to ensure that at the time of system launch and during the entire period of its operation it is possible to provide:

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

the required throughput of the system;

the required response time of the system to a request;

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

ease of operation and support of the system;

necessary security.

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

The design of automated information systems covers three main areas:

designing data objects that will be implemented in the database;

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

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

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

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

3. STAGES OF DESIGN

The process of creating AIS is divided into a number of stages (stages), limited by some time frame and ending with the release of a specific product.

Each project, regardless of the complexity and amount of work required for its implementation, goes through certain stages in its development. From the state when “there is no project yet” to the state when “the project is no longer there”. The set of stages of development from the emergence of an idea to the completion of the project is usually divided into phases.

The purpose of the initial stages of creating AIS, performed at the stage of analysis of the organization's activities, is the formation of requirements for AIS that correctly and accurately reflect the goals and objectives of the customer organization. To specify the process of creating an AIS that meets the needs of the organization, it is necessary to find out and clearly articulate what these needs are. To do this, it is necessary to determine the requirements of customers for AIS and display them in the language of models in the requirements for the development of the AIS project so as to ensure compliance with the goals and objectives of the organization.

The following phases of development of automated information systems can be distinguished:

3.1 Formation of the concept. Concept phase

This includes:

Formation of an idea;

Formation of a key project team;

study of the motivations and requirements of the customer and other participants;

collection of initial data and analysis of the existing state;

determination of the basic requirements and restrictions, required material, financial and labor resources;

Comparative evaluation of alternatives;

submission of proposals, their examination and approval.

The task of forming requirements for AIS is one of the most responsible, difficult to formalize and the most expensive and difficult to correct in case of an error. Modern tools and software products allow you to quickly create AIS according to ready-made requirements. But often these systems do not satisfy customers, require numerous improvements, which leads to a sharp rise in the cost of the actual cost of AIS. The main reason for this situation is the incorrect, inaccurate or incomplete definition of AIS requirements at the analysis stage.

3.2 Preparation of a technical proposal

§ development of the main content of the basic structure of the project;

§ development and approval of terms of reference;

§ planning, decomposition of the basic structural model of the project;

§ drawing up estimates and budget of the project;

§ development calendar plans and enlarged work schedules;

§ signing a contract with the customer;

§ commissioning of means of communication of project participants and means of monitoring the progress of work.

3.3 Design

At the design phase, subsystems, their relationships are determined, the most effective ways of designing and using resources are selected. Characteristic works of this phase:

§ implementation of basic design work;

§ development of private technical specifications;

§ implementation of conceptual design;

§ preparation of technical specifications and instructions;

§ presentation of design development, examination and approval.

At the design stage, first of all, data models are formed. Designers receive the results of the analysis as initial information. Building logical and physical data models is a major part of database design. The information model obtained during the analysis is first converted into a logical and then into a physical data model.

3.4 Development

At the development phase, coordination and operational control of work on the project is carried out, subsystems are manufactured, combined and tested.

After the autonomous test is successfully passed, the module is included in the developed part of the system and the group of generated modules passes the link tests, which should track their mutual influence.

Next, a group of modules is tested for reliability, that is, they pass, firstly, tests of simulating system failures, and secondly, tests of the time between failures. The first group of tests shows how well the system recovers from software failures, hardware failures. The second group of tests determines the degree of system stability during normal operation and allows you to evaluate the system uptime. The stability test suite should include tests that simulate the peak load on the system.

Then the entire set of modules passes a system test - a test of internal acceptance of the product, showing the level of its quality. This includes functionality tests and system reliability tests.

The last test of an automated information system is acceptance testing. Such a test involves showing the information system to the customer and should contain a group of tests that simulate real business processes.

3.5 Commissioning the system

At the system commissioning phase, tests are being carried out, trial operation of the system is underway in real conditions, negotiations are underway on the results of the project and on possible new contracts.

Main types of work:

§ complex tests;

§ training for operation created system;

§ preparation of working documentation, delivery of the system to the customer and its commissioning;

§ support, support, service maintenance;

§ Evaluation of project results and preparation of final documents.

4. COMPOSITION AND STRUCTURE OF THE TERMS OF REFERENCE AND TECHNICAL PROJECT

1. General Provisions

1.1. The terms of reference (TOR) is the main document that defines the requirements and procedure for creating (development or modernization - further creation) of an information system, in accordance with which the development of an IS is carried out and its acceptance upon commissioning.

1.2. TK is developed for the system as a whole, designed to work independently or as part of another system.

1.3. The requirements for IP in the scope established by this standard can be included in the assignment for the design of a newly created informatization object. In this case, TK is not developed.

1.4. The requirements included in the TOR must correspond to the current level of development of information technologies and not be inferior to similar requirements for the best modern domestic and foreign analogues. The requirements specified in the TOR should not limit the system developer in the search and implementation of the most effective technical, feasibility and other solutions.

1.5. The TOR includes only those requirements that supplement the requirements for systems of this type and are determined by the specifics of the particular object for which the system is being created.

1.6. Changes to the TOR are formalized by an addendum or a protocol signed by the customer and the developer. The addendum or the specified protocol is an integral part of the TOR on the IP. On the title page of the TK there should be an entry "Valid from ...".

2. Composition and content

2.1. The TOR contains the following sections, which can be divided into subsections:

1) general information;

2) purpose and goals of creation (development) of the system;

3) characteristics of objects;

4) system requirements;

5) the composition and content of work to create the system;

6) procedure for control and acceptance of the system;

7) requirements for the composition and content of work to prepare the development object for putting the system into operation;

8) requirements for documentation;

9) development sources.

Applications may be included in the ToR.

2.2. Depending on the type, purpose, specific features of the project and the operating conditions of the system, it is allowed to draw up sections of the TOR in the form of applications, introduce additional, exclude or combine subsections of the TOR.

The TOR for parts of the system does not include sections that duplicate the content of the sections of the TOR as a whole.

2.3. In the "General information" section indicate:

1) the full name of the system and its symbol;

2) cipher of the topic or cipher (number) of the contract;

3) the name of the companies of the developer and the customer (user) of the system and their details;

4) a list of documents on the basis of which the system is created, by whom and when these documents were approved;

5) planned dates for the start and completion of work on the creation of the system;

6) information about the sources and procedure for financing the work;

7) the procedure for formalizing and presenting to the customer the results of work on the creation of the system (its parts), on the manufacture and adjustment of individual means (hardware, software, information) and software and hardware (software and methodological) complexes of the system.

2.4. The section "Purpose and objectives of the creation (development) of the system" consists of subsections:

1) purpose of the system;

2) the purpose of creating the system.

2.4.1. In the subsection "Purpose of the system" indicate the type of activity of the system (management, design, etc.) and the list of informatization objects (objects) on which it is supposed to be used.

2.4.2. In the subsection “Goals of creating a system”, the names and required values ​​\u200b\u200bof the technical, technological, production-economic or other indicators of the informatization object that must be achieved as a result of creating an IS are given, and indicate the criteria for assessing the achievement of the goals of creating a system.

2.5. In the section "Characteristics of the object of informatization" they give:

1) brief information about the object of informatization or links to documents containing such information;

2) information about the operating conditions of the automation object.

2.6. The System Requirements section consists of the following subsections:

1) requirements for the system as a whole;

2) requirements for the functions (tasks) performed by the system;

3) requirements for types of collateral.

The composition of the system requirements included in this section of the TOR for IS is established depending on the type, purpose, specific features and operating conditions of a particular system.

2.6.1. In the subsection "Requirements for the system as a whole" indicate:

requirements for the structure and functioning of the system;

requirements for the number and qualifications of the personnel of the system and the mode of its work;

destination indicators;

reliability requirements;

safety requirements;

requirements for ergonomics and technical aesthetics;

requirements for operation, maintenance, repair and storage of system components;

requirements for the protection of information from unauthorized access;

requirements for the safety of information in case of accidents;

requirements for protection from the influence of external influences;

requirements for patent purity;

requirements for standardization and unification;

Additional requirements.

2.6.1.1. The requirements for the structure and functioning of the system include:

1) a list of subsystems, their purpose and main characteristics, requirements for the number of hierarchy levels and the degree of centralization of the system;

2) requirements for methods and means of communication for information exchange between system components;

3) requirements for the characteristics of the interconnections of the system being created with related systems, requirements for its compatibility, including instructions on how to exchange information (automatically, by sending documents, by phone, etc.);

4) requirements for the operating modes of the system;

5) requirements for diagnosing the system;

6) prospects for development, modernization of the system.

2.6.1.2. In the requirements for the number and qualifications of personnel on IS, the following are given:

§ requirements for the number of personnel (users) of IS;

§ requirements for the qualification of personnel, the procedure for their training and control of knowledge and skills;

§ the required mode of work of the IS personnel.

2.6.1.3. In the requirements for indicators of the purpose of IS, the values ​​of the parameters characterizing the degree of compliance of the system with its purpose are given.

2.6.1.4. Reliability requirements include:

1) the composition and quantitative values ​​of reliability indicators for the system as a whole or its subsystems;

2) a list of emergency situations for which reliability requirements should be regulated, and the values ​​of the corresponding indicators;

3) requirements for the reliability of hardware and software;

4) requirements for methods for assessing and monitoring reliability indicators at different stages of creating a system in accordance with the current regulatory and technical documents.

2.6.1.5. The safety requirements include requirements for ensuring safety during the delivery, commissioning, operation and maintenance of the system.

2.6.1.6. The requirements for ergonomics and technical aesthetics include IS indicators that specify the required quality of human-machine interaction and the comfort of personnel working conditions.

2.6.1.7. The requirements for protecting information from unauthorized access include the requirements established by the industry and the information environment of the customer.

2.6.1.8. In the requirements for the safety of information, a list of events is given: accidents, failures of technical means (including power loss), etc., in which the safety of information in the system must be ensured.

2.6.1.9. The requirements for patent purity indicate a list of countries in respect of which the patent purity of the system and its parts must be ensured.

2.6.1.10. Additional requirements include special requirements at the discretion of the system developer or customer.

2.6.2. In the subsection "Requirements for the functions (tasks)" performed by the system, the following is given:

§ for each subsystem, a list of functions, tasks or their complexes (including those ensuring the interaction of parts of the system) to be automated;

§ when creating a system in two or more queues - a list of functional subsystems, individual functions or tasks put into effect in the 1st and subsequent queues;

§ time schedule for the implementation of each function, task (or set of tasks);

§ requirements for the quality of implementation of each function (task or set of tasks), for the form of presentation of output information, characteristics of the required accuracy and execution time, requirements for the simultaneity of the execution of a group of functions, the reliability of the results;

§ list and failure criteria for each function for which reliability requirements are specified.

2.6.3. In the subsection “Requirements for the types of support”, depending on the type of system, requirements are given for mathematical, informational, linguistic, software, technical, metrological, organizational, methodological and other types of support for the system.

2.6.3.2. For the information support of the system, the following requirements are given:

1) to the composition, structure and methods of organizing data in the system;

2) to information exchange between system components;

3) to information compatibility with adjacent systems;

4) on the use of database management systems;

5) to the structure of the process of collecting, processing, transferring data in the system and presenting data;

6) to data protection;

7) control, storage, updating and recovery of data;

2.6.3.3. For the linguistic support of the system, requirements are given for the use of high-level programming languages ​​in the system, user interaction languages ​​and technical means of the system, as well as requirements for data coding and decoding, data input-output languages, data manipulation languages, means of describing the subject area, and methods organization of the dialogue.

2.6.3.4. For the system software, a list of purchased software is given, as well as requirements:

1) to the dependence of software on the operating environment;

2) to the quality of software, as well as to the methods of its provision and control;

2.6.3.5. For the technical support of the system, the following requirements are given:

1) to the types of technical means, including the types of complexes of technical means, software and hardware complexes and other components that are acceptable for use in the system;

2) to the functional, constructive and operational characteristics of the technical support of the system.

2.6.3.6. The requirements for metrological support include:

1) a preliminary list of measuring channels;

2) requirements for the accuracy of measurements of parameters and (or) for the metrological characteristics of measuring channels;

3) requirements for metrological compatibility of the technical means of the system;

4) a list of control and computing channels of the system for which it is necessary to evaluate the accuracy characteristics;

5) requirements for the metrological support of hardware and software that are part of the measuring channels of the system, tools, built-in control, metrological suitability of the measuring channels and measuring instruments used in the adjustment and testing of the system;

6) type of metrological certification (state or departmental) with an indication of the procedure for its implementation and organizations conducting certification.

2.6.3.7. For organizational support, the following requirements are given:

1) to the structure and functions of the units involved in the operation of the system or ensuring operation;

2) to the organization of the functioning of the system and the procedure for interaction between the IS personnel and the personnel of the informatization object;

3) to protection against erroneous actions of the system personnel.

2.7. The section "Composition and content of work on the creation (development) of the system" should contain a list of stages and stages of work on the creation of the system, the timing of their implementation, a list of organizations - performers of work, links to documents confirming the consent of these organizations to participate in the creation of the system, or a record identifying the person responsible (customer or developer) for carrying out these works.

This section also provides:

1) a list of documents to be presented at the end of the relevant stages and stages of work;

2) the type and procedure for conducting the examination of technical documentation (stage, stage, scope of the checked documentation, organization-expert);

3) a program of work aimed at ensuring the required level of reliability of the system being developed (if necessary);

4) a list of works on metrological support at all stages of the creation of the system, indicating their deadlines and executing organizations (if necessary).

2.8. In the section "Procedure for monitoring and acceptance of the system" indicate:

1) types, composition, scope and test methods of the system and its components;

2) general requirements for the acceptance of work by stages, the procedure for agreeing and approving acceptance documentation;

2.9. In the section "Requirements for the composition and content of work to prepare the automation object for putting the system into operation", it is necessary to provide a list of the main activities and their performers that should be performed when preparing the project for putting the IS into operation.

The list of main activities includes:

1) bringing the information entering the system (in accordance with the requirements for information and linguistic support);

2) creation of conditions for the functioning of the project, under which the compliance of the created system with the requirements contained in the TOR is guaranteed;

3) creation of subdivisions and services necessary for the functioning of the system;

4) terms and procedure for staffing and staff training.

2.10. In the "Documentation Requirements" section, the following is given:

1) the list of sets and types of documents to be developed agreed by the developer and the Customer of the system;

2) a list of documents issued on machine media;

3) in the absence of state standards that define the requirements for documenting system elements, they additionally include requirements for the composition and content of such documents.

2.11. The section "Sources of development" should list the documents and information materials on the basis of which the ToR was developed and which should be used when creating the system.

3.Rules of registration.

3.1. Sections and subsections of the TOR should be placed in the order established in sec. 2 of this standard.

3.2. Sheet (page) numbers are put down, starting from the first sheet following the title page, in the upper part of the sheet (above the text, in the middle) after the designation of the TK code on the IC.

3.3. On the title page, the signatures of the customer, developer and coordinating companies are placed, which are sealed. If necessary, the title page is drawn up on several pages. Signatures of TK developers and officials, participating in the coordination and consideration of the draft TOR on IP, are placed on the last sheet.

The form of the title page of the TOR is given in Appendix 2. The form of the last sheet of the TOR is given in Appendix 3.

3.4. The title page of the Supplement to the TOR is drawn up in the same way as the title page of the terms of reference. Instead of the name "Terms of Reference" they write "Addendum No. ... to the TOR for AC ...".

3.5. On subsequent sheets of the addendum to the TOR, the reason for the change, the content of the change and links to the documents in accordance with which these changes are made are placed.

3.6. When presenting the text of the supplement to the TOR, the numbers of the relevant paragraphs, subparagraphs, tables of the main TOR, etc., should be indicated and the words “replace”, “supplement”, “delete”, “state in a new edition” should be used.

The procedure for the development, approval and approval of TK for IP.

1. The draft TOR is developed by the organization-developer of the system with the participation of the customer on the basis of technical requirements (application, tactical and technical assignment, etc.).

In the competitive organization of work, the options for the draft TOR are considered by the customer, who either chooses the preferred option, or, on the basis of a comparative analysis, prepares the final version of the TOR for AC with the participation of the future IS developer.

2. The need for approval of the draft ToR with the state supervision authorities and other interested organizations is determined jointly by the customer of the system and the developer of the draft ToR for IP,

The work on the approval of the draft TOR on the IC is carried out jointly by the developer of the TOR and the customer of the system, each in the organizations of their own ministry (department).

3. The term for approval of the draft TOR in each organization should not exceed 15 days from the date of its receipt. It is recommended to send copies of the draft ToR (copies) for approval simultaneously to all organizations (divisions).

4. Comments on the draft TOR should be submitted with technical justification. Decisions on comments must be made by the developer of the draft ToR and the customer of the system before the ToR for the IS is approved.

5. If, when agreeing on the draft TOR, disagreements arose between the developer and the customer (or other interested organizations), then a protocol of disagreements is drawn up (arbitrary form) and a specific decision is made in the prescribed manner.

6. Approval of the draft TOR is allowed to be drawn up as a separate document (letter). In this case, under the heading "Agreed" make a link to this document.

7. Approval of the TOR is carried out by the heads of the companies of the developer and the customer of the system.

8. Copies of the approved ToR within 10 days after approval are sent by the developer of the ToR to the participants in the creation of the system.

9. Coordination and approval of additions to the TOR is carried out in the manner established for the TOR on the IP.

10. Changes to the TOR are not allowed to be approved after the submission of the system or its queue for acceptance tests.

The basis for the development of the technical design of the system is the terms of reference approved by the customer.

The technical design of the system is technical documentation approved in the prescribed manner, containing system-wide design solutions, an algorithm for solving problems, as well as an assessment of the economic efficiency of an automated control system and a list of measures to prepare an object for implementation.

The technical project is being developed in order to determine the main design decisions for the creation of the system. At this stage, a complex of research and experimental work is carried out to select the best solutions, an experimental verification of the main design decisions and a calculation of the economic efficiency of the system are carried out.

Actually technical project contains a complex of economic-mathematical and algorithmic models.

A complete set of technical design for the system includes 10 documents:

1. Explanatory note.

2. Functional and organizational structure of the system.

3. Statement of problems and solution algorithm.

4. Organization of the information base.

5. Album of forms of documents.

6. Software system.

7. The principle of constructing a complex of technical means.

8. Calculation of the economic efficiency of the system.

9. Measures to prepare the facility for the implementation of the system.

10. List of documents.

From the above list, document 3 "Problem Statement and Solution Algorithm" is performed for each individual task included in the EIS, the rest of the documents are common to the entire system. In addition, documents 1, 2, 5, 8 and 9 can be developed for individual subsystems.

All of these documents can be grouped and presented in the form of four main parts of the technical project: economic and organizational, informational, mathematical, technical.

The economic and organizational part of the technical project contains explanatory note with the justification for the development of the system, a list of developer organizations, a brief description of the object indicating the main technical and economic indicators of its functioning and relations with other objects, brief information about the main design decisions for the functional and supporting parts of the system.

In the section of the technical project, devoted to the organizational and functional structure of the system, the following is given: the rationale for the allocated subsystems, their list and purpose; a list of tasks to be solved in each subsystem, with a brief description of their content; scheme of information links between subsystems and between tasks within each subsystem.

For each task included in the set of priority tasks, its statement and solution algorithm are performed. This section of the technical design includes:

§ organizational and economic essence of the task (name, purpose of the solution, summary, method, frequency and time of solving the problem, methods of collecting and transmitting data, the connection of the task with other tasks, the nature of the use of the results of the solution in which they are used);

§ economic and mathematical model of the problem (structural and expanded form of representation);

§ input operational information (characteristics of indicators, their significance and range of change, presentation forms);

§ reference information (NSI) - content and presentation forms;

§ Information stored for connection with other tasks;

§ information accumulated for subsequent solutions to this problem;

§ information on making changes (change system and list of information subject to changes);

§ algorithm for solving the problem (sequence of calculation steps, scheme, calculation formulas);

§ test case (a set of input document forms filled with data, conditional documents with accumulated and stored information, output document forms filled out based on the results of solving an economic and technical problem and in accordance with the developed calculation algorithm).

The document "Calculation of the economic efficiency of the system" contains a summary estimate of the costs associated with the operation of the systems, provides a calculation of the annual economic efficiency, the sources of which are the optimization of the production structure of the economy (combinations), reducing the cost of production due to the rational use of production resources and reducing losses, improving the accepted management decisions.

The document "Measures to prepare the facility for the implementation of the system" contains a list of organizational measures to improve the existing management structure, a list of works on the implementation of the system that must be performed at the detailed design stage, indicating the timing and responsible persons.

The information part of the technical project combines documents 4 and 5. The document "Organization of the information base" reflects: sources of information and methods of its transmission to solve the priority set of functional tasks; a set of indicators used in the system; the composition of documents, the timing and frequency of their receipt; main design decisions for the organization of the NSI fund; the composition of the NSI, including the list of details, their definition, significance, range of change and the list of documents of the NSI; list of NSI arrays, their volume, order and frequency of information correction; proposals for the unification of documentation, a test case for making changes to the NSI; structural form of NSI with a description of the relationship between the elements; requirements for the technology of creating and maintaining the fund; methods of storage, search, modification and control, determination of volumes and flows of NSI information.

"Album of forms of documents" contains NSI forms.

The mathematical part of the technical project contains the rationale for the structure of the software, the rationale for choosing a programming system, including a list of standard programs.

The technical part of the technical project includes: description and justification of the scheme of the technical process of data processing; substantiation of requirements for the development of non-standard equipment; substantiation and choice of the structure of the complex of technical means and its functional groups; a set of measures to ensure the reliability of the functioning of technical means.

CONCLUSION

The development of an information system, as a rule, is carried out for a well-defined enterprise. Features of the subject activity of the enterprise, of course, have an impact on the structure of the information system, but at the same time, the structures of different enterprises are generally similar to each other. Each organization, regardless of the type of its activity, consists of a number of divisions that directly carry out one or another type of activity of the company, and this situation is true for almost all organizations, no matter what type of activity they are engaged in.

The introduction of modern information technologies makes it possible to reduce the time required for the preparation of specific marketing and production projects, reduce unproductive costs during their implementation, eliminate the possibility of errors in the preparation of accounting, technological and other types of documentation, which gives a commercial company a direct economic effect.

Of course, in order to reveal all the potential opportunities that the use of computers brings, it is necessary to use a set of software and hardware tools that best suits the tasks set. Therefore, there is currently a great need commercial companies in computer programs that support the work of the company's management, as well as information on how to optimally use the company's computer equipment.

The implementation of AIS design involves the use by designers of a certain design technology that corresponds to the scale and features of the project being developed.

LIST OF USED LITERATURE

1. Guide to the study of the discipline "Automated information systems" [Electronic resource]. - Moscow, 2006. - Access mode:

http://www.e-biblio.ru/book/bib/01_informatika/sg.html - Head. from the screen.

2. Wikipedia, the free encyclopedia [Electronic resource] / Article "Information system" - Access mode: http://ru.wikipedia.org/wiki/Information system.

3. Computer press: Online magazine. -- Electron. Dan. -- [B.m., 2001]. -- Access mode: http://compress.ru/article.aspx?id=12282.

4. Vendrov A.M., “Designing software for economic information systems” / A.M. Vendrov. - M.: "Finance and statistics", 2000. - 364 p.

5. "Terms of reference for the creation of an automated system" / - M .: GOST 34.602-89, 1990.

6. Grekul V.I. "Design of information systems" / V.I. Grekul, G.N. Denishchenko, N.L. Korovkin. - M.: Internet University of Information Technologies, 2008.

Hosted on Allbest.ru

Similar Documents

Development of information systems. Modern market financial and economic application software. Advantages and disadvantages of introducing automated information systems. Methods for designing automated information systems.

thesis, added 11/22/2015


Types of provision of automated information systems. Preparation of terms of reference, development of an information system, preparation of a user manual for the program. Programming tools for distributed information processing systems.

practice report, added 04/16/2017


Life cycle of automated information systems. Fundamentals of the methodology for designing automated systems based on CASE technologies. Phase of analysis and planning, construction and implementation of an automated system. Cascade and spiral model.

term paper, added 11/20/2010


The concept of an information system, types of information systems. Analysis of tools for the development of automated information systems. Requirements for the program and software product. Development of GUI forms and databases.

thesis, added 06/23/2015


Principles of organizing a system consisting of personnel and a set of means for automating its activities. Designing corporate automated information systems. Structure, input and output flows, limitations of automated systems.

presentation, added 10/14/2013


The concept of an information system. Stages of development of information systems. Processes in the information system. Information system for finding market niches, for reducing production costs. The structure of the information system. Technical support.

abstract, added 11/17/2011


Organization, architecture and structure of the information system. Indicators of the effectiveness of its work. Goals and objectives of the analysis of automated control systems. Components of automated systems. Description of the subject area, input and output data. Building a diagram of precedents.

term paper, added 04/11/2014


Creation and organization of automated information systems (AIS). Main components and technological processes of AIS. Stages and stages of AIS creation from the position of the organization's management. Development of complexes of design solutions for an automated system.

abstract, added 10/18/2012


The main factors influencing the history of the development of corporate automated information systems. Their general characteristics and classification. Composition and structure of integrated AIS. ERP systems like modern look corporate information system.

presentation, added 10/14/2013


Analysis of the subject area, stages of designing automated information systems. Tool systems for software development. The role of CASE-tools in the design of the information model. The logical model of the database being designed.

AIS design

Detailed development system design containing a complete set of its organizational, design, technological and operational documentation. In accordance with GOST 34.601-90. design of automated systems involves the implementation of a number of stages, including: the formation of requirements for the NPP, the development of the concept of the NPP, the development of technical specifications, preliminary design, technical design and development of working documentation. The stages of creating the AU, in addition to designing, also include: commissioning and maintenance of the AU. Each stage is subdivided into stages. The annexes to this standard also define:

· List of types of organizations involved in the work.

Depending on the nature of the design object and its specific conditions, GOST 34.601-90 allows the exclusion of individual stages, as well as their combination. Taking into account the long-term practice that has developed in Russia when creating automated information systems (" AIS”), the following stages of design are usually carried out: pre-project survey, conceptual design, preliminary design, technical design and detailed design. Other state standards governing various aspects of NPP design:

· GOST 34.602-89 Set of standards for automated systems. Terms of reference for the creation of an automated system. Entered.01.01.90.

Standard 34.603-92 Information technology. Types of AS tests.

· Standards 34. (971, 972.973, 974, 981) - 91 Information technology. The relationship of open systems.

Standard 34.91. Information technology. Local area networks, etc.

Pre-project survey- Collection and processing of information about the organization and functioning of the automation object, including data on its interaction with the external environment and other objects, as well as the implementation system analysis, development of a feasibility study for the feasibility of automation and the development of general requirements for the development of an automated system. The content of work during the pre-project survey of the automation object corresponds to the stage “Formation of requirements for the AU” GOST 34.601-90, stages: “Inspection of the object and justification for the need to create an AU”, “Formation of user requirements for the AU”, “Formation of a report on the work performed and an application for development AC - tactical and technical assignment.

Conceptual design- Corresponds to the design stages in accordance with GOST 34.601-90 - “Development of the AU concept” (stages: “Development of variants of the AU concept and selection of the AU concept option that satisfies the user”, “Drawing up a report on the work performed”) and “Development of terms of reference”. The types of final documents of work at this stage are preliminary project(also used names - “ Conceptual project ”, “Pilot project") or Program creating a system that includes:

· Brief description the initial state of the automation object and the environment in which it operates;

Indication of the main goals and a list of automation tasks;

· Description of the enlarged organizational and functional structure of the selected option (or options) for building the system being created;

· Feasibility study;

· An enlarged description and basic requirements for the means of information and linguistic support;

· General requirements for software and hardware;

· A list and an enlarged description of the stages of creating the system, the timing of their implementation, the composition of the performers and the expected results of their implementation;

· Initial assessment of cost indicators of work performance;

· Terms of reference for the system as a whole and/or its main components (subsystems, software and hardware systems and tools, individual tasks, etc.), approved by the customer.

Preliminary design- Development of preliminary design solutions for the system and its parts. The final document of the work at this design stage is preliminary design , which contains the fundamental design and circuit solutions of the development object, as well as data that determine its purpose and main parameters (when designing software system, the draft design must contain a complete specification developed programs).

Engineering design - NPP design stage, which includes:

· Development of design solutions for the system and its parts;

· Development of documentation for the AU and its parts;

· Development and execution of documentation for the supply of products for the acquisition of nuclear power plants and / or technical requirements (technical specifications) for their development;

· Development of tasks for designing in adjacent parts of the project of the automation object.

The final document of this design stage is technical project containing, in addition to the listed materials, electrical circuit diagrams and design documentation of the development object and its components, a list of selected ready-made tools software and hardware(including computers, operating system, application programs etc.), as well as algorithms solving problems for the development of new software tools, etc.

Working design- Final stage design, which, in addition to the development of working documentation for the system and its parts required by GOST 34.601-90, generally provides for clarification and detailing of the results of previous stages, the creation and testing of an experimental and / or pilot industrial sample of an automation object, the development and testing of software products, technological and operational documentation. The results are presented in working or technical working project. In modern design practice automated information systems(for example, ABIS, ASNTI, ACS etc.) it is the initial stage of their implementation in the work of a firm, organization or service that is the customer of the project, or the head in a number of other automated firms, organizations, services, etc.

Development cycle (design) software - Set of development stages software starting from system analysis and development of initial requirements before its implementation.

AIS design principles- A set of rules or requirements fixed by many years of and versatile experience in the creation and operation of AIS. The most common ones are:

· Identity- the development of a new one, the improvement of an existing one, or the introduction of an externally obtained AIS are scientific and technical problems similar in content, differing from one another only in the content of a number of stages and time parameters;

· Manufacturability: automated technology means development new technology or modernization of the existing AIS and does not allow the simple use of the developed software and hardware in the old traditional technologies;

· Continuity, phasing and succession of development and development: AIS - systems constantly developing on their basis; each innovation serves as a development of the basic system principles and already achieved quality;

· adaptability: AIS components should have properties that ensure that these components quickly adapt to changes external environment and new means;

· Modular principle of building software and hardware: assumes that the composition of these tools consists of blocks (“modules”) that provide the possibility of their replacement or change in order to improve the functioning of the AIS or its adaptation to new conditions;

· Technological (including - network) integration: implies unity for the entire system of technology for creating, updating, preserving and using information resources and, in particular, single processing of documents and data, as well as their multiple and multi-purpose use;

· Full normalization of processes and their monitoring: multi-purpose use of AIS information requires high reliability of data in the system. To do this, at various stages of processing and input information documents it is necessary to use various forms of information control, the requirements for which can be formed from the composition of the tasks being solved and the data being processed. constant monitoring is also necessary to obtain qualitative and quantitative characteristics of the functioning of AIS based on built-in and specially developed tools of intellectual statistics;

· Regulation: AIS are focused on functioning in the industrial mode, providing mass streaming processing of information documents; this processing is regulated by standards, route and operational technologies, standards for resource and time indicators, and a developed dispatching service.

· Economic expediency: the creation of AIS should provide for the choice of such design solutions (including software, technical, organizational and technological), which, subject to the achievement of the goals and objectives, ensure the minimization of the cost of financial, material and labor resources.

· Typification of design solutions: the development and development of AIS and their networks is carried out with a focus on interlibrary cooperation, and cooperation, as well as in accordance with the rules and protocols of international information exchange;

· Maximum use of ready-made solutions: to reduce the cost and time of development and implementation of AIS, as well as to reduce design errors of both the system as a whole and its individual components, it is recommended to use ready-made solutions and tools as much as possible. In this plan, when creating a new system, a significant amount of work is associated with the analysis of alternative options for possible solutions, the choice of the most appropriate for the automation object and its adaptation to new conditions of use;

· corporatism: when designing an automated system that is part of a higher-level system (cities, departments, republics, etc.), its hardware, software, linguistic and information compatibility with other participants in the system and / or AIS network should be provided. Corporate requirements may conflict with requirements or decisions dictated by other principles, for example, the continuity of design solutions;

· Orientation to the first persons of the automation object: successful implementation of work on the creation of AIS, its development and operation is possible only if they are unconditionally supported by the first person of the automation object (for example, the director of a library or information body) and the direct responsibility for their implementation is assigned by order of the organization to the head at the level of at least the deputy director