Organization information system module. Integration of enterprise information systems. Functional tasks of the enterprise information system and the main modules of modern enterprise information systems. integration of modules
Workstations to be automated
Performance requirements
List of generated reports
4.4.2. Requirements for a production planning and control system
The information system should provide enterprise resource planning and order production management.
Requirements for IS functionality:
1. Configuration management of finished products (FP):
Maintaining normative and reference information on the composition of the GP with the ability to indicate the period of relevance of the specification and with the possibility of being in production of the GP with several different specifications;
Maintaining normative and reference information on the manufacturing technology of products that are part of the GP with the ability to indicate the period of relevance of the technologies and with the possibility of being in production of the GP with several different technologies;
2. Sales management:
Viewing the history of customer relationships;
Registration / correction of the client's application with an indication of the list of SOEs, volumes, date of shipment, sale price and any additional conditions;
View the current economic indicators (cost estimates) of the ordered SOE;
3. Production planning:
Formation of the equipment availability schedule indicating the number of available standard hours for each day of the planned period;
Formation of a production plan with an indication of the manufactured product, its quantity, equipment used, division for each day of the planning period;
Formation of a plan for production needs in materials and components;
Control and management of equipment loading according to the formed production plan;
Making adjustments to the production plan during its execution;
Plan-fact analysis of the production plan;
4. Production management:
Formation of shift tasks (orders) for the manufacture of products;
Assigning / reassigning to performers' orders and fixing the execution of orders with an indication of the number of manufactured products, the number of defective products and the reasons for the occurrence of marriage;
Management of storage and movement of inventory items (TMC) in production;
5. Supply management:
Formation of a purchase order based on the plan of the need for materials and components, indicating the supplier, the nomenclature of goods and materials, the quantity and delivery time;
Formation of purchase orders based on one-time orders for goods and materials from departments;
Controlling and tracking the process of completing purchase orders;
Operational control of residues;
Plan-fact analysis of deliveries;
6. Cost management:
Formation of the planned (standard) cost of the SOE;
Fixing the actual production costs;
Calculation of the actual cost of the SOE;
Plan-actual cost analysis.
Requirements for calculating the standard cost of an order
The standard cost of the product and the entire order is calculated using the following method:
1. The direct material component of the standard cost of a product is formed on the basis of information about the standard composition of this product (specification) and the established accounting prices for the inventory items included in this specification. For the specification, the use of several items of material costs is allowed.
2. The amount of direct wages is calculated on the basis of the standard operational composition of the product. The following are set: the standard duration of each operation, the worker's profession required for this operation, as well as the worker's rank. Also, the system introduces monetary rates of standard hours for the professions of workers and their categories.
3. The standard value of indirect costs is calculated as a percentage of the specified base (the amount of direct costs for the specified item).
To carry out this calculation, the following data must be available in the Information System:
1. Specification of the manufacture of the product (as well as the specification of the manufacture of all semi-finished products of our own production included in this product);
2. Manufacturing technology of the product and the semifinished products included in it: what operations should be performed and in what time. In addition, for each operation, the profession and the category of the worker are specified, which are necessary for its implementation (for the release of this particular product);
3. Protocol of accounting prices for used goods and materials;
4. Monetary rates of standard hours for professions and ranks.
Requirements for calculating the actual cost of the order
The actual cost of the product and the entire order is calculated using the following method:
1. Direct material costs for the release of the product are calculated based on the actual data on the consumption of materials by the shop for production redistributions. In this case, the cost of all semi-finished products included in this product is first calculated. The total assessment is carried out according to the methodology adopted in the accounting policy of the enterprise.
2. The wages of direct production workers are calculated on the basis of data on the closure of shop orders. In the event that orders are not recorded in the IS, wages refer to direct costs subject to distribution, i.e. distributed among the manufactured products according to a certain base.
3. Depreciation of direct production equipment is included in direct costs if for each redistribution the equipment (machine tool) used in this redistribution is indicated.
4. Direct costs to be allocated:
Basic materials that are consumed less frequently than for each redistribution (for example, chemicals, the rate of which per unit of production is so small that it makes no sense to take into account their alternate consumption even at this rate);
Wages of workers in the absence of information about their distribution by turnover;
Depreciation of direct equipment if only its total monthly amount is available, without breakdown by redistribution.
Such costs are allocated to the manufactured items according to the selected distribution base (for example, in proportion to direct material costs).
1. General production costs (account 25 BU): distributed to manufactured products in proportion to the selected distribution base. The share of such expenses may or may not remain in the work in progress in accordance with the accounting policy adopted at the enterprise.
2. General operating and selling expenses (accounts 26 and 44) are recognized as expenses of the current period and relate to selling expenses. The distribution of such costs to the cost of finished products can be seen using a special report.
Information system performance requirements
<Раздел должен содержать требования к производительности Информационной системы. Вводится в шаблон>.
Reliability requirements
<Раздел должен содержать требования к надежности Информационной системы. Например:>
Requirements for ensuring reliable (stable) functioning of the Information system
Reliable (stable) functioning of the Information System must be ensured by the implementation by the Customer of a set of organizational and technical measures, the list of which is given below:
1. Organization of uninterrupted power supply of technical equipment;
2. Use of licensed software;
3. Regular implementation of the recommendations of the Ministry of Labor and Social Development of the Russian Federation, set out in the Decree of July 23, 1998 "On the approval of inter-industry standard time standards for work on the maintenance of personal computers and office equipment and maintenance of software";
4. Regular fulfillment of the requirements of GOST 51188-98. "Protection of information. Testing software for availability computer viruses»;
5. Regular backup of the databases of the Information System by means of the Information System itself or by means of the used database management system.
Introduction
The thesis under consideration was written on the basis of Donetsk OJSC Donetsk Manufactory for the Cleonelly store.
One of the leading activities of Donetsk Manufactory OJSC produces a wide range of garments, mainly bathrobes, sheets and towels. In addition, the company produces dyed cotton yarn for weaving and knitting.
The development of automated information technologies goes hand in hand with the emergence of new types of technical means for processing and transmitting information, improving the organizational forms of using computers, saturating the infrastructure with new means of communication. The development of market relations has led to the emergence of new types of entrepreneurial activity and, above all, to the creation of firms engaged in information business, the development of information technologies, their improvement, the spread of components of automated information technologies, in particular software products that automate information and computing processes. They also include computing equipment, communication facilities, office equipment and specific types of services - information, technical and consulting services, training, etc. This contributed to the rapid dissemination and effective use of information technologies in management and production processes, to their almost universal application and great diversity.
Enterprises engaged in the design and development of devices for various purposes currently widely use various means of both computer-aided design - CAD (CAD), and monitoring of production processes - ACS (SCADA / DCS). However, for devices of our own design, it is necessary to develop our own means of monitoring their performance and analyzing product quality.
The technological process of accounting for products in a warehouse in a Cleanelly store includes the stage of keeping records of products sold.
The purpose of this diploma project is the implementation of an automated workstation (AWP), which allows accounting for products in the store's warehouse.
To achieve the above goal, it is necessary to solve the following tasks:
¾ analyze the business processes of the store;
¾ investigate information flows arising at the stage of delivery of a product being developed;
¾ develop conceptual and logical data models;
¾ develop software for AWP of production accounting
¾ to assess the economic efficiency of the information system.
1 Development of software requirements
1.1 Analysis of existing solutions
Currently, there is a wide range of companies that combine both the direct development of products and the development of control systems for these products. Such systems are being developed by such well-known companies as 1: C Enterprise and Zvezda. In such systems, control and accounting of materials is carried out, and the processing of the information received.
"1C: Enterprise" is a system of applied solutions built on the same principles and on a single technological platform. The manager can choose a solution that meets the current needs of the enterprise and will further develop as the enterprise grows or the automation tasks expand.
The 1C: Enterprise software system is designed to solve a wide range of accounting and management automation tasks that dynamically developing modern enterprises face. Solution of urgent problems of accounting and management The composition of the programs of the 1C: Enterprise system is focused on the actual needs of enterprises. Firm "1C" produces serialized software solutions designed to automate typical accounting and management tasks at enterprises. A distinctive feature of the 1C edition solutions is a thorough study of the composition of the functionality included in the standard solutions. Firm "1C" analyzes the experience of users using programs of the system "1C: Enterprise" and monitors changes in their needs.
The main advantages of my Wholesale Base system include the relatively low cost of implementing this system, as well as a number of other advantages:
¾ Reliability of the created applications. The software package (PC) must be resistant not only to user errors, but also to failures in the communication system.
¾ Ease of use of the interface;
¾ High level of system security, which implies not only control over the availability of certain system resources and information security at all stages of operation, but also tracking the actions performed with a high degree of reliability.
1.2 Domain analysis
The peculiarity of the analysis of the subject area is that it allows you to see the entire set of operations of the organization.
CASE is designed to analyze and reorganize business processes. – All Fusion Process Modeler (BPwin) top-level tool supporting IDEF0 (Functional Model), DFD (Dataflow Diagram) and IDEF3 (Workflow Diagram) methodologies. BPwin is a powerful software product for creating models to analyze, document and plan changes in complex business processes. BPwin offers a tool for collecting all relevant information about the operation of the enterprise and graphically depicting this information in the form of a coherent and consistent model.
In terms of system functionality. Within the framework of the IDEF0 (Integration Definition for Function Modeling) methodology, a business process is represented as a set of work elements that interact with each other, and information, human and production resources consumed by each work are shown. The functional model is designed to describe the existing business processes in the enterprise (the so-called AS-IS model) and the ideal state of affairs – what to strive for (TO-BE model). The IDEF0 methodology prescribes the construction of a hierarchical system of diagrams, i.e. single descriptions of system fragments. First, a description of the system as a whole and its interaction with the outside world (context diagram) is carried out, after which a functional decomposition is carried out – the system is divided into subsystems and each system is described separately (decomposition diagrams). Then each subsystem is broken down into smaller ones, and so on to achieve the desired level of detail.
If in the process of modeling it is necessary to highlight the specific aspects of enterprise technology, BPwin allows you to switch to any branch of the model to DFD or IDEF3 notation. Data Flow Diagramming (DFD) diagrams can complement what is already reflected in the IDEF3 model, as they describe data flows, allowing you to trace how information is exchanged between business functions within the system. At the same time, DFD diagrams ignore the interactions between business functions.
In terms of the sequence of work performed. And an even more accurate picture can be obtained by supplementing the model with IDEF3 diagrams. This method draws attention to the order in which the events are executed. Elements of logic are included in IDEF3, which allows you to model and analyze alternative scenarios for the development of a business process.
To consider the business processes running in the store's warehouse, only two methodologies IDEF0 and DFD need to be used. The process of modeling a system in IDEF0 begins with defining the context, i.e. the most abstract level of description of the system or business processes in general.
Model IDEF0... To study the business processes "Formation of a supplier's order", "Receipt of goods", "Release of goods", consider the diagrams that are presented in the form of an IDEF0 diagram. The IDEF0 system is presented as a collection of interacting activities or functions.
The IDEF0 methodology is based on four main concepts.
The first is the concept functional block (Activity Box)... A functional block is graphically depicted in the form of a rectangle and personifies some specific function within the framework of the system under consideration
Each of the four sides of a functional block has its own specific meaning (role), while:
The top side is Control;
The left side is Input;
Right side has the value "Output";
The bottom side is set to Mechanism.
The second "whale" of the IDEF0 methodology is the concept of an interface arc (Arrow). The graphical display of the interface arc is a unidirectional arrow. Each interface arc must have its own name (Arrow Label). With the help of interface arcs, various objects are displayed that, to one degree or another, determine the processes taking place in the system. In this case, the arrows, depending on which face of the work rectangle they enter or which face they leave, are divided into:
Input arrows (included in the left side of the functional block) - represent data or objects that are changed during the execution of work;
Control arrows (included in the upper face of the functional block) - depict the rules and restrictions due to which the work is performed;
Exit arrows (exit from the right side of the functional block) - represent data or objects that appear as a result of work;
Arrows of the mechanism (included in the lower edge of the functional block) - represent resources (for example, equipment, human resources).
The third basic concept of the IDEF0 standard is Decomposition. The decomposition principle is used when breaking down a complex process into its constituent functions.
Decomposition allows you to gradually and structured represent the system model in the form of a hierarchical structure of individual diagrams, which makes it less overloaded and easy to digest.
The last of the IDEF0 concepts is the Glossary. For each of the IDEF0 elements: diagrams, functional blocks, interface arcs, the existing standard implies the creation and maintenance of a set of relevant definitions, keywords, narratives, etc. that characterize the object displayed by this element. This set is called a glossary and is a description of the essence of this element.
Consider the diagrams of business processes occurring in the warehouse of the OJSC DMM store, "Cleonelly":
For the general visibility of the system, it is necessary to build the context "Activity of the warehouse of the enterprise" (see Figure 1.1).
Figure 1.1 - Diagram "Warehouse activities of the enterprise"
After the context is established, decomposition is performed, i.e. building the following diagrams in the hierarchy.
Each subsequent diagram is a more detailed description of one of the works in the higher diagram. An example of decomposition of contextual work is shown in Figure 1.2. Thus, the entire system is divided into subsystems to the desired level of detail, this system is divided into three levels.
Figure 1.2 - First level decomposition diagrams
Figure 1.3 - Diagram "Clearance of goods"
Figure 1.4 - Diagram "Goods issue"
Figure 1.5 - Diagram "Posting goods"
DFD. This methodology is based on the construction of a model of the analyzed IS - projected or actually existing. In accordance with the methodology, the system model is defined as a hierarchy of data flow diagrams (DFD), describing the asynchronous process of transforming information from its input into the system to its output to the user. DFD diagrams are usually built to visualize the current work of an organization's workflow system. Most often, DFD diagrams are used to complement the business process model implemented in IDEF0.
The main components of a data flow diagram are:
External entities (graphically depicted as a square) - denote a material object or individual, which is a source or receiver of information. For example: customers, personnel, suppliers, clients, warehouse;
Systems / subsystems (graphically looks like a rectangle with rounded corners) - works denoting functions or processes that process and change information;
Data storages are an abstract device for storing information that can be put into a drive at any time and after a while can be retrieved, and there can be any way of placing and retrieving. In general, the data store is a prototype of the future database and the description of the data stored in it should be linked to the information model;
Data streams - defines the information transmitted over a certain connection from the source to the receiver. The flow of data in the diagram is represented by a line ending with an arrow that indicates the direction of the flow.
Consider the Issue Data Flow Diagram (DFD) Figure 1.6. This diagram shows the movement of documents when a "product requisition" arrives at an organization.
Figure 1.6 - DFD "Goods issue" diagram
Consider the following data flow diagram "Product Clearance" (see figure 1.7). It shows the process of work execution and the movement of documents during the "goods issue".
Figure 1.7 - DFD Diagram "Clearance of goods"
In data flow diagrams, all the symbols used add up to a big picture, which gives a clear idea of what data is used and what functions are performed by the workflow system. At the same time, it often turns out that the existing information flows that are important for the company's activities are not implemented reliably and need to be reorganized. *******
The organizational structure of an enterprise selling terry products is considered on the example of the company OJSC “Donetsk Manufactura M” of the Cleonelly store:
In the direction of the development of systems for control and accounting of materials, they can successfully solve problems:
1. This is control over the supplied and stored goods.
2. Information about suppliers and consumers
3. It also contains information information and operations on the product
4. Contains a log of the released goods report
5. Contains a directory of goods
6. Automation of warehouse functions (receipt, consumption, write-off, goods reservation)
7. Registration and storage of invoices for purchased and sold goods and services, as well as billing for prepayment, deferred payment and delivery of goods
8. Creation of invoices and accounting of issued goods
9. Carrying out an inventory of warehouses with the creation of a collation statement, an act of shortage and surplus
10. Creation of sets of goods
As indicated, the main field of activity of this enterprise is the sale of cotton products. The design process includes many stages carefully worked out by the management structures of the design enterprises during the entire life of the enterprise. This process cannot be changed at the same time, since it involves many departments of the enterprise itself, external subcontractors and clients of the project enterprise. Therefore, enterprises are wary of the implementation of information systems related to design and development management processes. As a rule, Russian enterprises use their own developments in this area.
1.3 Collecting Requirements
When designing the information system (IS) of the "Workstation of the Wholesale Store", it was necessary to collect requirements that would help create an interface in such a way that the end user (store employee) was comfortable working with the developed IS.
Requirements development is the process that includes the activities required to create and approve a system requirements specification document.
To implement the process of automation of accounting and control of materials, it is necessary that the information system be able to fulfill the following functional requirements:
¾ documenting the results.
¾ The information system must be implemented as a program based on the Visual Fox Pro integrated environment.
The program works in the Windows 2000 / NT / XP operating system.
There are four main stages in the requirements development process (Figure 1.8):
Analysis of the technical feasibility of creating a system;
Formation and analysis of requirements;
Specification of requirements and creation of relevant documentation;
Attestation of requirements.
The collection of requirements is an important stage in software design, since it is here that all customer requirements must be correctly and correctly formulated.
1.4 Requirements specification
Determining the correct requirements is probably the most critical step in a software project. It is very important that the format of the project matches the requirements for the software assembled by the development team, otherwise these requirements cannot be supported and presented in the software product. Software Requirements Specification (SRS) is central to the entire software development lifecycle. It is not only a derivative document that defines the specifications of a software project, but also the main document used for the purpose of conducting qualification and acceptance tests. Attestation is an assessment of the quality of the project managers' work. It determines the degree of compliance of a software product with established requirements. The SRS specification acts as a mechanism for recording system requirements that are used as criteria for attestation.
Based on the SRS, agreement is reached between customers and manufacturers of the software product. The SRS specification fully describes the functions that the developed software product must perform. This allows potential users to determine the degree to which the product meets their needs, as well as ways of modifying the product so that it is most useful in solving their problems.
Decreases development time. Various groups within the customer's organization are involved in the preparation of the SRS specification. They thoroughly investigate all requirements even before the actual development of the project begins. This reduces the likelihood of subsequent re-design, coding, and testing.
A careful study of the requirements in the SRS specification can reveal oversights, misunderstandings, and inconsistencies early in the development cycle, when problems are much easier to fix than later.
The SRS specification becomes the basis for cost estimation and scheduling. The product description is the real basis for estimating the cost of a project. In an environment where the concept of a formal proposal exists, the SRS is used to validate the estimate of a proposal or price.
With well-written specifications, SRSs at the organizational level can develop much more productive certification and audit plans. As part of the development contract, the SRS provides a reference point for assessing compliance with specifications.
The SRS specification makes it easier to transfer the software product to new users, as well as to install it on other computers. Thus, it becomes easier for customers to transfer the software product to other departments of the organization, and for developers to transfer to other customers.
The SRS specification serves as a basis for modernization. This document deals with the product itself, not the project development process, so it can be used to expand the completed product.
After the process of defining and specifying the requirements is complete, it is necessary to carry out the attestation of the requirements.
The specification of the requirements for the software project should be presented in Appendix A.
1.5 Attestation of requirements
The validation must demonstrate that the requirements actually define the system that the customer wants to have. Requirements validation is important because an error in the requirements specification can lead to system rework and high costs if discovered during the development process of the system or after it is put into operation.
During the requirements attestation process, different types of requirements documentation checks should be performed:
1. Checking the correctness of the requirements.
2. Checking for consistency.
3. Checking for completeness.
4. Check for feasibility.
There are a number of requirements attestation methods that can be used together or each separately:
1. Review of requirements.
2. Prototyping.
3. Generation of test scripts.
4. Automated analysis of consistency.
Prototyping is the most visual for the system customer.
Before starting prototyping, you can create a user interface flow diagram. This diagram is used to study the relationships between the main elements of the user interface.
The next step in requirements validation is direct prototyping.
A software prototype is a partial or possible implementation of a proposed new product. Prototypes allow you to accomplish three main tasks: clarifying and completing the requirements formulation process, exploring alternative solutions, and creating the final product.
The prototype of the main menu of this module is shown in Figure 1.9.
1.6 Choosing an information system design methodology
The essence of the structural approach to the development of IS lies in its decomposition (division) into automated functions: the system is divided into functional subsystems, which in turn are divided into subfunctions, subdivided into tasks, and so on. The partitioning process continues down to specific procedures. At the same time, the automated system maintains a holistic view in which all the constituent components are interconnected.
All of the most common structural approach methodologies are based on a number of general principles. The following principles are used as two basic principles:
Divide and Conquer - the principle of solving complex problems by breaking them down into many smaller, independent problems that are easy to understand and solve;
The principle of hierarchical ordering is the principle of organizing the constituent parts of a problem into hierarchical tree structures with the addition of new details at each level.
In structural analysis, there are mainly two groups of tools that illustrate the functions performed by the system and the relationships between data. Each group of funds corresponds to certain types of models (diagrams), the most common, among which are the following:
SADT (Structured Analysis and Design Technique) models and related functional diagrams;
DFD (Data Flow Diagrams) data flow diagrams;
ERD (Entity-Relationship Diagrams) entity-relationship diagrams.
At the design stage of the IS, the models are expanded, refined and supplemented with diagrams that reflect the structure of the software: software architecture, program block diagrams and screen diagrams.
The listed models together give Full description IP regardless of whether it is existing or newly developed. The composition of the diagrams in each specific case depends on the required completeness of the description of the system.
2 DESIGNING THE INFORMATION SYSTEM
2.1 Architectural design
When creating any complex information system, a critical aspect is its architecture, where it represents a conceptual vision of the structure of future functional processes and technologies at the system level and in interconnection. Typically, complex information systems of organizations are designed as a composition of high-level interacting components, which may themselves be systems. An organization's information system architecture makes the system easier to understand by defining its functionality and structure in a way that reveals design decisions and allows the observer to ask questions about meeting design requirements, allocating functionality, and implementing components.
An organization's information system architecture is a model of how information technology will support the main goals and development strategy of the automated object. It allows you to think critically and to articulate a vision of how integrated sets of information systems should be structured to achieve these goals. Information system architecture describes how information systems, applications, and people work throughout an organization in a uniform, unified manner.
Thus, the architecture of an information system includes a generally accepted set of components that provide the "building blocks" of an information system. These "building blocks" and their characteristics are defined at the appropriate level of detail to meet the needs of the planning decisions.
When designing modern information systems of organizations, their architecture should be developed taking into account many stakeholders, it should be understandable to users, enable developers to make a plan and schedules of the system, allow to define key interfaces, functions and technologies, and also allow to estimate the schedule and budget of the project. This requires the responsibility of architects of modern information systems to create a satisfactory and workable concept of the system at the earliest stage of its development, to maintain the integrity of this concept throughout development, and to determine the suitability of the resulting system for use by the client. Information system architecture, on the other hand, is the process of describing information system architectures in sufficient detail to make them more useful for information system design.
The study of foreign experience shows that in developed countries, when developing an information system architecture, the following conditions must be met:
¾ focus on the mission of the organization;
¾ focus on requirements;
¾ focus on development;
¾ the ability to adapt;
¾ the need for flexibility.
Compliance with all these conditions allows developing the architecture of the organization's information system more perfect and efficient.
The main software architectures currently being implemented are:
¾ file-server;
¾ client-server;
¾ multi-level.
File Server... This architecture of centralized databases with network access involves the designation of one of the computers on the network as a dedicated server that will store the files of the centralized database. In accordance with user requests, files from the file server are transferred to user workstations, where the bulk of data processing is carried out. The central server mainly performs only the role of file storage, not participating in the processing of the data itself. After completion of work, users copy files with processed data back to the server, from where they can be taken and processed by other users. This organization of data maintenance has a number of disadvantages, for example, when multiple users access the same data at the same time, work performance drops sharply, since it is necessary to wait until the user working with the data finishes his work. Otherwise, changes made by some users may be overwritten by changes made by other users.
Client-server... This concept is based on the idea that in addition to storing the database files, the central server must do most of the data processing. Users access the central server using a special structured query language (SQL, Structured Query Language), which describes a list of tasks performed by the server. User requests are received by the server and generate data processing processes in it. In response, the user receives an already processed dataset. Not the entire set of data is transferred between the client and the server, as it happens in the file-server technology, but only the data that the client needs. A user query that is only a few lines long can generate data processing involving many tables and millions of rows. In response, the client can receive only a few numbers. Client-server technology allows you to avoid the transmission of huge amounts of information over the network by shifting all data processing to a central server. In addition, the considered approach avoids conflicts of changes to the same data by multiple users, which are typical for the file-server technology. Client-server technology implements consistent data modification by multiple clients, ensuring automatic data integrity. These and some other advantages have made client-server technology very popular. The disadvantages of this technology include high performance requirements for the central server. The more clients access the server, and the larger the amount of data processed, the more powerful the central server must be.
Based on these considerations, when designing the AWS architecture, the client-server technology was taken as a basis. Layout diagrams show the physical relationships between software and hardware components in a system.)
2.2 Designing the information system interface
The user interface is often understood only as the appearance of the program. However, in reality, the user perceives through him the entire system as a whole, which means that such an understanding of him is too narrow. In reality, the user interface includes all aspects of design that affect the interaction between the user and the system. It is not only the screen that the user sees. The user interface consists of many components, such as:
a set of user tasks that he solves using the system;
system controls;
navigation between system blocks;
visual design of program screens.
Here are some of the most significant business benefits of a good user interface:
reducing the number of user errors;
reducing the cost of maintaining the system;
reducing the loss of productivity of employees during the implementation of the system and faster recovery of lost productivity;
improving staff morale;
reducing the cost of changing the user interface at the request of users;
availability of system functionality for the maximum number of users.
AWP wholesale base is developed as an application using client-server technology.
2.2.1 User interface of the control program
The main module of the "AWP Wholesale Base" is the Luck.exe module, which provides the implementation of the main functionality of the use case diagram shown in Figure 1.9 of Section 1.4.
When developing an information system, one of the main tasks is to create the most simple and not loaded interface. It is the interface of the software product that helps users "communicate" with the information system, acting as a dialogue between the user and the system.
Program interface, administrative part:
1. starting form of the program. This form is launched when the software product is launched, thus forming the beginning of a user dialogue with the system (Figure 2.3);
2. admin form. In this form, the complete management of the information system is carried out, i.e. adding, deleting, changing data in the database, as well as, if necessary, viewing and printing reports (Figure 2.4);
3. "Customers" form, thanks to this form, you can see complete information about the customers of the enterprise (Figure 2.7);
4. "Suppliers" form, thanks to this form you can see complete information about the customers of the enterprise (Figure 2.8).
The user interface of the program:
In the window for the arrival of goods, the registration of goods is in progress. When choosing this tab of the form, the user must first
In the expense menu, there are operations carried out by the warehouse employee for the release and sale of goods.
In the menu balances, the goods are counted, the names of the items stored in the warehouse.
In the cashier menu, information on credit orders and cash outflow orders is stored here. (Screenshots)
2.2.2 User Interfaces of Control Components
Fig 2.0 Main menu of the program
The main window of the program is shown in Fig. 1.9. As you can see from the figure, in addition to the main menu, already described above, it will also contain a control panel (buttons "Income", "Consumption", "Access", "Balances", "Cashier", "Revaluation", "Analytics", " Directories "," Service "and" Exit the program ").
Figure 2.1 Menu window of receipt or receipt to the warehouse.
Figure 2.2 Consumption menu window
Figure 2.2 Menu window regulating access rights to the program.
Figure 2.3 Menu window of the remainder of the goods.
Figure 2.4 Cash register menu window.
Figure 2.4 Revaluation menu window.
2.3 Database design
ERwin 4.0 from Computer Associates Int was used to design the database.
ERwin is a powerful and easy-to-use database design tool that has gained wide acceptance and popularity. It provides the highest productivity when developing and maintaining database applications. Throughout the entire process - from the logical modeling of information requirements and business rules that define the database, to the optimization of the physical model in accordance with the specified characteristics - ERwin allows you to visually display the structure and basic elements of the database.
ERwin is not only the best database design tool, but also a tool to create one quickly. ERwin will optimize the model according to the physical characteristics of the target database. Unlike other tools, ERwin automatically maintains logical and physical consistency and translates logical constructs, such as many-to-many relationships, into physical implementations. Facilitates database design. To do this, it is enough to create a graphic E-R model(relationship object) that satisfies all data requirements and enter business rules to create a logical model that displays all elements, attributes, relationships, and groupings. Erwin has two levels of model presentation - logical and physical. The logical level is an abstract view of data, on it the data is presented as it looks in the real world, and can be called as it is called in the real world, for example, “ Regular customer"," Department "or" Employee surname ". Model objects that are represented at the logical level are called entities and attributes. The logical level of the data model is universal and has nothing to do with a specific implementation of the DBMS. There are three sublevels of the logical level of the data model, which differ in the depth of presentation of information about the data:
Entity Relationships Diagram (ERD);
Key Based model (KB);
Fully Attributed model (FA).
Entity diagram - Relationship includes entities and relationships that reflect the core business rules of the domain. Such a diagram is not too detailed, it includes the main entities and relationships between them, which satisfy the basic requirements. Entity diagram - A relationship can include many-to-many relationships and not include key descriptions. Typically, ERD is used for presentations and discussion of data structure with subject matter experts. A key-based data model is a more detailed view of data. It includes a description of all entities and primary keys and is intended to represent the data structure and keys that correspond to the subject area.
A logical model is the most detailed representation of a data structure: it represents data in third normal form and includes all entities, attributes and relationships (see Appendix B).
Physical data model on the contrary, it depends on the specific DBMS, in fact, being a display of the system catalog. The physical layer of the model contains information about all objects in the database. Since there are no standards for database objects (for example, there is no standard for data types), the physical layer of the model depends on the specific implementation of the DBMS. Consequently, several different physical levels of different models can correspond to the same logical level of a model. If at the logical level of the model it does not matter much what specific data type the attribute has (although abstract data types are supported), then at the physical level of the model it is important to describe all the information about specific physical objects - tables, columns, indexes, procedures, etc. ... Dividing the data model into logical and physical levels allows you to solve several important problems.
The physical data model is presented in Appendix B.
2.4 Rationale for choosing a platform for creating an information system
Visual FoxPro is a visual relational database management system currently available from Microsoft. The latest version is 9.0. Uses the FoxPro programming language. System version 7.0 can run on Windows 9x operating systems and NT kernels, versions 8.0 and 9.0 - only in Windows XP, 2000, 2003.
FoxPro is one of the dialects of the xBase programming language. It is mainly used for the development of relational DBMS, although it is possible to use it for the development of other classes of programs. As noted above, the VFP language is a strongly augmented and extended xBase language. In Visual FoxPro, a programming language, that is, the basic construction of a language is the concept of a class. The original version of xBase is the purest structured language, with a basic concept of procedures and functions. Thus, the modern programming language Visual FoxPro allows you to combine both the "old-fashioned" programming by describing a mass of procedures, and in the OOP style, creating a complex class hierarchy.
I chose this programming language because it contains a number of the following advantages:
¾ A well-known database table format that makes it easy to organize the exchange of information with other Microsoft Windows applications.
Modern organization of relational databases, which allows you to store information about database tables, their properties, indexes and relationships, set compliance conditions referential integrity, create local and remote views (Views), server connections, stored procedures, executed when more than 50 different types events (VFP 7.0-9.0).
High speed of work with large databases.
High visibility of working with databases: the multifunctional Data session window allows you to see the list of open database tables, their relationships, filters, index order, buffering modes, switch to structure modification modes, to work with table information, etc.
High speed of application development using Wizards, Designers, Builders, IntelliSense hints mode when writing program text, a system for debugging and testing programs.
The ability to develop applications based on the "client-server" technology with data hosted on Oracle and Microsoft database servers SQL Server and with other Microsoft Windows applications using ODBC and OLE
The VFP system is intended for use by professional programmers, so there is no point in Russifying its menu and language - for any programmer, the English syntax of an algorithmic language is more familiar than Russian.
2.5 Designing modules
Let us dwell in more detail on the design of one of the program modules and consider, using its example, the steps necessary to create a project.
As an example, I will consider the design of a module that implements the use case "Issues an application for admission".
First, let's describe the streams of events that occur in this use case.
A precondition for a use case is the receipt of a request from a client.
5. The use case starts when the customer submits the application.
6. The manager opens the Income form.
7. The manager sets the date of the application.
8. The manager puts the name of the product.
9. The manager enters the quantity of the goods received.
10. The manager enters the amount of the application.
11. The manager closes the form.
12. The use case ends.
The postcondition to the use case is the registration of an application in the system and the appearance of a new client in the journal of the main form.
Consider a sequence diagram this option use. As you can see from this diagram, the manager, opening the Arrival form, causes several actions to be performed - automatically (from the manager's point of view) the date of the application is filled in. When placing an application, the list of clients is filled out from the base with primary information. After that, the manager enters all the necessary data and clicks the "Accept" button. In this case, the following actions are performed. All data is passed to the stored procedure.
3 Implementation and validation of the information system
3.1 Application implementation
The implementation of the application, in its essence, is one of the laborious stages for the developer of the information system, because the requirements put forward by the customer must be clearly and correctly integrated into the system. So far, there are no software products that could "adjust" to the requirements of the so-called customer and provide a certain set of functions for the implementation of the system that would meet these requirements. Therefore, each developer must choose the optimal environment for developing the system, but it should be noted that when implementing an application, one cannot do without writing program code. It is when writing the program code that certain functions that the system must perform will be implemented. Depending on the selected environment for the implementation of the system, the program code will look different, in such an environment as Microsoft Visual FoxPro there will be one program code, in Visual basic another, etc.
In this case, the application was implemented in Microsoft Visual FoxPro.
The main functions of the system will be described below:
1. The starting form of the system. This form is a button form and, accordingly, each button performs its own function. The administrator registration button is shown in Figure 3.1. This button will perform the function that opens the administrator panel if the user has such rights to this system.
2. Menu button arrival. This button allows you to keep track of incoming goods to the store's warehouse. Figure 3.2.
3. In the button of the menu, the expense is kept records of the goods released from the warehouse. Figure 3.3.
4. In the button of the access menu, the rights to use this program are regulated. Figure 3.4.
5. In the button of the menu "leftovers" is stored information about the materials stored in the warehouse of the store Fig. 3.5.
6. The cash desk menu button stores information about incoming cash orders and outgoing cash orders. Figure 3.6.
7. In the menu button revaluation, the price changes for new price goods fig. 3.7.
Figure 3.1 - The starting form of the system
Figure 3.2 - Form of accounting for goods receipts to the warehouse.
Figure 3.3– Form of accounting for released goods.
Figure 3.4– Form regulating access rights to the program.
Figure 3.5– Form of the remainder of the goods in the warehouse.
Figure 3.5 – Form about cash receipts and cash receipts.
Figure 3.6 – Form of operations on goods.
Testing the application
Testing is the process of executing a program in order to detect errors. Testing provides:
Error detection;
Demonstration of compliance of the program functions with its purpose;
Demonstration of the implementation of the requirements for the characteristics of the program;
Display of reliability as an indicator of program quality.
Figure 3.2 shows the information flows of the testing process.
There are three streams at the input of the testing process:
Program text;
Initial data for starting the program;
Expected results.
Tests are performed and all results obtained are evaluated. This means that the actual test results are compared with the expected results. When a mismatch is found, an error is recorded and debugging begins.
After collecting and evaluating the test results, the display of the quality and reliability of the software begins. If serious errors that require design changes are regularly encountered, then the quality and reliability of the software are suspicious, and the need to strengthen testing is stated.
The results accumulated during testing can be assessed in a more formal way. For this, software reliability models are used that predict reliability based on real data on the error rate.
There are 2 principles of software testing:
Functional testing (black box testing);
Structural testing (white box testing).
When testing the "white box" method, the internal structure of the program is known. The object of testing here is not the external, but the internal behavior of the program. The correctness of the construction of all elements of the program and the correctness of their interaction with each other are checked.
Black box testing (functional testing) allows you to obtain combinations of input data that provide a complete check of all functional requirements for the program //. A software product is considered here as a "black box" whose behavior can only be determined by examining its inputs and corresponding outputs.
The black box principle is not an alternative to the white box principle. Rather, it is a complementary approach that detects a different class of errors.
Black box testing searches for the following error categories:
Incorrect or missing features;
Interface errors;
Errors in external data structures or in accessing an external database;
Characteristic errors (required memory capacity, etc.);
Initialization and completion errors.
Unlike white box testing, which is performed early in the testing process, black box testing is used in the later stages of testing. When testing the black box, the control structure of the program is neglected. Here the focus is on the information area of the software system definition. Testing during this phase focuses on the suitability of the solution for a live production environment. The focus is on fixing bugs and identifying their severity, and preparing the product for release.
At the testing stage, two main tasks are solved:
Solution Testing - Test plans created during the planning phase and extended and tested during the development phase are executed;
Pilot operation - deployment of the solution in a test environment and testing with the involvement of future users and the implementation of real scenarios of using the system. This task is performed prior to the start of the deployment phase.
The purpose of the testing phase is to reduce the risk that occurs when the solution is put into commercial operation.
For the testing phase to be successful, there needs to be a change in attitude towards the project and the developer switch from developing new features to ensuring the proper quality of the solution.
At this stage of development of the information system, the following types of testing should be carried out:
Basic testing is low-level technical testing. It is carried out by the developer himself in the process of writing the program code. The "white box" method is applied, high risk of errors.
Usability testing - high-level testing performed by the tester and future users of the product. The "black box" method is applied.
Alpha and Beta Testing - In MSF terms, alpha code is basically all the source code created during the development phase of the MSF process model, and beta code is the code that was tested during the testing phase. Therefore, the alpha code is tested during the development phase of the MSF process model, and the beta code is tested during the testing phase.
Compatibility Testing - The solution being developed is required to be able to integrate and interoperate with existing systems and software solutions. This form of testing is focused on testing the integrability and ability of the developed solution to interact with existing systems. In this particular case, the correct operation of the application on the user's equipment and the software used by the user will be checked.
Performance testing - focused on checking whether the application meets the performance requirements and the level of comfort in terms of speed.
Testing documentation and help system- all developed supporting documents and help systems are tested.
Pilot operation is testing a solution in an industrial environment. The main objective of the pilot operation is to demonstrate that the solution is capable of stable operation under industrial conditions and meets the business requirements. During pilot operation, the solution is tested in real conditions. Pilot operation allows users to provide feedback on product performance. Guided by this opinion, the developer eliminates all possible problems or creates an action plan in case of unforeseen circumstances. Ultimately, pilot operation allows a decision to be made whether to initiate a full deployment or postpone until any issues that could derail the deployment are resolved.
The plan of the pilot operation process for the developed information system is shown in Table 3.2.
Table 3.2 - Pilot operation plan
| Action |
Description |
||
| 1. Choice of criteria for success |
The developer and the test takers define the success criteria and agree on them |
||
| 2. Choice of users and installation location |
A team of participants in experimental testing from the side of users and developers is being formed. The location of the pilot process deployment is determined. |
||
| 3. Preparing users and installation sites |
Training of users - participants of the trial is being carried out. The installation site is being prepared. |
||
| 4. Deploying a development version |
An experimental version is installed and included in the work. |
||
| 5. Support and monitoring of the development version |
Monitoring the work of users and the system, providing assistance in operation, collecting information about the operation of the system |
||
| 6. Feedback from users and evaluation of results |
Users express their opinion about the operation of the system, point out shortcomings and errors. |
||
| 7. Introduction of changes and additions |
Errors are corrected, design or process changes are made. Corrected results are provided for users to work and evaluate. |
||
| 8. Deployment decisions |
If the results of the pilot testing work satisfy the users, a decision is made to deploy the system. |
||
3.2 Application deployment methodology
At this stage, the developer (or team) deploys the technologies and components necessary for the solution, the project moves to the stage of maintenance and support, and the customer finally approves it. After deployment, the team evaluates the project and surveys users to determine their satisfaction.
Deployment Phase Objectives:
¾ to transfer the solution to an industrial environment;
¾ acknowledgment by the customer of the fact of completion of the project.
Deployment of site-specific components consists of several stages: preparation, installation, training, and formal approval.
The results of the system deployment stage are maintenance and support systems, a document repository where all versions of documents and code developed during the project are located.
To deploy the system under development, an action plan was drawn up, which is shown in Table 3.1.
Table 3.1 - Application deployment plan
| Action |
Description of action |
| 1. Backup |
The user data is backed up with his participation and approval by transferring information to removable media (CD, DVD) |
| 2. Installation of basic components of the solution |
The use of technologies that ensure the operation of the solution. In this case, installing the Visual FoxPro component |
| 3. Installing the client application |
Transfer to the user's computer and installation of the final version of the developed IS and database |
| 4. Training |
Users are trained to work with the system, the developer is convinced of the correctness and understanding of the work of IP by clients |
| 5. Transfer of the knowledge base of the project to the client |
All project documentation is handed over to the customer |
| 6. Closing the project |
A project closure report is prepared. The customer signs the acceptance certificate. |
For the normal functioning of the AWP it is required operating system Microsoft WindowsXP.
4 Information project management
4.1 Choosing a development life cycle
One of the basic concepts of the IS design methodology is the concept of the life cycle of its software (life cycle software). The life cycle of software is an ongoing process that begins from the moment a decision is made on the need to create it and ends at the time of its complete withdrawal from service.
The main regulatory document governing software lifecycle is the international standard ISO / IEC 12207 (ISO - International Organization of Standardization - International Organization for Standardization, IEC - International Electro technical Commission - International Commission on Electrical Engineering). It defines the structure of the life cycle, containing the processes, actions and tasks that must be performed during the creation of software.
ISO / IEC 12207 does not offer specific model Lifecycle and software development methods. The life cycle model can be understood as a structure that determines the sequence of execution and the relationship of processes, actions and tasks performed during the life cycle. The life cycle model depends on the specifics of the IS and the specifics of the conditions in which it is created and operates.
Today there are many models of the software life cycle, but the most popular and widespread are two models:
Spiral model (see figure 4.1);
Iterative model.
Figure 4.1 - Spiral model of software lifecycle
To create an information system, i.e. "Automated workplace of warehouse employee wholesale warehouse", iterative was chosen. A distinctive feature of the iterative model is that it is a formal method, it consists of independent phases, performed sequentially, and is subject to frequent review (Figure 4.2). The iterative approach has worked well for building ISs, for which, at the very beginning of development, all the requirements can be formulated accurately and fully enough in order to give developers the freedom to implement them as best as possible from a technical point of view.
Advantages of the iterative model:
the model is well known to non-software consumers and end users.
Convenience and ease of use, because all work is performed in stages (according to the phases of the model);
Stability of requirements;
The model is understandable;
Even poorly trained personnel (inexperienced user) can be guided by the structure of the model;
The model handles complexity in an orderly manner and works well for projects that are reasonably understandable;
The model facilitates the implementation of strict control of project management;
Facilitates the job of the project manager to plan and assemble the development team.
Figure 4.2 - Iterative model of software lifecycle
Model phases:
At the analysis stage, they define the functions that the system should perform, highlight the most priority ones that require elaboration in the first place, describe information needs;
At the design stage, the processes of the system are considered in more detail. The functional model is analyzed and, if necessary, corrected. System prototypes are being built;
The system is being developed at the stage of implementation;
At the stage of implementation, the finished product is introduced into the existing system of the organization. User training is in progress;
At the maintenance stage, the software product is serviced (any addition or change for more functional operation of the product).
Choosing a software development lifecycle model is an important step. Therefore, for a project, the choice of a software development life cycle model can be carried out during the use of the following processes.
Analysis of the distinguishing categories of the project, placed in the tables.
Answer the questions for each category, highlighting the words "yes" and "no".
Rank by importance the categories or questions related to each category in relation to the project for which an acceptable model is being selected.
Development team... Based on the capabilities, the selection of personnel for the development team takes place even before the software development life cycle model is chosen. The characteristics of such a team (see Appendix G, Table G.1) play an important role in the process of choosing a life cycle model, which means that the team can provide significant assistance in choosing a software product life cycle model, since it is responsible for the successful implementation of the developed life cycle model. ...
User team... At the initial stages of the project, you can get a complete picture of the team of users (see Appendix AND Table I.1) who will work with the developed software, and its future relationship with the development team throughout the project. Such a view helps in choosing a suitable model, since some models require increased user participation in the development and study of the project, since the requirements can be slightly changed by the user during the development process, the developer needs to know these changes and how to represent these changes in the software.
4.2 Determining the purpose and scope of the software project
The developed software product for accounting of goods in the warehouse will automate the process of receipt, structuring and storage of data about the goods in the warehouse, as well as simplify the process of issuing reports.
The objectives of the software project will be - the creation and deployment of a system for accounting for goods. This system is intended for internal use by Cleonelly staff, mostly employees of the company's warehouse.
To determine the scope of the software product, it will be described below what should or should not be a software project.
The software project must be:
For internal use in an organization;
A project for the implementation of multi-user access;
A project that has the ability to enter, change and store information about the company's product;
A project that has the ability to enter, change and store information about system users;
A project that has the ability to enter, change and store information about customers and suppliers of the organization who are the subjects of transactions to be concluded;
A project that will carry out the formation of external reporting.
4.3 Creating a structure for a step-by-step list of works
To create a unique product or service (project result), you need to carry out a certain sequence of work. The task of project planning is to accurately estimate the timing and cost of these works. The more accurate the assessment is, the higher the quality of the project plan. To give an accurate assessment, you need to have a good understanding of the scope of the project, that is, to know exactly what work needs to be done to get its result. Only after a list of design works has been drawn up, the duration of each of them is estimated, and the resources necessary for their implementation are allocated. And only then it is possible to estimate the cost and timing of each task and, as a result of the addition, the total cost and duration of the project. This is why defining the scope of work is the first step in project planning. Determining the scope of design work begins with defining the stages (or phases) of the project. For example, in the project to create a system "Accounting for goods in stock" the following phases can be highlighted:
Development of software requirements;
Information system design;
Implementation and certification of the information system;
System implementation.
After the composition of the phases and their results are determined, it is necessary to determine the sequence of these phases relative to each other and the deadlines for their implementation. Then you need to determine what works the phases consist of, in what sequence these works are performed and in what deadlines you need to meet when they are completed.
The step-by-step work list (Figure 4.3) was designed using a software product such as MS Project 2003.
Figure 4.3 - Step by step list of works
4.4 Estimating the duration and cost of software development
Estimation of duration. It is determined after the construction of a step-by-step list of works (Figure 4.3, paragraph 4.3). This estimated duration can be seen using the Gantt chart (Appendix K).
Diagrams are a graphical means of displaying information contained in a project file. From charts, you can get a visual idea of the sequence of tasks, their relative duration, and the duration of the project as a whole.
The Gantt chart is one of the most popular ways to graphically represent a project plan and is used in many project management programs.
In MS Project, the Gantt chart is the main visualization tool for the project plan. This chart is a graph with a horizontal timeline and a list of tasks vertically. In this case, the length of the segments denoting tasks is proportional to the duration of the tasks.
On the Gantt chart, next to the bars, additional information can be displayed (next to the tasks, the names of the resources involved in them and their loading when the task is completed are displayed).
Cost estimation
The project consists of tasks , that is, activities aimed at achieving a certain result. In order for the task to be completed, resources .
An important property of resources is the cost (Cost) of their use in the project. There are two types of resource costs in MS Project: time-based rate and cost-per-use.
The time-based rate (Rate) is expressed in the cost of using the resource per unit of time, for example, 100 rubles per hour or 1000 rubles per day. In this case, the cost of participation of the resource in the project will be the time during which it works in the project, multiplied by the hourly rate.
In this case, the time-based rate was used (Figure 4.4). The total cost of using resources can be seen in Figure 4.5.
Figure 4.4 - Time rate in resource use
In this figure, you can see that the system developer receives 50 rubles per hour when executing a project; a business analyst receives 45 rubles an hour, a tester 38 rubles an hour. Overtime rates are not included.
Figure 4.5 - Total costs of using project resources
4.5 Allocating Project Resources
A fragment of the distribution of resources for the "Inventory Accounting" system can be seen in Figure 4.6
Figure 4.6 - Fragment of the distribution of project resources
For each work performed in the project, a resource is associated that will perform this work. The figure shows the total number of labor costs of each of the resources and specific amount hours spent on a specific day.
4.6 Assessment of the economic efficiency of the project
Calculation of the economic efficiency of the project is an important step. This is where the economic efficiency of the project will be calculated. This calculation will show how profitable a project or a completely unprofitable project is. When calculating the economic efficiency of the project, it will be necessary to calculate the payback period of the project. The payback period will show the period for which the project will pay off.
Input data.
Additional profit from the project (DP) = 38,000 rubles. The additional profit was predicted by the company's experts.
Initial investment (IC) = 39396.47 rubles. Initial investments correspond to the total costs of using the project resources (Figure 4.5, clause 4.6)
Discount rate (i) = 12%.
The period for which the project is designed (n) = 2 years.
Additional profit from the project (DP) = 38,000 rubles.
Annual project implementation costs (Z 1) = 15,000 rubles.
Annual project implementation costs (Z 2) = 10,000 rubles.
Annual cash receipts (R 1) = 23,000 rubles.
Annual cash receipts (R 2) = 28,000 rubles.
When evaluating investment projects, the method of calculating net present value is used, which provides for discounting cash flows: all income and costs are brought to one point in time.
The central indicator in the considered method is NPV (net present value) - the present value of cash flows. This is a generalized final result of investment activity in absolute terms.
An important point is the choice of the discount rate, which should reflect the expected average lending rate in the financial market.
Net present value (NPV) is calculated using the formula 4.2
(4.2)
R k - annual cash receipts for n years.
k - the number of years for how long the project is designed.
IC - start-up investment.
i - discount rate.
According to the calculations of this formula NPV = RUB 3,460.67
NPV is an absolute increase because it estimates how much the present value overlaps with the present cost. Since NPV> 0, the project should be accepted.
The return on investment (ROI) is calculated using the formula 4.3
(4.3)
Calculated (ROI) = 108.78%
Table 4.1 Auxiliary table for calculating the payback period of the project
= 1,84
Payback period n ok = 1.84 years (1 year and 11 months)
Since ROI => 100% (namely = 108.78%), the project is considered profitable.
(4.4)
Thus, the profitability index is (PI) = 1.2
Outsourcing of corporate information systems
Outsourcing of production functions and business processes based on corporate information systems allows using the latest achievements and "best practices" of modern management. The implementation of corporate information systems is at the heart of business process reengineering (Business Process...(Outsourcing and outstaffing: high technologies of management)
Integration patterns of corporate information systems
Information systems integration patterns are top level classification of design patterns. Similarly to the patterns of lower levels of classification, a group of structural patterns is distinguished among the patterns of integration. Structural patterns describe the main components of a single integrated ...(Introduction to Software Architecture)
FUNCTIONAL TASKS OF THE INFORMATION SYSTEM OF THE ENTERPRISE AND THE BASIC MODULES OF MODERN INFORMATION SYSTEMS OF THE ENTERPRISE. INTEGRATION OF MODULES
The meaningful meaning of the concept of a module presupposes a comparison of functional subsystems, functional tasks with a functional task-based approach with the main modules of modern Rice. 6.2. Comparison of functional tasks with the main modules of modern ICISP information systems of an enterprise, ...(Enterprise Information System)
CONCEPT, HISTORY OF DEVELOPMENT AND CLASSIFICATION OF INFORMATION SYSTEMS OF THE ENTERPRISE. INTEGRATED CORPORATE INFORMATION SYSTEMS OF THE ENTERPRISE
The concept and classification of information systems change in the course of their historical development. However, the goal remains constant and is associated with the achievement of enterprise management efficiency. The efficiency of enterprise management depends on the interaction of many factors, among them: philosophical, historical, ...(Enterprise Information System)
FEATURES OF MODERN INFORMATION TECHNOLOGIES IN THE INFORMATION SYSTEMS OF THE ENTERPRISE
MODERN TECHNOLOGIES FOR ORGANIZATION OF DATA ENTRY IN CORPORATE INFORMATION SYSTEMS Information about business transactions should be timely entered into the operational database from any sources of its origin. This will make it possible to effectively organize further data processing in information ...(Enterprise Information System)
Based on the purpose of the information system being developed, we will further design the modular structure of the application. To define the modular structure, let's use the UML 2.0 Notation Component Diagram (Figure 3.4).
Rice. 3.4
The information system consists of three components:
- 1. Interface. Implementation of user interaction with the information system. Contains the following modules:
- · Input / output - organization of input and output of information when working with IS;
- · Reporting - organization of reporting in accordance with the established forms of documentation for various areas of the recruiting agency;
- · Search - organizing the search for candidates and vacancies according to the specified parameters;
- 2. Data processing. Implementation of information processing functions: search for data in a database, a mathematical model for the task of primary analysis of documents, etc.;
- 3. DB. An implementation of a data store that contains information about customers.
Database structure design
As mentioned earlier, in the information system, all information is stored in a single database. The IDEF1x methodology was applied to model the logical structure of the database. According to this methodology, the process of building an information model consists of the following steps:
- · Definition of entities; defining dependencies between entities;
- · Assignment of primary and alternative keys;
- · Definition of attributes of entities;
- · Bringing the model to the required level of normal form;
- · transition to physical description models: assignment of correspondences entity name - table name, entity attribute - table attribute;
- · Assignment of triggers, procedures and restrictions;
- · Database generation.
The entity-relationship diagram describing the database in terms of IDEF1.x is built from three main blocks - entities, attributes and relationships. If we consider a diagram as a graphical representation of domain rules, then entities and attributes are nouns, and relationships are verbs.
Since the future IS for this database will search, the following were chosen as the main attributes for the document:
- - document's name;
- - the date of receipt of the document in the archive (law firms that provide archival services monitor the storage period of the documentation. Each document has its own storage period. Many securities lose their relevance over time, and their value is reduced to zero. Such documents should be destroyed. Timely selection of such papers and destruction of documents is included in the package of archival services provided by law firms. When accepting for storage, each document, after a special examination, is determined by the storage period. After this period, the document is submitted for destruction);
- - the identity (type) of the document (since all documents were divided into 7 types, for which the ranking was made in order of importance);
- -column number;
- - shelf number;
- - sled number (these 3 parameters are necessary to determine the location of the document in the archive);
- - the presence of a document in its cell (you need to know whether the document is in the archive, or it was issued to the applicant).
The result of a query to select all documents belonging to one client should look like the following, see Figure 3.5. In the example presented, the number of documents was intentionally limited to 20.
Now let us consider in more detail the logical data model of the information system being developed, shown in Figure 3.6.
Rice. 3.5
Rice. 3.6
From the presented data model, it can be seen that it contains three entities, each with its own set of attributes, and two of them are dependent, and one is not.
The "Employee" entity, which is an independent entity, has the following attributes:
- · Employee identification number - is the primary key of this entity;
- · Full name of the employee;
- · Area of specialization;
- · Rating;
- · Additional Information.
The Customer entity is a dependent entity from the Employee entity, which means that each employee can serve many customers. The client entity has attributes:
- · Passport series and number - is the primary key of this entity;
- · Employee identification number - is the secondary key of this entity;
- · Full name of the employee;
- · Area of specialization;
- · Rating;
- · Additional Information.
The “Document” entity is a dependent entity from the “Client” entity, which means that each client can store many different documents in the archive. The document entity has attributes:
- · Document identifier - is the primary key of this entity;
- · Passport series and number - is the secondary key of this entity;
- · Document's name;
- · Receipt date;
- · Belonging to a group;
- · Column number;
- · Shelf number;
- · Number of the sled;
- · The presence of the document in the cell.
The elements that ensure the operation of IS for any purpose are listed in the definition. Some of them - means, methods and personnel - ensure the operation of the IS, while others - storage, processing and issuance of information - indicate functional characteristics, i.e. determine from which information processes the functioning of the IS is composed. Therefore, the structure of the IS is considered in two different ways: the functional structure and the structure of the IS as a set of supporting subsystems.
In accordance with the definition, the functional elements of the IS are the following groups (blocks) of processes:
input of information from external or internal sources;
processing input information and presenting it in a convenient form;
output of information for presentation to consumers or transfer to another IS;
feedback is information processed by the people of a given organization to correct the input information.
Functional structure information systems are presented in the form of a block diagram (Fig. 1), in which each element of the system is represented in the form of a block (in the Fig. - a rectangle), and the links and their directions are indicated by arrows.
The individual parts (system blocks) are called subsystems.
In each specific case, the set and interconnections of functional subsystems depend on the subject area and the specifics of the activity of the enterprise, the activity of which is provided by the information system.
The structure of the IS can also be represented as a complex of supporting subsystems (Fig. 2).
Fig. 1. Generalized functional block diagram of the IC.
However, for AIS, which differ in the nature and types of information processing, the functional diagram differs in a set of processing subsystems. For example, AIPS (library, museum, reference legal, etc.) produce input, systematization, storage, search and delivery of information at the request of the user without complex data transformations. Information-decisive systems: ASOD, ACS, DSS - process the database information according to a certain algorithm, however, they also differ in the composition of information processing subsystems. A CAD system specialized in design automation has special subsystems in its structure: technical documentation, task formation, simulation, computational, and some may also have an expert system (see the block diagram in Fig. 2).
Fig. 2. CAD block diagram
Consider another type of IS structure: as a complex of supporting subsystems (Fig. 3).
The structure of an information system can be considered as a set of subsystems, regardless of the scope. A subsystem is a part of the system, selected according to some attribute. In this case, they speak of a structural feature of the classification, and the subsystems are called providing.
Thus, the structure of any information system can be represented by a set of supporting subsystems.
Fig. 3. IS structure by the type of supporting subsystems.
Among the supporting subsystems, information, technical, mathematical, software, organizational and legal support are usually distinguished.
Information Support- a set of information data sets, a unified system of classification and coding of information, unified documentation systems, schemes of information flows circulating in an organization, as well as a methodology for building databases. The purpose of the information support subsystem is the timely formation and delivery of reliable information for making management decisions.
Unified documentation systems are created at the state, republican, sectoral and regional levels. The main goal is to ensure the comparability of indicators of various spheres of social production. Standards have been developed where the requirements are established:
to unified documentation systems;
to unified forms of documents of various levels of management;
to the composition and structure of details and indicators;
to the procedure for the implementation, maintenance and registration of unified forms of documents.
Despite the existence of a unified documentation system, a survey of most organizations reveals a whole range of typical shortcomings:
extremely large volume of documents for manual processing;
the same indicators are often duplicated in different documents;
working with a large number of documents distracts specialists from solving immediate problems;
there are indicators that are created but not used, etc.
Elimination of these shortcomings is one of the tasks facing the creation of information support.
Information flow diagrams reflect the routes of information movement, its volumes, the places of origin of the primary information and the use of the resulting information. By analyzing the structure of such schemes, it is possible to develop measures to improve the entire management system.
Construction and detailed analysis of information flow diagrams, allowing to identify routes and volumes of information, duplication of indicators and processes of their processing, provides:
elimination of duplicate and unused information;
classification and rational presentation of information.
Database building methodology based on the theoretical foundations of their design.
Basic concepts of the methodology:
a clear understanding of the goals, objectives, functions of the entire management system of the organization;
identifying the movement of information from the moment of its origin to its use at various levels of management, presented for analysis in the form of information flow diagrams;
improvement of the document management system;
availability and use of a classification and coding system;
possession of the methodology for creating conceptual information-logical models that reflect the interconnection of information;
creation of arrays of information on computer media, which requires modern technical support.
This concept is practically implemented in two stages.
1st stage - examination of all functional divisions of the company in order to:
understand the specifics and structure of its activities;
build a diagram of information flows;
analyze the existing document management system;
define information objects and the corresponding composition of attributes (parameters, characteristics) that describe their properties and purpose.
2nd stage - construction of a conceptual information-logical data model based on the results of the 1st stage survey. In this model, all connections between objects and their attributes must be established and optimized. The information-logical model is the foundation on which the database will be created.
Technical support- a set of technical means intended for the operation of the information system, as well as the corresponding documentation for these means and technological processes
The complex of technical means consists of:
computers of any model;
devices for collecting, accumulating, processing, transmitting and outputting information;
data transmission devices and communication lines;
office equipment and devices for automatic information retrieval;
operating materials, etc.
Documentation formalizes the preliminary selection of technical means, the organization of their operation, the technological process of data processing, technological equipment. Documentation can be roughly divided into three groups:
system-wide, including state and industry standards for technical support;
specialized, containing a set of methods for all stages of development of technical support;
normative reference, used when performing calculations for technical support.
By now, there are two main forms of organization of technical support (forms of using technical means): centralized and partially or completely decentralized.
Centralized technical support is based on the use of large computers and computing centers in the information system. This form of organization facilitates the management and implementation of standardization, but reduces the responsibility and initiative of the staff.
Decentralization of technical means involves the implementation of functional subsystems on personal computers directly at workplaces. In this case, more personal responsibility is required from staff, it is more difficult for management to implement standardization.
Currently, a partially decentralized approach is more common - the organization of technical support based on distributed networks consisting of personal computers and a mainframe for storing databases common to any functional subsystems.
Mathematical and software- a set of mathematical methods, models, algorithms and programs for the implementation of the goals and objectives of the information system, as well as the normal functioning of the complex of technical means.
To funds software relate:
tools for modeling management processes;
typical management tasks;
methods of mathematical programming, mathematical statistics, queuing theory, etc.
Part software includes system-wide and special software products, as well as technical documentation.
TO system-wide software includes complexes of programs aimed at users and designed to solve typical tasks of information processing. They serve to expand the functionality of computers, control and manage the data processing process.
Special software is a set of programs developed when creating a specific information system. It includes applied software packages (APPs) that implement the developed models of varying degrees of adequacy, reflecting the functioning of a real object.
The technical documentation for the development of software must contain a description of the tasks, the task for algorithmization, the economic and mathematical model of the problem, test examples.
Organizational support Is a set of methods and means that regulate the interaction of workers with technical means and with each other in the development and operation of IS.
Organizational support implements the following functions:
analysis of the existing management system of the organization, where the IS will be used, and identification of tasks to be automated;
preparation of tasks for solving on a computer, including terms of reference for the design of IS and a feasibility study of its effectiveness;
development of management decisions on the composition and structure of the organization, methodology for solving problems aimed at improving the efficiency of the management system.
Organizational support is created according to the results of the pre-project survey at the 1st stage of building the database.
Legal support- a set of legal norms that determine the creation, legal status and operation of information systems, regulating the procedure for obtaining, transforming and using information.
The main purpose of legal support is to strengthen the rule of law. The legal framework includes laws, decrees, decisions of state authorities, orders, instructions and other normative documents of ministries, departments, organizations, local authorities. In legal support, one can distinguish a general part that regulates the functioning of any information system, and a local part that regulates the functioning of a specific system.
Legal support for the stages of development of an information system includes regulations related to the contractual relationship between the developer and the customer and the legal regulation of deviations from the contract.
Legal support of the stages of the information system functioning includes:
information system status;
rights, duties and responsibilities of personnel;
the procedure for creating and using information, etc.
This set of subsystems is general for almost all types of AIS. However, the structure and complexity of the supporting subsystems depends on the type of AIS, the field of application and other factors. So, the subsystem of mathematical support takes place in the AIS of the original software development - in the AIS with standard software, it is absent. The subsystem of legal support may be absent in the AIS for intra-firm purposes - in this case, it is possible to restrict ourselves to the subsystem of organizational support, in which, among other things, the issues of legal support are resolved; AIS for independent purposes, for example, information service systems, may have a subsystem of legal support. AIS, which have a factual database, have only a subsystem of information support, in which it may be necessary to solve certain linguistic issues. Documentary AIPS have a developed subsystem of linguistic support, since these systems solve complex problems of ensuring the semantic relevance of user requests to the content of issued documents. And this, as a rule, is not only software modules of morphological analysis, but also a set of dictionaries and rules for their maintenance.
The goals of creation and implementation of IP.
What can be expected from the implementation of information systems?
The introduction of information systems can contribute to:
1. release of workers from routine work and its acceleration due to automation;
2. replacement of paper data carriers with magnetic disks or tapes, which leads to a decrease in the volume of documents on paper, and therefore the possibility of a more rational organization of information processing on a computer;
3. improving the structure of information flows and the document management system in the company due to the effect of consistency: single data entry - multiple and multipurpose use ";
4. obtaining more rational options for solving management problems (through the introduction of mathematical methods and intelligent systems, etc.):
finding new market niches;
optimization of costs for the production of products and / or services;
optimization of relationships with buyers and suppliers.
Stages of development of information systems
The history of the development of IP is divided into stages (Table 2), corresponding approximately to the accepted numbering of goals - the approach to the use of IP is changing.
Table 2. Stages of IP development.
|
Time period |
Information use concept |
Type of information systems |
Purpose of use |
|
1950 - 1960 |
Paper flow of settlement documents |
Information systems for processing settlement documents on electromechanical accounting machines |
Increasing the speed of document processing Simplified invoice processing and payroll processing |
|
1960 - 1970 |
Essential help in preparing reports |
Management information systems for production information |
Speeding up the reporting process |
|
1970 - 1980 |
Management control of implementation (sales) |
Decision support systems Systems for senior management |
Selection of the most rational solution |
|
1980 - 2000 |
Information is a strategic resource that provides a competitive advantage |
Strategic information systems Automated offices |
Survival and prosperity of the firm |
The first information systems appeared in the middle of the last century. In the 1950s, they were designed for processing invoices and calculating salaries, and were implemented on electromechanical accounting machines. This led to some reduction in costs and time for preparing paper documents.
60s are marked by a change in attitudes towards information systems. The information obtained from them began to be used for periodic reporting on many parameters. On that day, organizations needed general-purpose computer equipment capable of serving a variety of functions, and not just processing invoices and calculating salaries, as was the case in the past.
In the 70s - early 80s. information systems are beginning to be widely used as a means of management control that supports and accelerates the decision-making process.
By the end of the 80s. the concept of using information systems is changing again. They become a strategic source of information and are used at all levels of an organization of any profile. Information systems of this period, providing the necessary information on time, help the organization to achieve success in its activities, create new products and services, find new sales markets, provide worthy partners for itself, organize the release of products at a low price, and much more.
The modern understanding of the information system involves the use of a personal computer as the main technical means of processing information. In large organizations, along with personal computer the technical base of the information system may include a mainframe or a supercomputer. In addition, the technical implementation of the information system in itself will mean nothing if the role of the person for whom the information is intended is not taken into account and without whom it is impossible to receive and present it.