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 starting from system analysis and development of initial requirements prior to its installation (installation) on a computer.
The experience in the development and implementation of various classes of AIS has shown high efficiency (including economic) of their application, especially in 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 a model of its activity exists; 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) choice material resources implementation of the designed object - functional, technological and technical aspect (media, data processing tools, etc.),
- d) the spatial (territorial) placement of material means of sale in the allocated or possible areas for use,
- 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. Development of detailed plan work is associated with a description of the processes and their sequence performed at each stage, the necessary specialists, funds and resources. This approach helps to a greater extent to avoid omissions and mistakes. It is necessary for employees implementing the implementation of an automation project, and also has a positive impact on the persons who finance it.
Effective phased implementation design work associated with the need to develop a schedule for their implementation, including resources and terms (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 the automation of various types of activities (management, design, research, etc.), including their combinations, the provisions of GOST 34.601-90 are used. It provides for the following stages and stages of design (table 1).
table 2
|
1. Formation of requirements for the AU |
|
|
2. Development speaker concepts |
|
|
3. Terms of reference |
3.1. Development and approval of technical specifications for the creation of an AU |
|
4. Draft project |
|
|
6. Working documentation |
|
|
7. Commissioning |
|
|
8. Accompaniment of the AU |
|
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 nuclear systems 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 preliminary design contains the fundamental electrical circuits and design documentation of the development object and its components, a list of selected ready-made software and hardware tools (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 refinement 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 Project Customer, 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 surveyed and the need to create an AIS is substantiated, 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 a pre-design study for the implementation of the necessary design work, the following is 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.
Nbsp; AIS life cycle models
AIS life cycle model is a structure that describes the processes, actions and tasks that are carried out and during the development, operation and maintenance throughout the entire life cycle of the system.
The choice of a life cycle model depends on the specifics, scale, complexity of the project and the set of conditions in which the AIS is created and operates.
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 the first At this stage, a study of the problem area is carried out, the customer's requirements are formulated. The result this stage is a technical task (task for development), agreed with all interested parties.
During second stage, according to the requirements of the technical task, certain design solutions are developed. The result is a set project documentation.
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 a finished software product.
On the 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 model of AIS life cycle
The stages of work within the framework of the waterfall model are often called parts of the AIS design cycle, since the stages consist of many iterative procedures for clarifying the system requirements and design options. AIS lifecycle is much more complicated and longer: it can include arbitrary number cycles of clarification, changes and additions to already adopted and implemented design solutions. In these cycles, the development of the 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 stage 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 unreliability of investments.
Delay in receiving results manifests itself in the fact that a consistent approach to the development of the agreement of the 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 analytical 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 drawback 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 in the schedule and complicate the relationship between the development groups performing individual 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 thoroughly synchronization must 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 major 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 have to wait for the results of the work of other teams, therefore, administrative intervention is required to agree on the timing and composition of the submitted documentation.
If errors are detected in the work, a return to the previous stages is necessary; the current work of those who made a mistake is interrupted. The consequence of this is usually a delay in the completion of both the corrected and the new project.
It is possible to simplify the interaction between developers and reduce the 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 results of the development 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 - it requires going back to previous stages and repeating the development process. However, the return to 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 grow, and the deadlines for the delivery of the finished product are constantly being postponed.
II. Iterative model consists of 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.
Flaws 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 is improved 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 - the unfinished work can be completed at the next iteration. The main goal of each iteration is to 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 the introduction of changes to the project when the customer's requirements change;
When using the spiral model, the individual AIS elements are gradually integrated into a single whole. Since the integration starts with fewer elements, there are far 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 greater 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 the products of third-party companies instead of your own developments as component parts (it is important in a market economy when it is necessary to resist the promotion of competitors' products);
An iterative approach makes it easier to reuse components, since 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 because as the system evolves, errors and weaknesses are discovered and fixed 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 are able 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 needs of customers.
Modern methodologies and AIS design technologies that implement them are delivered in electronic form along 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 constitute the core of a set of harmonized AIS development tools. 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 one method or another.
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 the productivity of designers;
· 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 instrumental 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 is carried out on the basis of 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 signs of 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 successive stages and exclude some of them at any stage of the project. It is also allowed to start the work of the next stage before the end of the previous one.
The stages and stages of 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 object of automation;
· 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. Usually, necessary information 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 the creation of the system and to estimate the costs of its implementation (for hardware, for purchased software and for the development of new software).
The result of the strategy definition stage is a document (feasibility study - feasibility study - project), 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 the 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, the expected economic effect (if it can be estimated).
Limitations, risks, critical factors that can affect the success of the project;
The set of conditions under which it is supposed to operate the future system - system architecture, hardware and software resources, operating conditions, service 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 a 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-methodological 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 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.
The functions of the first category provide opportunities that are critical for the successful operation of the system. 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. 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 implementation 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, technical and technological support;
· To determine the composition of subsystems and functional tasks;
· Develop and substantiate the requirements for subsystems;
· Determine the stages of creating the system and the timing of their implementation;
· To make a preliminary calculation of the costs of creating a system and determine the level of economic efficiency of implementation;
· To determine the composition of the performers.
| Chapter | Content |
| General information | The full name of the system and its symbol. Topic code or code (number) of the contract. The name of the enterprises of the developer and customer of the system, their details. The list of documents on the basis of which the IS is created. Scheduled dates for the start and end of work. Information about the sources and the procedure for financing the work. The procedure for registration and presentation to the customer of the results of work on the creation of the system, its parts and individual means |
| Purpose and goals of creation (development) of the system | The type of activity to be automated. List of objects where the system is supposed to be used. Names and required values of technical, technological, production-economic and other indicators of the object, which must be achieved when introducing IS |
| Description of automation objects | Brief information about the automation object. Operating Conditions and Performance Information environment |
| System Requirements | Requirements for the system as a whole: requirements for the structure and functioning of the system (list of subsystems, levels of hierarchy, degree of centralization, methods of information exchange, modes of operation, interaction with adjacent systems, prospects for the development of the system); requirements for personnel (number of users, qualifications, working hours, training procedure); purpose indicators (the degree of adaptability of the system to changes in control processes and parameter values) requirements for reliability, safety, ergonomics, portability, operation, maintenance and repair, protection and safety of information, protection from external influences, for patent purity, for standardization and unification. Requirements for functions (by subsystems): a list of tasks to be automated; time schedule for the implementation of each function; requirements for the quality of implementation of each function, for the form of presentation of output information, characteristics of accuracy, reliability of the results; list and criteria for refusals. Requirements for the types of support: mathematical (composition and scope of mathematical models and methods, standard and developed algorithms); |
Typical requirements for the composition and content of the technical specifications are given in table. 1.6.
Tablitsa 1.6. The composition and content of the technical task (GOST 34.602-89)
| informational (composition, structure and organization of data, data exchange between system components, information compatibility with adjacent systems, classifiers used, DBMS, data control and maintenance of information arrays, procedures for giving legal effect to output documents); linguistic (programming languages, languages of user interaction with the system, coding systems, input-output languages); software (independence of software from the platform, quality of software and methods of its control, use of funds of algorithms and programs); technical; metrological; organizational (structure and functions of operating units, protection against erroneous actions of personnel); methodological (composition of normative and technical documentation) | |
| The composition and content of work on the creation of the system | List of stages and stages of work. Deadlines. Composition of organizations executing works. The type and procedure for the examination of technical documentation. Reliability assurance program. Metrological support program |
| System control and acceptance procedure | Types, composition, scope and test methods of the system. General requirements for the acceptance of works by stages. Admissions committee status |
| Requirements for the composition and content of work on the preparation of the automation object for putting the system into operation | Converting input information to machine-readable form. Changes to the automation object. Terms and procedure for recruiting and training personnel |
| Documentation requirements | List of documents to be developed. List of documents on machine media |
| Development sources | Documents and information materials on the basis of which the TK and the system are developed |
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 sets of tasks 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 qualification requirements on the 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. The composition and content of the technical project are given in table. 1.7
Table 1.7. Content of the technical project
| Chapter | Content |
| Explanatory note | Basis for the development of the system. List of organizations of developers. 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 |
| Functional and organizational structure of the system | Justification of the allocated subsystems, their list and purpose. List of tasks to be solved in each subsystem, with a brief description of their content. Scheme of information links between subsystems and between tasks within each subsystem |
| Problem statement and solution algorithms | 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 problems, 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, range of changes, presentation forms). Reference information (NSI) (content and presentation forms). Information stored for communication with other tasks. Information accumulated for subsequent solutions to this problem. Change information (change system and list of information subject to change). 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) |
| Organization of the information base | Sources of information and methods of its transmission. 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. The composition of the NSI, including the list of details, their definition, range of changes and the list of documents NSI. List of datasets of reference data, their volume, order and frequency of information correction. The structure of the NSI fund with a description of the relationship between its elements; requirements for the technology of creation and maintenance of the fund. Methods of storage, retrieval, modification and control. Determination of volumes and flows of information reference data. Test case for making changes to the NSI. Proposals for the unification of documentation |
| Album of forms of documents | Missing |
| Software system | Justification of the structure of the software. Justification of the choice of the programming system. List of standard programs |
| The principle of constructing a complex of technical means | Description and justification of the flow chart of data processing. Justification and choice of the structure of the complex of technical means and its functional groups. Justification of requirements for the development of non-standard equipment. A set of measures to ensure the reliability of the functioning of technical means |
| Calculation of the economic efficiency of the system | A summary estimate of the costs associated with the operation of the systems. Calculation of the annual economic efficiency, the sources of which are the optimization of the production structure of the economy (association), the reduction of the cost of production due to the rational use of production resources and the reduction of losses, improvement of management decisions |
| Measures to prepare the facility for the implementation of the system | List of organizational measures to improve business processes. 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 |
| List of documents | Missing |
At the stage "Working documentation", a software product is created and all accompanying documentation is developed. 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 upon 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 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) input-output 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 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 the 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
Debugging methodology takes symptoms into account possible mistakes:
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, thoughtful approach to debugging, plan your 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 debugging 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 analysis and control flow analysis to validate and establish data scopes for different routes of program execution.
8. Use different 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 program code for performance, taking into account the most likely errors.
9. Document any errors found and fixed, their differences, location and type. This information will be helpful in preventing 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 guess 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 familiarizing the AIS personnel with the operational documentation.
Trial operation of the system is carried out in order to determine the actual values of the quantitative and qualitative characteristics of the system and the readiness of personnel to work in the conditions of its functioning, as well as to determine the actual efficiency and adjust, if necessary, the documentation.
Acceptance tests are carried out to determine the compliance of the system with the technical specifications, assess the quality of trial operation and resolve the issue of the possibility of accepting the system for permanent operation.
Compliance with the above principles is necessary when performing work at all stages of the creation and functioning of AIS and AIT, i.e. throughout their entire life cycle.
Life cycle(Life Cycle) - the period of creation and use of AIS (AIT), starting from the moment the need for this automated system arises and ending with the moment of its withdrawal from use.
The life cycle of AIS and AIT allows us to distinguish four main stages, each design stage is divided into a number of stages and provides for the corresponding work:
Stage I - pre-project inspection:
1st stage - the formation of requirements, the study of the design object, the development and selection of a variant of the concept of the system;
2nd stage - analysis of materials and formation of documentation - creation and approval of a feasibility study and technical specifications for the design of the system based on the analysis of survey materials collected at the first stage.
Stage II - design:
1st stage - technical design, where the search for the most rational design solutions for all aspects of development is carried out, all components of the system are created and described, and the results of the work are reflected in the technical project;
2nd stage - detailed design, in the process of which the development and refinement of programs, adjustment of database structures, creation of documentation for the supply, installation of technical means and instructions for their operation, preparation of job descriptions for each user is carried out. Technical and working projects can be combined into a single document - a technical working project.
Stage III - system input into action:
1st stage - preparation for implementation- installation and commissioning of technical means, loading of databases and trial operation of programs, personnel training;
2nd stage - pilot testing all components of the system before transfer to industrial operation, personnel training;
3rd stage (final stage of AIS and AIT creation) - putting into commercial operation; is drawn up by acts of acceptance and delivery of works.
Stage IV - industrial operation - in addition to day-to-day operation, it includes maintenance of software tools and the entire project, operational maintenance and database administration.
5. Methods of design work
The creation of automated information systems and technologies can be carried out in two ways. The first option assumes that this work is carried out by specialized firms with professional experience in the preparation of software products of a specific orientation. According to the second option, the design and creation of developments is carried out by designers-programmers who are on the staff of enterprises, where new information technologies and systems are created.
In the process of developing automated systems, workplaces and technologies, designers are faced with a number of interrelated problems:
It is difficult for a designer to obtain comprehensive information to assess the requirements for new system or technology.
The customer often does not have sufficient knowledge about automation problems to judge the feasibility of implementing certain innovations. At the same time, the designer is faced with an excessive amount of detailed information about the problem area, which causes difficulties in modeling and formalized description of information processes and solving functional problems.
Due to its large volume and technical terms, the specification of the system being designed is often incomprehensible to the customer, and its excessive simplification cannot satisfy the specialists who create the system.
With the help of well-known analytical methods, it is possible to solve some of the listed problems, however, a radical solution is provided only by modern structural methods, among which the methodology of structural analysis occupies a central place.
Structural analysis is called the method of studying a system, which begins with its general overview and then details, acquiring a hierarchical structure with an increasing number of levels.
Structural analysis involves dividing the system into levels of abstraction with a limited number of elements at each of the levels (usually from 3 to 6-7). At each level, only the details that are essential for the system are highlighted.
The structural analysis methodology is based on the principles of decomposition and the principle of hierarchical ordering.
Decomposition principle involves solving difficult problems by breaking them down into problems that are easy to understand and solve.
The principle of hierarchical ordering declares that the system can be understood and built in levels, each of which adds new details.
On the pre-project stage a study and analysis of all the features of the design object is carried out in order to clarify the customer's requirements. In particular, a set of conditions is identified under which it is supposed to operate the future system (hardware and software resources; external conditions of its functioning; the composition of people and work related to it and participating in information and management processes), a description of the functions performed by the system, etc. P.
At this stage, the following are determined:
System architecture, its functions, external conditions, distribution of functions between hardware and software;
Interfaces and distribution of functions between a person and a system;
Requirements for software and information components of the system, necessary hardware resources, requirements for a database, physical characteristics of system components, their interfaces.
The quality of further design decisively depends on the correct choice of analysis methods, formulated requirements for the newly created technology.
The methods used at the pre-project survey stage are divided into:
- Methods for studying and analyzing the actual state of an object or technology. These methods allow you to identify bottlenecks in the studied processes and include: oral or written questioning; written questionnaire; observation, measurement and evaluation; group discussion; analysis of tasks; analysis of production and management processes.
In general, the methods of studying and analyzing the actual state of management activities and the existing technology for solving problems are intended to collect the necessary materials and form the basis for the design of AIS and AIT.
- Methods for generating a given state. They are based on the justification of all the AIS components based on the goals, requirements and conditions of the customer. These methods, which are working tools of designers, include methods: modeling of the control process; structural design; decomposition; analysis of the information process.
- The method of modeling the control process. In the process of studying the design object, economic-organizational and information-logical models are built. They reflect business and management relationships, as well as the information flows associated with them.
- Structural design method allows to divide the whole complex of tasks into visible and analyzable sub-complexes (modules).
- Decomposition method modules provides for the further division of sub-sets of tasks into separate tasks, indicators.
- Analysis of information processes is designed to identify and represent the relationship between the result, the processing process and data entry. It is also used to analyze and form information links between the workplaces of management workers, specialists, technical personnel and information technology. For this purpose, the input and output information, as well as the information processing algorithm for each workplace, are described.
- Methods for graphing actual and target states provide for the use of a visual representation of information processing processes. The most famous of them include the block diagram method, arrow diagrams, network diagrams, process flow tables.
If at the pre-design stage the requirements for the creation of AIS and AIT must be formulated in the terms of reference, then the design must answer the question: "How will the system meet the requirements for it?"
As a result of the design stages, a system design should be obtained within the budget of the allocated resources.
The design stages include the following main work:
Development of goals and organizational principles of AIS;
Formation of a version of AIS and AIT;
Debugging programs;
Trial operation;
Delivery of the AIS and AIT project.
In the process of organizing the design, a variety of decisions are made that affect the dynamics and quality of work. Therefore, for each design stage, the following are determined: expected results and documents; personal functions of the head; decisions made by the head; functions of the customer and developer of AIS and AIT.
The design and as-built documentation includes: instructions for work processes, programs for workplaces, instructions for drawing up documents, recommendations for using information, methods, decision tables, etc.
In modern conditions, AIS, AIT and AWP, as a rule, are not created from scratch. The need for timely, high-quality, operational information and its assessment as the most important resource in management processes, as well as the latest achievements of scientific and technological progress, necessitate the restructuring of functioning AIS and the creation of AIS and AIT on new technical and technological bases.
Send your good work in the knowledge base is simple. Use the form below
Students, graduate students, young scientists who use the knowledge base in their studies and work will be very grateful to you.
Posted on http://www.allbest.ru/
Ministry of Education and Science of the Russian Federation
Federal State Budgetary educational institution higher professional education
Saint Petersburg State University 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; all 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 demands made on 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 human activity different methods of separating components (sub-processes) are used and different results are obtained - such as research and development, analysis and synthesis, etc.
It is quite acceptable to consider design as a generalizing concept for many intellectual tasks that are solved in the process of thinking and are 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 that main activity, which 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 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, and 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) is an interconnected set of tools, methods and personnel used for storing, processing and issuing information in order to achieve the set 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.
An 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, information, linguistic, organizational and technological means 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:
· The limitation of the ultimate 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 for the possibility of 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 manageable, that is, some characteristics are distinguished by which the progress of the project can be constantly monitored. 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 a particular method, 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 chosen design technology should be the reflection of interrelated design processes at all stages of the AIS life cycle. The main requirements for the selected design technology include the following:
· The created project must meet the 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 design organization involves the determination 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 choice 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. A good design solution forms the basis 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 the 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 requirements for AIS is one of the most responsible, difficult to formalize and the most expensive and difficult to correct in case of 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 a customer;
§ putting into operation the means of communication of the project participants and means of monitoring the progress of work.
3.3 Design
At the design phase, subsystems are determined, their interrelationships, and the most effective ways of design and resource use are selected. Characteristic works 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 test of the automated information system is 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 TASK 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 volume 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. The requirements included in the TK must correspond to the current level of development of information technologies and not be inferior to similar requirements for the best modern domestic and foreign counterparts. The requirements set in the TK should not restrict 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 duplicating 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 on 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) systems 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 "The goals of creating a system", the names and required values of technical, technological, production-economic or other indicators of the object of informatization, which must be achieved as a result of creating an IS, are given, and the criteria for assessing the achievement of the goals of creating a 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;
§ the required mode of operation of the 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 of 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 requirements for ensuring safety during delivery, commissioning, operation and maintenance of the system.
2.6.1.6. The requirements for ergonomics and technical aesthetics include IP indicators that set required quality human-machine interaction and the comfort of the working conditions of the 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 is given:
§ for each subsystem, a list of functions, tasks or their complexes (including those that ensure 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 phases;
§ 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, the reliability of the results;
§ a list and criteria of failures for each function for which reliability requirements are set.
2.6.3. In the subsection "Requirements for the 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) to 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 divisions 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.
V this section also quote:
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 verified 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, which 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 TOR 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) a 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 state standards that determine the requirements for documenting system elements, 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 approval 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 IS.
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, with the participation of the future IS developer, the final version of the TK for AC.
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 IS 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 (departments) 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 the prescribed manner.
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 reference 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 the 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 the facility 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 the best solutions, experimental verification 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-organizational, informational, mathematical, 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 dedicated to organizational and functional structure systems, given: 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 problems, 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 summary 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 in the cost of production due to the rational use of production resources and the 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 creating and maintaining a 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 choosing a programming system, including a list of standard programs.
The technical part of the technical project 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
Development of an information system, as a rule, is carried out for a very specific enterprise. The specifics 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 that directly carry 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 of commercial companies for computer programs that support the work of the company's management, as well as for information on how to optimally use the computer equipment available to the company.
The 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 on 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 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 on 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. The logical model of the designed database.
Personal data privacy policy and personal data processing conditions
This Privacy Policy for personal data applies to all personal data that TEKORA may receive from you while you use the company's websites.
By filling out the form on the website http: //www.site/ and other websites of the TEKORA Company that collect data and refer to these conditions, you give your voluntary consent to the TEKORA Company to process the following personal data using automated processing tools or without them: surname, name, patronymic; place of work, name of the position held; E-mail address; contact phone number.
By providing TEKORA with the information necessary to initiate further interaction, you consent to its use in accordance with this Policy.
If you do not agree with the terms and conditions set forth in this document, please do not use these websites or fill out information request forms.
TEKORA means:
JSC "TEKORA", Legal address: 119285 Moscow, st. Mosfilmovskaya, 22, building 1.
Postal address: 117997, GSP-7, Moscow, st. Profsoyuznaya, 65, office 369.
The processing of personal data means the actions provided for by the legislation of the Russian Federation, including the Federal Law of 27.07.2006 N 152-FZ "On Personal Data".
By submitting your personal data, you agree to their processing, including collection, recording, systematization, accumulation, storage, clarification (update, change), extraction, use, transfer, depersonalization, deletion, destruction by TEKORA in order to process your orders and requests to carry out activities to promote goods, works, services or objects of intellectual property on the market by making direct contacts with you using means of communication, evaluating and analyzing the site, analyzing purchasing characteristics and providing personal recommendations; informing you about promotions, discounts and special offers through electronic mailings, as well as in order to contact you (by e-mail and / or phone).
By providing TEKORA with your personal data, you can be sure that they will not be provided to third parties, except when it is required in the interests of business relations between you and TEKORA. In some cases, TEKORA is obliged to transfer your personal data to third parties in connection with the requirements of applicable law. For example, this may be the case when there are grounds to suspect a crime or misuse of the TEKORA website.
You can opt out of receiving emails at any time, however, this does not affect the transmission of emails that are required in order to conduct a business relationship between you and TEKORA.
These websites contain several links to companies with which TEKORA maintains business relationship... The TEKORA Company is not responsible for compliance with the requirements for the protection of personal data in relation to the use of the websites of the TEKORA Company partners. For information about data protection when visiting these sites, please refer to the privacy policies of the respective companies' websites.
Personal data collected by TEKORA is stored on secure servers. Access is allowed only to a limited number of authorized persons who need it in order to manage the websites of the TEKORA Company or ensure their proper functionality, especially in terms of technical support.
With this consent, you confirm that you are the subject of the provided personal data, and also confirm the accuracy of the data provided.
