Ais project management. AIS “Project Management. Basic concepts of AIS design

There are many methods and options for developing AIS, the use of which depends on various factors, for example, the size of enterprises and (or) their IS, the goals of creating an IS, available resources, etc. Methods and principles of designing an IS are discussed in the previous chapters.

The software project lifecycle is a set of stages and stages of software development, from system analysis and development of initial requirements to its installation (installation) on a computer.

Experience in the development and implementation of various classes of AIS has shown high efficiency (including economic) of their application, especially at large enterprises. It is reflected in a good organization of labor and production, an increase in the accuracy of planning and implementation of the tasks set, in ensuring the rhythm of the enterprise, reducing the share of manual labor, effective (including operational) information support for various categories of users, etc. The average payback period for such systems usually does not exceed two years.

When developing IS, in most cases, preference is given to standard design solutions, adapted to specific conditions and capabilities of the Customer. Individual projects are developed in the absence of standard solutions or when the basic parameters of the organization differ significantly (by more than 10-15%) from standard solutions. This usually applies to large and largest organizations.

No IC development scheme is absolute. Various options are possible, depending, for example, on the initial conditions in which the development is carried out: a completely new system is being developed; a survey of the enterprise has already been carried out and there is a model of its activity; the enterprise already has an IS that can be used as an initial prototype or should be integrated with the developed one.

Detailed development of the AIS project presupposes the availability of a complete set of organizational, design, technological and operational documentation.

The design of any object is carried out with:

• a) determining its functional purpose (why is it needed, what and how the designed object does),
• b) identifying logical connections (how the designed object fulfills its functional purpose, what information is processed and in what sequence),
• c) the choice of material means for the implementation of the designed object - the functional, technological and technical aspect (media, data processing tools, etc.),
• d) spatial (territorial) placement of material means of sale in allocated or possible for use areas,
• e) formation of the organizational and management structure of the designed object (composition of departments, powers and functional responsibilities workers)

After choosing the AIS design method, it is necessary to plan a set of works to create a system in accordance with the typical stages of its development. The project is reviewed and approved by the Customer. AIS design involves the implementation of certain stages and stages.

For the successful implementation of the project, it is necessary to establish real milestones with clearly marked start and end. The development of a detailed work plan is associated with a description of the processes and their sequence performed at each stage, the specialists, funds and resources required for this. This approach helps to a greater extent to avoid omissions and mistakes. It is necessary for workers implementing the implementation of an automation project, and also has a positive impact on the persons who finance it.

Effective phased implementation of design work is associated with the need to develop a schedule for their implementation, including resources and timing (stages) of their implementation (see previous graphs and figures). Resources include the required personnel, hardware, software, funding and infrastructure. At the same time, it is better to finance it separately for each type of work (purchase of funds and software, installation, training, individual design stages, etc.).

For automation different types activities (management, design, research, etc.), including their combinations, use the provisions of GOST 34.601-90. It provides for the following stages and stages of design (table 1).

table 2

The standard also states that:

• · Stages and stages performed by organizations participating in the creation of the AU are established in contracts and Terms of Reference based on this standard.
• · It is allowed to exclude the stage “Draft design” and separate stages of work at all stages, to combine “Technical design” and “Working documentation” into one stage “Techno-working design”. Depending on the specifics of the NPPs being created and the conditions for their creation, it is allowed to perform individual stages of work before the completion of the previous stages, parallel in time execution of stages of work, the inclusion of new stages of work.

The technical project (preliminary design) contains circuit diagrams and design documentation of the development object and its components, a list of selected ready-made software tools and technical support(including types of computers, operating systems, application programs, etc.), algorithms for solving problems for the development of new software tools).

Detailed design - the final design stage, in general, providing for the clarification and detailing of the results of the previous stages, the creation and testing of a prototype of the automation object, the development and testing of software products, technological and operational documentation.

In the modern practice of designing automated information systems (for example, AIPS, ASNTI, ACS, etc.), it can be the initial stage of their implementation in the work of an organization or service of the Customer of the project, or the head one in a number of other automated organizations, services, etc.

Detailed development of the system design presupposes the availability of a complete set of organizational, design, technological and operational documentation.

State standard GOST 19.102-77 establishes the following stages of development of software documentation:

• 1. Terms of reference;
• 2. Draft project;
• 3. Technical design;
• 4. Working draft;
• 5. Implementation.

Note that for small projects the number of stages can be reduced.

As part of the implementation of the first stage “Formation of requirements for the AU”, the object is examined and the need to create an AIS is justified, taking into account the user's requirements for the designed AIS. These procedures of the first stage of design are part of the pre-project study. This may also include the procedures of the second stage of design - “Development of the NPP concept”.

In the process of pre-design research, a feasibility study is being carried out for the feasibility of creating an AIS; development of general requirements for the development of AIS.

In the process of pre-design research to perform the necessary design work, the following are identified:

• · material resources,
• · financial resources,
• · human resources,
• · Temporary resources.

Currently, any organization has at its disposal some material resources, as a rule, of heterogeneous origin. To ensure the safety of these resources, it is necessary to keep records and appoint responsible persons. The solution to this problem can be carried out using various applications such as 1C: Enterprise, AVARD and many others. But these programs are very expensive, both in purchase and in maintenance. Require special education and training of personnel.

Under design should understand the process of creating a prototype of the proposed or possible object.

Modern technology for creating AIS is a combination of effective design tools and methods that simplify this process, reduce cost costs, shorten the system design calendar time and improve the quality of development due to a wide selection of proven advanced design solutions.

To the main design tools can be attributed:

Typical design solutions (TPD) and application packages (PPP). TPR - a set of algorithmic and software elements that ensure the implementation of tasks on a computer with the help of appropriate technical means;

Computer-aided design systems (CAD), involving the use of computers at all stages of AIS creation.

General requirements for design tools:

Full coverage of the entire process of creating AIS;

Compatibility, i.e. consistency both in the process of creating a system and in the process of its functioning;

Versatility, i.e. the possibility of using the same tools for different objects;

Accessibility in development and simplicity (simplicity) in implementation;

Possibility of organizing the design process in the mode of interactive interaction between the system developer, designer and computer;

Adaptability and cost-effectiveness.

Among design methods allocate:

Original design;

Typical design and its types: elemental, subsystem, modular, group;

Computer-aided design.

The original design method is traditional and focused on one specific enterprise. Characteristic feature This method is the development of original methods of object inspection and the creation of the necessary documentation in the form of an individual project. The advantage of this method is the reflection of the specific features of the automation object in the AIS project. The disadvantages include a relatively high labor intensity and long development time, a low indicator of functional reliability and adaptability to changing conditions. Projects created by the original method lend themselves to modernization, however, in pure form this method is rarely used. Today, during its implementation, various design tools are used, and only certain parts of the project require original design solutions. This somewhat smoothes out its shortcomings. However, this method remains relevant when automating complex, extraordinary objects.

V modern conditions AIS is usually not built from scratch. At present, in the economy, at almost all levels of management and at all economic entities, automated information processing systems operate. The increased need for timely, high-quality and operational information necessitates the creation of AIS on a new technical and technological basis.

The search for rational ways of designing goes in the following directions:

1. development of standard design solutions implemented in applied software packages (PPP) for solving economic problems with the subsequent linking of the PPP to the specific conditions of implementation and operation;

2. development of automated design systems.

The first of the ways is the ability to use standard design solutions included in the packages of applied programs.

Typical design- an industrial method of creating AIS using TPR and RFP. This method is characterized by the presence of proven, standard organizational and economic, technical, informational, mathematical and software control automation tools. Application of this method makes it possible to reduce labor intensity, reduce cost and shorten design time, and improve design quality. The typical design process consists in the selection and binding of supporting subsystems in accordance with the requirements of a specific AIS. The typical part of the AIS is a complex of information, software and hardware. The typical nature of information support is achieved through strict adherence to the unity of the structure of the information base, the composition of the arrays, the forms of input and output documents. The typical nature of the software is achieved by using the PPP, and the typical nature of the technical support is achieved by using computers of the same or combined types.

1. A variation of the typical design method is the method elemental design, which is based on TPR. When developing a project, a ready-made solution with minor modifications is used, and a new one is not being developed.

2. When using modular method TPR are created on a modular basis, when each design solution is divided into separate component parts - modules that implement a certain part of TPR. This allows you to create a project for a new automated system by combining individual standard modules.

3. When using subsystem design method for each subsystem, solution projects and application packages are created - system-wide and functional. The allocation of subsystems depends on the object of the economic and production process. For each of the subsystems, its own automated design solution and PPP are developed, which can be system-wide or functional. System-wide PPPs include data management PPPs, PPPs of standard data processing procedures, methods of mathematical statistics and discrete programming, etc. Functional PPPs include packages aimed at industrial enterprises with a discrete or continuous nature of production, in the non-industrial sphere, and sectoral management.

An important requirement for RFP is compatibility, since when designing AIS, it is advisable to use several packages at once. The design of systems using PPP is actually reduced to the binding of packages selected according to certain parameters to the specific conditions of the automation object. Positive qualities This approach to design can be called: less labor-intensive process, reduction of design time compared to original design, implementation of advanced data processing methods, simplification of project documentation (since package documentation is used), increased reliability of designed AIS.

4. In addition, there are group design method... Its essence lies in the preliminary selection of a group of objects of the same type in terms of characteristics. Among them, the base object is selected, for which the project is being developed, and various methods and design methods can be used. The main thing here is to ensure high adaptability of the project. The main area of ​​application of this method is non-industrial facilities (for example, warehouses).

The following activities lend themselves most effectively to automation:

1. accounting, including management and financial. The largest number of RFPs have been created for accounting purposes. Among them are "1C: Accounting", "Turbo-Accountant", "Info-Accountant", "Parus", "ABACUS", "Bambi +", etc .;

2.information and information service economic activity... Represented by the following PPP: "GARANT" (taxes, accounting, audit, entrepreneurship, banking, currency regulation, customs control); "CONSULBTANT +" (taxes, accounting, audit, entrepreneurship, banking, currency regulation, customs control).

3.economic and financial activities... Represented by the following RFP:

a) "Economic analysis and forecast of the firm, organization" (firm "INEK"), which implements the functions: economic analysis activities of a firm, enterprise; drawing up business plans; feasibility study for loan repayment; analysis and selection of options for activities; forecast of balance, cash flows and finished goods.

b) Multi-user network complex of full automation of the Galaktika corporation (JSC Novy Atlant), which includes planning, operational management, accounting and control, analysis, in addition, allows within the framework of the DSS to ensure the solution of business planning problems using the PPP Project- Expert.

4. organization of the head's work;

5. automation of document flow;

6. training.

Recently, enterprises and firms prefer to buy ready-made packages and technologies, and if necessary, add their own software to them, since the development of their own AIS is associated with high costs and risks. As a rule, a basic system is developed and proposed, which is adapted according to the wishes of individual clients. At the same time, users are provided with consultations that help to minimize the implementation time of systems and technologies, use them in the most effective way, and improve the qualifications of personnel.

Computer-aided design systems - the second, rapidly developing way of conducting design work.

Among the computer-aided design methods, model design methods occupy a special place. The creation and use of CAD systems provides a sufficiently high level of functional reliability, comprehensive coverage of all technological processes, and a decrease in the labor intensity of design work with maximum consideration of the interests of the automation object. However, this method is quite expensive and requires highly skilled developers. The key requirement for CAD is the ability to build and maintain in the design system in an adequate state of some global economic information model of the automation object. A model is an explicit display of information components of an automation object and relationships between them. The main goal of building a model is to create an AIS project corresponding to this model, taking into account and actively using all the characteristics of the object. Such a model should contain in a formalized form a description of the sets of information components and the relationship between them, including information links and algorithmic interaction. Using the model design method, systems approach, which determines the use of computers not only at all stages of the creation of the system, but also in the process of analyzing the results of its industrial operation. The development and application of CAD predetermined the transition to the creation of individual projects, but at a significantly higher level than the original design method.

Over the past decade, a new direction has emerged in the field of IC and IT design automation - CASE computer-aided software development technology(CASE - Computer-Aided Software / System Engineering). The increasing complexity of information systems, the increasing requirements for them have led to the need for the industrialization of technologies for their creation.

CASE technology is a set of methods for analysis, design, development and maintenance of IS, supported by a set of interconnected automation tools. CASE is a toolkit for system analysts, developers and programmers that automates the process of designing and developing ICs. CASE systems are used as a powerful tool for solving research and design problems, such as structural analysis of the subject area, project implementation using the latest generation of programming languages, issuing project documentation, testing project implementation, planning and monitoring developments, modeling business applications in order to solve operational problems. and strategic planning and resource management, etc.

The main goal of CASE is to automate the development and operation of systems as much as possible.

When using CASE-technologies, the technology of work at all stages of the life cycle of automated systems changes. In CASE-systems, design is based on visual visual methods of development, while graphs, diagrams, tables, diagrams and textual explanations to them are used to describe the model of the designed IS. Such methodologies provide a rigorous and descriptive description of the system being designed, which begins with an overview of the system and then goes into more detail, becoming a hierarchical structure with an increasing number of levels.

Programming automation is based on the automatic generation of program codes that contain data descriptions, the main logic of their processing, database schemes, interface description files, etc. The codes are further refined and refined, but in some cases automation reaches 90%. In addition, the CASE technology generates the necessary project documentation ready for use.

When using the CASE-technology, the support of a single project base is provided, i.e. all information about the developed AIS is automatically placed in a single project database. This maintains consistency, consistency, completeness and minimal redundancy of design data.

CASE-technology provides teamwork of development teams, because different groups of specialists are provided with adequate tools, as well as the ability to consistently and correctly make changes to the project by various specialists in real time.

CASE technologies are successfully used to build almost all types of AIS. CASE is also used to create system models that help commercial structures solve the problems of strategic planning, financial management, firm policy determination, personnel training, etc.

CASE have the following main advantages:

Improve the quality of the created IS (IT) by means of automatic control (first of all, project control);

Allow in a short time to create a prototype of the future IS (IT), which allows you to quickly, in the early stages, assess the expected result;

Accelerate the system design and development process;

Free the developer from routine work, allowing him to concentrate entirely on the creative part of the design;

They support the development and maintenance of an already functioning IS.

By now, a powerful CASE-industry has emerged, bringing together hundreds of firms and companies of various orientations. Among them stand out:

Companies-developers of tools for analysis and design of IP and IT

Firms-developers of special tools with a focus on narrow subject areas or at separate stages of the life cycle of IP;

Training firms that organize seminars and training courses for specialists;

Consulting firms providing practical assistance in using CASE packages for the development of specific IS;

Firms specializing in the publication of periodicals and bulletins on CASE technologies.

Nbsp; AIS life cycle models

AIS life cycle model is a structure that describes the processes, actions and tasks that are carried out and the course of 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.

AIS lifecycle model includes:

Work results at each stage;

Key events or points of completion and decision making.

In accordance with the well-known models of the life cycle of software, the models of the life cycle of the AIS are determined - cascade, iterative, spiral.

I. Waterfall model describes the classic approach to the development of systems in any subject area; was widely used in the 1970s and 1980s.

The waterfall model provides for the sequential organization of work, and the main feature of the model is the division of all work into stages. The transition from the previous stage to the next occurs only after the complete completion of all the work of the previous one.

Allocate five stable stages of development, practically independent of the subject area (Fig. 1.1).

On first At this stage, a study of the problem area is carried out, the customer's requirements are formulated. The result of this stage is the terms of reference (development assignment), agreed with all interested parties.

During second stage, according to the requirements of the technical assignment, certain design solutions are developed. As a result, a set of project documentation appears.

Third stage - project implementation; in essence, software development (coding) in accordance with the design decisions of the previous stage. In this case, the implementation methods are not of fundamental importance. The result of this stage is the finished software product.

On fourth At this stage, the received software is checked for compliance with the requirements stated in the terms of reference. Trial operation allows you to identify various kinds of hidden flaws that appear in the real conditions of the AIS.

The last stage is surrender finished project, and the main thing here is to convince the customer that all his requirements are met in full.

Figure 1.1 Waterfall AIS Lifecycle Model

The stages of work in the framework of the waterfall model are often called parts of the AIS project cycle, since the stages consist of many iterative procedures for clarifying the system requirements and design options. AIS lifecycle is significantly more complicated and longer: it can include an arbitrary number of cycles of clarification, changes and additions to already adopted and implemented design solutions. In these cycles, the development of AIS and the modernization of its individual components take place.

The advantages of the cascade model:

1) at each stage, a complete set of project documentation is formed that meets the criteria of completeness and consistency. At the final stages, user documentation is developed, covering all types of AIS support provided by the standards (organizational, informational, software, technical, etc.);

2) the sequential implementation of the stages of work allows you to plan the timing of completion and the corresponding costs.

The waterfall model was originally developed to solve various kinds of engineering problems and has not lost its significance for the applied field until now. 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 with sufficient accuracy 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 to return;

The complexity of the parallel work on the project;

Excessive information oversaturation of each of the stages;

Complexity of project management;

High level of risk and unreliable investments.

Delay in receiving results manifests itself in the fact that a consistent approach to the development of coordination of results with stakeholders is carried out 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 may arise at any stage of development; in addition, errors can be inadvertently introduced by both analyst designers and programmers, since they are not required to be well versed in the subject areas for which the AIS is being developed.

Return to earlier stages. This shortcoming is one of the manifestations of the previous one: step-by-step sequential work on a project can lead to the fact that mistakes made at earlier stages are discovered only at subsequent stages. As a result, the project is returned to the previous stage, reworked and only then transferred to the subsequent work. This can lead to a disruption to the schedule and complicate the relationship between the development groups performing certain stages.

The worst option is when the flaws of the previous stage are discovered 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.

Complexity of parallel work connected with the need to coordinate different parts of the project The stronger the relationship of the individual parts of the project, the more often and more thoroughly synchronization should be performed, the more dependent on each other the development teams. As a result, the benefits of parallel work are simply lost; the lack of parallelism negatively affects the organization of the work of the entire team.

Problem information oversaturation arises from strong dependencies between different development groups. 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 critical task: developers must constantly get acquainted with the 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 must wait for the results of the work of other teams, therefore, administrative intervention is required to agree on the timing and composition of the submitted documentation.

If errors are detected in the work, it is necessary to return to the previous stages; the current work of those who made a mistake is interrupted. The consequence of this is usually a delay in the completion of both the corrected and the new project.

It is possible to simplify interaction between developers and reduce information overload of documentation by reducing the number of connections 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 takes and the more complex the interconnections between the individual parts of the project, the number of which also increases. Moreover, the development results can be really 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 significant time and money.

Late evaluation creates serious problems in identifying errors in analysis and design - you need to go back to previous stages and repeat the development process. However, the return to the previous stages can be associated not only with errors, but also with changes that have occurred in the subject area or in the customer's 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 likelihood of "looping" the development process: the costs of the project will constantly increase, and the deadlines for the delivery of the finished product are constantly being postponed.

II. Iterative model consists in a series of short cycles (steps) of planning, implementation, study, action.

The creation of complex AIS involves the approval of design solutions obtained in the implementation of individual tasks. The bottom-up design approach necessitates such iterations of returns, when design solutions for individual tasks are combined into common systemic ones. At the same time, there is a need to revise the previously formed requirements.

Advantage the iterative model is that inter-stage adjustments provide less labor-intensive development compared to the waterfall model.

disadvantages iterative model:

· The lifetime of each stage is extended for the entire period of work;

· Due to a large number of iterations, there are inconsistencies in the implementation of design solutions and documentation;

· Intricacy of architecture;

· Difficulties in using design 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, it involves an iterative process of AIS development. At the same time, the importance of the initial stages, such as analysis and design, increases, at which the feasibility of technical solutions is checked and justified by creating prototypes.

Each iteration represents a complete development cycle leading to the release of an internal or external version of a product (or a subset of the final product), which improves from iteration to iteration to become a complete system (Figure 1.2).

Rice. 1.2. Spiral model of life cycle AIS

Thus, each turn of the spiral corresponds to the creation of a fragment or version of the software product, the goals and characteristics of the project are specified on it, its quality is determined, work is planned for the next turn of the spiral. Each iteration serves to deepen and consistently concretize the details of the project, as a result of which a reasonable option for the final implementation is selected.

Using the spiral model allows you to move to the next stage of the project without waiting for the complete completion of the current one - unfinished work can be completed at the next iteration. the main task each iteration - create a workable product for demonstration to users as soon as possible. Thus, the process of making adjustments 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 capabilities, making the development process more flexible.

Advantages iterative approach:

Iterative development greatly simplifies making changes to the project when the customer's requirements change;

When using the spiral model, the individual elements of the AIS are gradually integrated into a single whole. Since the integration starts with fewer elements, there are much fewer problems in its implementation;

Reducing the level of risks (a consequence of the previous advantage, since risks are detected precisely during integration). The level of risks is maximal at the beginning of the development of the project; as the development progresses, it decreases;

Iterative development provides more flexibility in project management by allowing tactical changes to be made to the product being developed. So, you can shorten the development time by reducing the functionality of the system or use it as component parts products of third-party firms instead of their own developments (relevant in a market economy, when it is necessary to resist the promotion of competitors' products);

An iterative approach makes it easier to reuse components because it is much easier to identify (identify) 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 project after several initial iterations reveals common reusable components that will be improved in subsequent iterations;

The spiral model allows for a more reliable and stable system. This is due to the fact that as the system evolves, errors and weaknesses are discovered and corrected at each iteration. At the same time, critical performance parameters are adjusted, which in the case of a cascade model is available only before the implementation of the system;

An iterative approach improves the process
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 stage 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. Customer representatives get the opportunity to control the process of creating a system and influence its functional content. The result is the commissioning of a system that takes into account most of the customer's needs.

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

AIS design technology 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 TP design, AIS is a set of sequential-parallel, connected and subordinate chains of actions, each of which can have its own subject. The actions that are performed in the design of AIS can be defined as indivisible technological operations or as sub-processes of technological operations. All actions can be proper design, that shape or modify design results, and estimated, which are developed according to the established criteria for evaluating design results.

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 chosen design technology are as follows:

· The project created with the help of this technology must meet the customer's requirements;

· The technology should reflect as much as possible all stages of the life cycle of the project;

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

· The technology should contribute to the growth of designers' labor productivity;

· The technology should ensure the reliability of the design and operation of the project;

· The technology should facilitate easy maintenance of project documentation.

AIS design technology implements a specific design methodology. In turn, the design methodology assumes the presence of some 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, typical design solutions, adaptability to anticipated changes.

According to the degree of automation, they are distinguished:

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 (tuning) of design solutions is carried out using special software tools.

According to the degree of use of typical design solutions, they are distinguished:

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

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

Original design AIS assumes maximum consideration of the features of an automated facility.

Typical design performed on the basis ready-made solutions and is a generalization of the experience gained earlier in the creation of related projects.

By the degree of adaptability of design solutions the following methods differ:

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

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

restructuring of the model- the model of the subject area changes, which leads to the automatic reformation 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(use of CASE technologies) and typical(parametric-oriented or model-oriented) design.

Table 1.1.Characteristics of design technology classes

Canonical AIS Design focuses on the use of mainly the waterfall 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 can have different labor intensity. It is allowed to combine sequential 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 AIS creation, 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 facility and justification of the need to create 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 automation object;

· Carrying out the necessary research work;

· Development of options for the concept of AIS, satisfying the requirements of users;

· Preparation of the report and approval of the concept.

Stage 3. Technical task:

Development and approval of technical specifications for the creation of AIS.

Stage 4. Preliminary design:

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

· Development of outline documentation for 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 design assignments in related 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 supplied products (software and hardware, software and hardware complexes, information products);

· Construction and installation work; commissioning works;

· Conducting preliminary tests;

· Conducting trial operation;

· Carrying out acceptance tests.

Stage 8. AIS escort:

· 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 the existing system information processing.

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

Justification for the development and phased implementation of systems;

Drawing up technical specifications for the development of systems;

Development of technical and working projects of systems.

At the stage of the survey, it is advisable to distinguish two components: defining the 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 volume of the project, its goals and objectives based on the identified functions and information elements of the high-level automated object. These tasks can be implemented either by the AIS customer independently, or with the involvement of consulting organizations. This 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. Typically, the information you need can be obtained through interviews, conversations or workshops with management, experts and users.

Upon completion of the survey stage, it becomes possible to determine the likely technical approaches to creating a system and estimate the costs of its implementation (for hardware, for purchased software and for developing new software).

The result of the strategy definition stage is a document (feasibility study - feasibility study - project), where it is clearly formulated what the customer will receive if he agrees to finance the project, when he receives the finished product (work schedule) and how much it will cost (for large projects - this is a funding schedule 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, expected economic effect(if it can be assessed).

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

The set of conditions under which the future system is supposed to be operated - system architecture, hardware and software resources, operating conditions, service personnel and users of the system;

Terms of completion of individual stages, the form of acceptance / delivery of work, the resources involved, measures to protect information;

Description of the functions performed by the system;

Opportunities for the 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 detailed analysis of the organization's activities, activities are studied that ensure the implementation of management functions, organizational structure, staff and content of work on enterprise management, as well as the nature of subordination to higher management bodies. Here it is necessary to outline the instructive-methodical and directive materials, on the basis of which the composition of the subsystems and the list of tasks, as well as the possibility of using new methods of solving problems, are determined.

Analysts collect and record information in two interrelated forms:

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

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

When studying each functional control task, the following are determined:

Task name; terms and frequency of its decision;

The degree of formalizability of the problem;

Sources of information required to solve the problem;

Indicators and their quantitative characteristics;

The procedure for correcting information;

Operating algorithms for calculating indicators and possible control methods;

Existing means of collecting, transmitting and processing information;

Existing means of communication;

Accepted accuracy of the problem solution;

The complexity of solving the problem;

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

Consumers of the resultant information on the task.

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

Number of documents;

Place of formation of document indicators;

Interrelation of documents during 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 signs.

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

During the survey phase, the planned system functions should be classified according to their importance. One of the possible formats for presenting such a classification is MuSCoW. This abbreviation stands for: Must have - required functions; Should have - desired functions; Could have - I possible functions; Won "t have missing features.

Functions of the first category provide critical for I successful work systems capabilities. 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, in the order of priority, the number of functions of the second and third categories is being developed. The last category of functions is especially important, since it is necessary to clearly understand the boundaries of project I and the set of functions that will be absent in the system.

Organizational activity models are created in two types 1:

The “as is” model - reflects the business processes existing in the 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 the testing group in the work to solve the following tasks:

Obtaining comparative characteristics of hardware platforms, operating systems, DBMS, etc .;

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

Engaging testers early in development is a good idea for any project. The later errors in design solutions are discovered, the more expensive it is to fix them; the worst case scenario is their detection during the implementation phase. Thus, the sooner the testing teams begin to identify errors in the AIS, the lower the cost of working on the system. Time for testing the system and for correcting 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 effectiveness of testing. Their use allows you to have a single repository of errors, track their reoccurrence, control the speed and efficiency of error correction, see the most unstable system components, and also maintain communication between the development team and the testing team.

The survey results represent an objective basis for the formation of technical specifications for the AIS.

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

When developing a technical assignment (TOR), it is necessary to solve the following tasks:

· To establish the general purpose of creating AIS;

· Establish general requirements for the designed system;

· Develop and substantiate the requirements for information, mathematical, software, hardware and technological support;

· To determine the composition of subsystems and functional tasks;

· Develop and justify the requirements for subsystems;

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

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

· To determine the composition of the performers.

Typical requirements for the composition and content of the technical specifications are given in table. 1.6.

Tabblitsa 1.6. The composition and content of the technical task (GOST 34.602-89)

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

AIS functions;

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

Composition of task complexes and individual tasks;

Information base concept and its enlarged structure;

Database management system functions;

Composition of a computing system and other technical means;

Functions and parameters of the main software.

Based on the results of the work done, documentation is drawn up, agreed upon and approved in the amount necessary to describe the full set of adopted design decisions and sufficient for further work on the creation of 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;

Development of a general description of the algorithm for solving the problem;

Development of a feasibility study;

Development of an explanatory note.

In this case, 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 sketch design.

Mandatory documents:

1) updated terms of reference for the design and development
work of AIS;

2) specification of qualification requirements for AIS;

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

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

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

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

7) a preliminary version of the AIS administrator's manual;

8) a preliminary version of the AIS user manual;

9) a revised plan for the implementation of the project;

10) refined AIS quality assurance management plan;

11) explanatory note of the preliminary draft AIS;

12) a revised contract (agreement) with the customer for a detail-
new design of AIS.

Documents drawn up by agreement with the customer:

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

2) a diagram of data flows between the functional components of the AIS;

3) a refined diagram 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 the requirements for them by stages of AIS development;

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

6) a 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) a 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 test automation methods and tools;

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

11) preliminary plan of sale and implementation;

12) a description of the preliminary structure of the database.

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

Table 1.7. Content of the technical project

At the stage "Working documentation", the creation of a software product and the development of all accompanying documentation are carried out. The documentation should contain all the necessary and sufficient information to ensure the performance 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 drawn up, agreed and approved.

At the stage "Putting into operation" for the AIS, the following main types of tests are established: preliminary tests, trial operation and acceptance tests. If necessary, it is allowed to additionally conduct other types of tests of the system and its parts.

Depending on the relationship between the AIS components and the automation object, tests can be autonomous and complex. System components are involved in autonomous testing. They are carried out as soon as the parts of the system are ready for commissioning. Complex tests are carried out for groups of interconnected components (subsystems) or for the system as a whole.

To plan the conduct of all types of tests, the document "Program and Test Methodology" is being developed. The developer of the document is established in the contract or TK. Tests or test cases can be included in the document as an attachment.

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

The cost of identifying and eliminating errors in later design stages increases approximately exponentially (Figure 1.10).

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

1) logical;

2) data manipulation errors;

3) I / O errors;

4) errors in calculations;

Rice. 1.10. The relative cost of detecting and fixing a single error

5) errors in user interfaces;

6) errors in the operating system and auxiliary programs;

7) layout errors;

8) errors in interprogramming interfaces;

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

10) errors when handling external devices;

11) errors of interfacing with the database (DB);

12) database initialization errors;

13) errors of changes on request from outside;

14) errors related to global variables;

15) repetitive mistakes;

16) errors in documentation;

17) violation of technical requirements;

18) unrecognized errors;

19) operator errors.

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

The relationship between development and testing at various stages of AIS design is shown in Fig. 1.11.

This chain is only conditionally "stretched" into a line. There are always recurring loops inside it. 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. Correlation between development and testing by stages of AIS design

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

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

Wrong transfer of control - 16%;

Incompatibility of programs with the data used - 15%;

Incompatibility of programs for transmitted data - up to 9%.

When developing debug tasks, the following tasks are solved:

Writing tests;

Selection of points, zones and routes of control;

Determination of the list of controlled quantities 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 at least once work through each branch of the algorithm and at the same time assign a number of values ​​to the variables, capturing the boundaries of the range, several values ​​within it, zero values ​​and singular points (if any). For specialized systems, special debugging languages ​​are developed. They can contain a relatively small number of commands (20-30) with additional tuning parameters to solve the following tasks:

Withdrawal control;

Modeling the execution process of the program being debugged;

Issuing the state of memory components during program execution;

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

Establishing test values ​​of the initial data;

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

Performing service operations to prepare the program for testing.

The debugging process cannot be classified as fully formalized, therefore there are empirical recommendations for its conduct, which are given below.

1. Use a semantic, pre-thought approach to debugging, plan the debugging process, and carefully design test datasets from the simplest possible options, eliminating the most likely sources of error.

2. Collect and analyze information to streamline the testing process:

Features and error statistics;

On 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 the means of logging and displaying information about errors, including in the program special debug code for printing out sample values ​​of variables, messages about the end of individual sections of the program, tracing, logical conditions, etc.

5. Study the resulting output carefully and compare it with the expected, pre-calculated results.

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

7. Use data flow and control flow analysis to validate and establish data scopes for different paths of program execution.

8. Use a variety of debugging tools at the same time, without dwelling on one possibility. Use automated tools and manual debugging and testing at the same time, checking the code for performance against the most likely errors.

9. Document any errors found and fixed, their differences, location and type. This information will be useful to prevent future errors.

10. Measure the complexity of programs. In programs with high complexity, there is a high probability of specification and design errors, and with low complexity, coding and clerical errors.

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

Preliminary tests are carried out to determine the operability of the system and to resolve the issue of the possibility of its acceptance into 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 about their readiness for testing, as well as after the AIS personnel have familiarized themselves 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 functioning, as well as to determine the actual efficiency and adjust, if necessary, the documentation.

Acceptance tests are carried out to determine the conformity of the system to the technical specifications, assess the quality of trial operation and resolve the issue of the possibility of accepting the system into permanent operation.

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 Russian Federation

Federal State Budgetary educational institution higher professional education

Saint Petersburg State University of Technology and Design

Course work

By discipline: "Architecture of information systems"

On the topic: "Designing automated information systems"

INTRODUCTION

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

Here are just a few of the benefits of using computing for an organization:

* Possibility of operational control over the accuracy of information;

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

* Ability to quickly access 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, therefore, today there is a process of rapid development of automated information systems and their implementation in 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 for various enterprises and institutions, characterized by a wide range of input data with various routes for processing these data, is the concentration of complexity at the initial stages of requirements analysis and design of system specifications with relatively low complexity and laboriousness of subsequent stages. In fact, this is where the understanding of what the future system will do, and how it will work to meet the requirements for it, takes place. Namely, the vagueness and incompleteness of system requirements, unresolved issues and mistakes made at the stages of analysis and design give rise to difficult, often unsolvable problems at subsequent stages and, ultimately, lead to the failure of the entire work as a whole. A simple replication of even a very good enterprise management system will never completely suit the customer, since it cannot take into account its specifics. Moreover, in this case, the problem arises 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 operating at the enterprise);

* Phased implementation, etc.

In fact, the problem of complex automation has become relevant for every enterprise. And to do 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 the design;

§ Get acquainted with the main stages of design;

§ Highlight the phases of development of automated information systems;

§ Consider the composition and structure of the technical assignment and technical project.

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

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

Designing is quite acceptable to be considered as a generalizing concept for many intellectual tasks solved in the process of thinking and distinguished in different ways.

The root of the word design emphasizes the connection between the process that has such a name, and the main results of this process, as follows:

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

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

The above two reasons served as the rationale for 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, information systems are the objects of design, and this is quite natural for informatics (since IS are considered its main objects).

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

Information systems in many cases turn out to be subjects of design, i.e. those performers who carry out the design process itself. By studying the design process, we are thereby 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 combined in the interests of achieving the set goals. The systems differ significantly from each other both in composition and in terms of their 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 to the concept of the word information system reflects the purpose of its creation and functioning. Information systems provide collection, storage, processing, search, delivery of information necessary in the process of making decisions on problems from any field. 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 IP implementation methods, the choice of which is based on the requirements of the intended users, which, as a rule, change during the development process.

Adding the term “automated” to the concept of “system” reflects the ways of creating and functioning of such a system.

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

An automated information system (AIS) is a complex of software, technical, informational, linguistic, organizational and technological tools and personnel designed to solve the problems of reference and information services and (or) information support for 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 only to collect and save 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 retrieval in their information arrays (databases).

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

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

· Limited end 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 project planning and management, it is necessary to clearly understand 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 execution of works 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 controllable, 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.

The design of AIS 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, the design of AIS comes down to the sequential formalization of design solutions 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 (development organizations) can take part in the development of the system. In this case, the parent organization is allocated, which coordinates the activities of all co-executing organizations.

AIS design technology is a set of methodology and design tools for AIS, as well as methods and means of its organization (management of 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, means and resources.

The technological process of designing AIS as a whole is divided into a set of sequential-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 one method or another, as a result of which it becomes clear not only what should be done to create a project, but also how, by whom, and in what sequence.

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

· The created project must meet the customer's requirements;

· Maximum reflection of all stages of the project life cycle;

· Ensuring the minimum labor and cost costs for the design and maintenance of the project;

· Technology should be the basis for communication between design and project support;

· Increase in the productivity of the designer;

· Reliability of the design and operation of the project;

· Simple maintenance of project documentation.

The AIS design technology is based on the methodology that defines the essence, the main distinctive technological features.

A design methodology assumes the presence of some concept, design principles, implemented by a set of methods, which, in turn, must be supported by some means.

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

computer-aided design information system

2. PURPOSE AND DESIGN OBJECTIVES

Information systems design always starts with defining the goal 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 the mathematical support of systems includes a complete set of methods and algorithms for solving functional problems. When developing software systems, special attention is paid to the creation of a set of programs and user instructions and the selection of effective software products.

The main task of any successful project is to ensure that at the time of launching the system and throughout its operation, it would be possible to ensure:

· 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 the 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 determinant of system efficiency. Good design is the foundation of a high performance system.

The design of automated information systems covers three main areas:

· Design of data objects that will be implemented in the database;

· Designing programs, screens, reports that will ensure the execution of queries to data;

· 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 method that meets the requirements of the functionality of the system by means of available technologies, taking into account the given constraints.

A number of absolute requirements are imposed on any project, for example, the maximum project development time, the maximum financial investment in the project, etc. One of the difficulties of design is that it is not such a structured task as analyzing the requirements for a project or implementing 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 volume of work required for its implementation, goes through certain states in its development. From the state when “the project does not exist 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 complete completion of the project is usually divided into phases.

The purpose of the initial stages of creating AIS, carried out at the stage of analyzing the organization's activities, is to formulate 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 clarify and clearly articulate what these needs are. To do this, it is necessary to determine the requirements of customers for AIS and map them in the language of models into 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. Conceptual phase

This includes:

· Idea formation;

· 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 basic requirements and restrictions, required material, financial and labor resources;

· Comparative assessment of alternatives;

· Submission of proposals, their examination and approval.

The task of forming the requirements for AIS is one of the most important, difficult to formalize and the most expensive and difficult to correct in the event 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 modifications, 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 the requirements for AIS 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 technical specifications;

§ 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;

§ putting into operation the means of communication of the project participants and means of control over the progress of work.

3.3 Design

At the design phase, subsystems, their interrelationships are determined, and the most effective ways of project and resource use are selected. Typical works of this phase:

§ execution of basic design work;

§ development of private technical specifications;

§ implementation of conceptual design;

§ drawing up technical specifications and instructions;

§ presentation of design development, examination and approval.

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

3.4 Development

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

After the autonomous test has been successfully passed, the module is included in the developed part of the system and a group of generated modules undergoes communication tests, which should track their mutual influence.

Further, a group of modules is tested for reliability of operation, that is, they pass, firstly, tests to simulate system failures, and secondly, tests of operating 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 stability of the system during normal operation and allows you to estimate the uptime of the system. The stability test suite should include tests that simulate the peak load on the system.

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

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

3.5 Commissioning the system

At the stage of putting the system into operation, tests are carried out, the system is being tested in real conditions, negotiations are underway on the results of the project and on possible new contracts.

Main types of work:

§ complex tests;

§ training of personnel for the operation of the system being created;

§ preparation of working documentation, delivery of the system to the customer and putting it into operation;

§ accompaniment, support, service;

§ evaluation of project results and preparation of final documents.

4. COMPOSITION AND STRUCTURE OF THE TECHNICAL DESIGN AND TECHNICAL DESIGN

1. General Provisions

1.1. The terms of reference (TOR) is the main document that defines the requirements and procedure for the creation (development or modernization - further creation) of the information system, in accordance with which the development of the 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. Requirements for IS in the scope established by this standard can be included in the assignment for the design of a newly created object of informatization. In this case, the TK is not developed.

1.4. Requirements included in the TK must comply with the current level of development information technologies and not yield to similar requirements for the best modern domestic and foreign counterparts. The requirements set in the TK should not limit the system developer in finding and implementing the most effective technical, technical, economic and other solutions.

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

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

2. Composition and content

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

1) general information;

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

3) characteristics of objects;

4) system requirements;

5) the composition and content of work on the creation of the system;

6) the procedure for control and acceptance of the system;

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

8) requirements for documentation;

9) development sources.

TK may include applications.

2.2. Depending on the type, purpose, specific features of the project and the conditions for the functioning of the system, it is allowed to formalize sections of the TK in the form of applications, introduce additional, exclude or combine subsections of the TK.

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

2.3. In the section "General information" indicate:

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

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

3) the name of the companies of the developer and 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) the planned start and end dates for the creation of the system;

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

7) the procedure for registration and presentation to the customer of 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. Section "Purpose and goals of creation (development) of the system" consists of subsections:

1) the 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 objects of informatization (objects) on which it is supposed to be used.

2.4.2. In the subsection "Objectives of the system creation", the names and required values ​​of technical, technological, production-economic or other indicators of the informatization object, which must be achieved as a result of the creation of the IS, are given, and the criteria for assessing the achievement of the goals of creating the system are indicated.

2.5. In the section "Characteristics of the object of informatization" 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 the types of security.

The composition of the requirements for the system, included in this section of the TK for IS, is established depending on the type, purpose, specific features and conditions for the functioning 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 their 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 basic characteristics, requirements for the number of levels of hierarchy 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 adjacent systems, requirements for its compatibility, including instructions on how to exchange information (automatically, by sending documents, by phone, etc.);

4) requirements for the modes of operation of the system;

5) requirements for diagnosing the system;

6) prospects for development, modernization of the system.

2.6.1.2. The requirements for the number and qualifications of IS personnel include:

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

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

§ required mode of work of IS personnel.

2.6.1.3. In the requirements for the indicators of the purpose of the IS, the values ​​of the parameters that characterize 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 must 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 the system creation in accordance with the current regulatory and technical documents.

2.6.1.5. Safety requirements include safety requirements for the delivery, commissioning, operation and maintenance of the system.

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

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

2.6.1.8. In the requirements for the safety of information, a list of events is given: accidents, failures of technical means (including loss of power), 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 developer or customer of the system.

2.6.2. In the subsection "Requirements for the functions (tasks)" performed by the system, the following are 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 that are put into operation 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 complex of tasks), for the form of presentation of output information, characteristics of the required accuracy and execution time, requirements for the simultaneous performance of a group of functions, reliability of the results;

§ list and criteria of failures for each function, for which reliability requirements are set.

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

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

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

2) information exchange between the components of the system;

3) information compatibility with related systems;

4) on the application 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 linguistic support of the system, requirements are given for the use of high-level programming languages ​​in the system, languages ​​for interaction between users and technical means of the system, as well as requirements for encoding and decoding data, for data input-output languages, data manipulation languages, means for describing the subject area, for methods organizing a dialogue.

2.6.3.4. For the software of the system, a list of purchased software is given, as well as the 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 to the types of complexes of technical means, software and hardware complexes and other components, admissible for use in the system;

2) to the functional, design 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 the measuring channels;

3) requirements for the 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 metrological support of hardware and software that are part of the measuring channels of the system, means, built-in control, metrological suitability of measuring channels and measuring instruments used in setting up and testing the system;

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

2.6.3.7. For organizational support, the requirements are given:

1) to the structure and functions of subdivisions participating in the functioning of the system or providing operation;

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

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

2.7. The section "Composition and content of work on the creation (development) of the system" must contain a list of stages and stages of work on the creation of the system, the timing of their implementation, a list of organizations - executors of the 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 presented at the end of the relevant stages and stages of work;

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

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 creating the system, indicating their deadlines and executing organizations (if necessary).

2.8. In the section "Procedure for control 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 coordination and approval of acceptance documentation;

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

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 TK is guaranteed;

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

4) the timing and procedure for staffing and staff training.

2.10. In the "Requirements for Documentation" section, the following are 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 determine 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 TK was developed and which should be used when creating the system.

3. Rules of design.

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

3.2. The numbers of sheets (pages) 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 IP.

3.3. The title page contains the signatures of the customer, developer and approving companies, which are sealed. If necessary, the title page is drawn up on several pages. The signatures of the TK developers and officials participating in the agreement and consideration of the draft TK on the IP are placed on the last sheet.

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

3.4. The title page of the supplement to the TK is drawn up in the same way as the title page of the technical assignment. Instead of the name "Terms of Reference" they write "Supplement No. ... to the TOR for AC ...".

3.5. On the subsequent sheets of the addition to the TK, the basis 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 an addendum to the TK, the numbers of the relevant clauses, sub-clauses, tables of the main TK, etc. should be indicated and the words “replace”, “supplement”, “exclude”, “reworded” should be used.

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

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

In the competitive organization of work, the options for the draft TK 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 TK for AC with the participation of the future IS developer.

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

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

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

4. Comments on the draft TOR should be submitted with a technical justification. Decisions on comments should be made by the developer of the draft TK and the customer of the system prior to the approval of the TK on the IS.

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

6. The approval of the draft TK is allowed to draw up a separate document (letter). In this case, under the heading "Agreed" make a link to this document.

7. The approval of the TK is carried out by the heads of the companies of the developer and customer of the system.

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

9. Coordination and approval of additions to the TK are carried out in the manner prescribed for the TK on the IS.

10. Changes to the TK 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 project of the system is the technical assignment 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 solutions for the creation of the system. At this stage, a complex of research and experimental work is carried out to select best options solutions, an experimental check of the main design solutions and the calculation of the economic efficiency of the system are carried out.

In fact, the 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. Problem statement 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 "Statement of tasks and the algorithm for solving" is performed for each individual task included in the EIS, the rest of the documents are common for the entire system. In addition, documents 1, 2, 5, 8 and 9 can be developed for individual subsystems.

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

The economic and organizational part of the technical project contains an explanatory note justifying the development of the system, a list of developers' organizations, a brief description of the object indicating the main technical and economic indicators of its functioning and connections with other objects, brief information about the main design solutions 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 are 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; a diagram of information links between subsystems and between tasks within each subsystem.

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

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

§ economic and mathematical model of the problem (structural and detailed form of presentation);

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

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

§ information stored for communication with other tasks;

§ information accumulated for subsequent solutions to this problem;

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

§ algorithm for solving the problem (sequence of stages of calculation, diagram, calculation formulas);

§ test case (a set of input document forms filled with data, conditional documents with accumulated and stored information, output document forms completed 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 consolidated estimate of the costs associated with the operation of the systems, the calculation of the annual economic efficiency is provided, the sources of which are the optimization of the production structure of the economy (association), the reduction of production costs due to the rational use of production resources and reduction of losses, 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 work on the implementation of the system that must be performed at the stage of detailed design, indicating the timing and responsible persons.

The informational part of the technical project unites documents 4 and 5. The document "Organization of the information base" reflects: sources of information and methods of its transmission for solving the primary complex of functional tasks; a set of indicators used in the system; composition of documents, terms and frequency of their receipt; basic design solutions for the organization of the NSI fund; 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 datasets of reference data, their volume, order and frequency of information correction; proposals for the unification of documentation, a test case for amending the NSI; structural form of NSI with a description of the relationship between the elements; requirements for the technology of creation and maintenance of the fund; methods of storage, search, modification and control, determination of volumes and flows of information of reference data.

"Album of forms of documents" contains forms of reference data.

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

The technical part of the technical design includes: description and justification of the technical data processing process diagram; justification 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 quite a specific enterprise... Features of the subject activity of the enterprise, of course, affect 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 its type of activity, consists of a number of divisions directly carrying out one or another type of company activity, 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 non-productive 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 possibilities that the use of computers entails, it is necessary to use in their work a set of software and hardware tools that best suits the tasks set. Therefore, at present, there is a great need for commercial companies in computer programs that support the work of the company's management, as well as information on how to make the best use of the company's computer equipment.

Implementation of AIS design involves the use of a certain design technology by designers, corresponding to the scale and characteristics of the project being developed.

LIST OF USED LITERATURE

1. Guidelines for 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 - Title. 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: Internet magazine. - Electron. Dan. - [B.m., 2001]. - Access mode: http://compress.ru/article.aspx?id=12282.

4. Vendrov AM, "Designing software for economic information systems" / А.М. Vendra. - 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. "Designing information systems" / V.I. Grekul, G.N. Denischenko, N.L. Korovkin. - M .: Internet University of Information Technologies, 2008.

Posted on Allbest.ru

Similar documents

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

thesis, added 11/22/2015


Types of automated information systems support. Preparation of technical specifications, 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 methodology for designing automated systems based on CASE-technologies. The phase of analysis and planning, construction and implementation of an automated system. Waterfall 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 forms of graphical interface and databases.

thesis, added 06/23/2015


The principles of organizing a system consisting of personnel and a set of tools for automating their activities. Design of corporate automated information systems. Structure, input and output streams, limitations of automated systems.

presentation added on 10/14/2013


Information system concept. 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 her work. Goals and objectives of the analysis of ACS. Components of automated systems. Description of the subject area, input and output data. Building a use case diagram.

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 as a modern type of corporate information system.

presentation added on 10/14/2013


Analysis of the subject area, stages of designing automated information systems. Software development tool systems. The role of CASE tools in the design of the information model. Logical model of the designed database.

On December 1, 2015, an open defense of the Automated Project Management Information System (AIS PU) created by the order of the Ministry of Industry and Trade of Russia took place. The defense, chaired by the First Deputy Minister of Industry and Trade of the Russian Federation Gleb Nikitin, was attended by heads of departments of the Ministry, representatives of the Ministry economic development and the Ministry of Defense of the Russian Federation.

The automated project management system is designed to improve the efficiency of the Ministry of Industry and Trade of Russia in terms of support, maintenance and implementation of projects aimed, among other things, at import substitution, increasing exports, technological development of production, creation and modernization of high-performance jobs and development of industrial infrastructure (industrial parks, technology parks, centers industrial design and engineering).

The main users of the created system, along with the leadership and employees of the ministry responsible for the implementation of state programs and federal targeted programs, will be industrial enterprises implementing their own investment projects, federal bodies executive branch providing state support to enterprises, banks, institutional investors and other financial institutions involved in financing investment projects industrial enterprises and industrial infrastructure development projects.

The system was created by the Russian system integrator "Inline-Technologies" with the involvement of the domestic software developer "LM-Soft". AIS PU was developed on the basis of the Russian 1C platform using free software and proprietary software.

Based on the results of studying the functionality of the system, positive feedback was received both from the management and employees of the Ministry of Industry and Trade, and from the Ministry of Economic Development, which is responsible for the implementation of project management mechanisms in government bodies. In addition, positive feedback on the capabilities of AIS PU was given by industrial enterprises that presented their pilot projects as part of the development of the system. In particular, representatives of FSUE "Krylov State science Center", JSC" Scientific and Production Corporation "Uralvagonzavod", Federal State Enterprise "Scientific Research Institute" Geodesy ". It should also be noted that representatives of Garrison JSC, which is under the jurisdiction of the Ministry of Defense, as well as representatives of some banks with state participation, showed keen interest in the system and interest in joint cooperation in the implementation of project management.

“The created system of project management will not only increase the efficiency of the ministry's employees, but will also allow organizing effective interaction with participants in industrial projects from industrial enterprises, government bodies and development institutions, and financial institutions. AIS PU works on the principle of a “single window” with the maximum use of electronic document management technologies, ”commented Sergey Valuev, Director of the Department of Information Technologies and Public Relations of the Ministry of Industry and Trade, on the implementation of the system.

“The main goal of introducing AIS PU is to improve the quality of control and manageability, to facilitate interaction between authorities and executors of large-scale projects. When developing the system, first of all, industry standards, decrees and orders of the Government, decrees of the President and orders of the Minister of Industry and Trade, as well as the best domestic and foreign practices were taken into account. More than 600 components have been designed for AIS PU, more than 20,000 reference books, dictionaries and classifiers have been uploaded. As part of further work on the development of AIS PU, it is planned to integrate the system as one of the subsystems of the State Information System of Industry currently being created by the Ministry of Industry and Trade of Russia, ”said Sergey Valuev.

The introduction of project management methods is defined as one of the main tools for modernizing public administration and is enshrined in the new edition of the "Main directions of activities of the Government of the Russian Federation for the period up to 2018", signed by Prime Minister Dmitry Medvedev.