Information system design. Mobile phones of directors
Let's start by looking at the overall architecture. To begin with, let's highlight the characteristic features of information systems of this kind that operate on the Internet on websites, because the design task is based on the characteristics of a particular system and the functional requirements. So:
- all information and all calculations are stored and performed on the server
- each client has its own browser
- multi-user access
- access control
- restrictions on the amount of transmitted information
- increased security requirements
- increased performance requirements
- portability
Let's take a look at these features in order. In the foreground are the first two points. They represent the most important difference from information systems operating in closed networks. We are unable to store and process any information on the client side. Everything must be done on the server. When developing an information system with client software, it would be possible to store some of the user information and process it on the client side. Such an opportunity would allow us to offload the server and network traffic. For example, in the case of analyzing website visitors, we would store the bulk of the information with clients, and on the server - only publicly available statistical reports, extracts and comparative indicators with other clients. But we do not have such an opportunity, so we need to spend a lot of money on hard drives and server computing power. Multi-user access and access control are common requirements for all information systems. An important criterion is the limitation on the amount of transmitted information. The server may have a channel with a large bandwidth, but this channel carries information from many clients. In turn, the user has information only for him, but very often users sit on bad channels, for example, on a modem connection, or simply, due to the remoteness and a large number of gateways between the client and the server, the information transfer rate is very slow. Due to the fact that there are a huge number of people on the Internet, among whom there are intruders, it is necessary to impose increased security requirements. You cannot write instructions to the user: do this and not otherwise, but here we have a hole to bypass it, do this. You don't know what to expect from the user. Due to the fact that all the calculations take place on the server, and that the user wants to work in real time and does not intend to wait even 30 seconds, the execution of a single CGI program should be as fast as possible. And finally, portability. Of course, this feature is not so important, but let's say you needed to open a site mirror on another continent. Basically, two problems need to be solved. First, setting up the server platform and your software for the operation of your information system. Secondly, the translation of the system into another language. On another continent, there may simply be neither the platform required by your information system, nor specialists who could install, configure and support all this. For example, there will be a different flavor of Unix. All these characteristic features, basically, determine the design stage.
In the process of designing an information system, three main stages can be distinguished:
- user interface design;
- database design;
- designing a binding system for CGI programs.
At the first design stage, it is necessary to find out the requirements of users to the system and, based on these requirements, make a site layout showing all HTML forms and HTML files of reports of interaction with the information system. It is desirable that HTML forms contain some data by default and link to HTML documents that are expected to be the result of a request to the system. In this case, it will be easier for users to understand what you have designed.
Database design was discussed in detail in the Database Design chapter, so we won't repeat it here. We only note that this stage is hidden from users, and all responsibility for the choice right decision falls on you as a developer.
At the third stage, a set of CGI programs is found out. What each CGI program does and the relationships between them. I would like to immediately note one very common mistake of novice web developers who implement several functions in one program. For example, when developing a guest book, one CGI script is made, which is called in all HTML forms: both when displaying messages and when adding, it is even worse if administrator access functions are included there, i.e. deleting and editing messages. There are three major reasons why you shouldn't do this. First, it's a potential security hole. Secondly, loading and executing such a CGI program will be slower. And thirdly, such a program is difficult to modify, test and debug, because it in itself represents complexity because of the volume of the initial text.
Most right decision is a one-to-one relationship between a functional requirement and a CGI program. One function (operation) - one CGI program. In this case, the source code will be simple and small, and therefore, the probability of missing a security hole in it is greatly reduced. Loading and executing such a program will be much faster. And most importantly, it will be much easier to modify and maintain such a program.
In addition to describing which program performs which function, you need to establish relationships between them. It's such a goofy scheme. In simple systems, it is simple; in large systems, its complexity increases non-linearly. Of course, you can arrange links in place. In simple systems, nothing is drawn at all, because and everything is so obvious. But in large systems, especially if you work in a team of several people, it is useful to have a visual representation of where and what CGI script is called from, and where you will be taken after executing it. Basically, as we have already discussed in the "CGI Programming" chapter, a CGI program can output either text, or redirect to another address on the Internet, or output an image or some other file. This kind of hand-drawn diagram is useful to have in order to clearly understand the architecture of the project.
Based on the requirements for the design of the interface of the information system specified in paragraph 1.2.5.3, development was started. First of all, it was necessary to decide on the type of design for the entire site - let it be adaptive, fluid or regular design with a fixed width. The reason was that now, when layout, it is necessary to take into account screen resolutions, which range from 320 pixels to 2560 on 27-inch monitors, which means that the size of the site should change along with it. The solution was to abandon responsive design (capable of adapting to the screen size of the device on which the system is viewed), despite its modernity, in favor of a fixed width. This was done due to the fact that one of the tasks of adaptive design is to make it easier for the user to read text from a mobile phone, while reducing the size of the image, and since the primary task of the photo archive is to show photos, this approach would not be entirely rational. Therefore, it was decided to leave the usual design with a fixed width.
Based on the given requirements, it is necessary to develop two types of pages:
fullwidth;
with sidebar.
The first step was to determine the width of all blocks for both types of pages. Despite the rapid advancement of technology, there are still monitors with a screen width of 1024x768, smaller ones, such as 800x600, are already out of service. And since this difference is present, let's take the width of all blocks and the gaps between them as 1000 pixels (Fig. 12 a). Accordingly, this is the width for the full-width option, in the case of the side column, we will take 760 pixels for the block with content and 200 for the side column, respectively (Fig. 12 b).
a | b |
Figure 12 - Width of blocks on IS pages
a- for a full-width page, b– for a page with a sidebar
The next stage in the development of the graphic component of the final qualification work was the creation of a background image and the selection colors under this image.
The initial requirement for a background image was “use a photograph/photos from camp shifts in the background. Make them transition from black and white old to color new. To give the impression that they go along with the time scale.”. Based on this requirement, the first version of the background image was compiled (Fig. 13).
Figure 13 - Initial version of the background image
This option turned out to be not very attractive, after which it was changed to the option when neighboring images overlapped each other a little, creating the impression of “time flow” (Fig. 14). Due to the fact that the first option in good quality took up a lot of space -
3 mb (by the standards of the web, this is a lot. No more than 300 kb is needed), and in a bad one it looked terrible, the image was reduced in height and repeated along the Y axis. But this option also turned out to be not as expected.
Figure 14 - Fragment of the second version of the background image
Then the images on the background were mixed with each other (Fig. 15). But this option was not suitable either. It was decided to change the terms of reference and abandon the option with photographs on the background.
Figure 15 - The third version of the background image
It was decided to use hand-drawn images as a background. Such a step would significantly reduce the size of the resulting image in good quality with its unchanged resolution (2560x1500px) from 3-4 mb to 700 kb. The ideal size for a background image should not exceed 300 kb, so the quality of the background image was slightly degraded, which was not very noticeable.
Since the camp is located in a pine forest, I chose the following concept: in the header of the site there is a sky with clouds, in the middle of a neutral color with the ability to increase with an increase in the height of the site, and in the footer there is land with fir trees (Fig. 16).
This option was also dropped. It was necessary to show that the camp is located on the shore of the Gorky Sea, so another change was made to the interface design requirements, namely the presence of the sea in the background. As a result, the version from Figure 17 was left. It turned out to be bright, inviting and not so distracting, for all its brightness. By increasing the height of the site beyond the width of the image, the resulting space should be filled with the color of the sand, so that the image would appear to be continuous.
Figure 16 - The original version of the drawn background image
Figure 17 - The second version of the drawn background image
The next step was to decide on the style of the time scale. There were also several options here, many of which had to be abandoned in favor of a more beautiful image. On fig. 18 shows how the design of the time scale has changed.
a | |
b | |
in |
Figure 18 - Timeline design options
a- initial, b– approved, c – implemented in green(Fig. 21). On top, in the cap, logos of the camp were added.
Figure 21 - Final page design with sidebar
2.2 System architecture development
The architecture of the system in this final qualification work was not developed, since the standard architecture of the Wordpress content management system is used.
A method of navigating the system has been developed, which consists of dividing sections into decades for ease of navigation. Depending on the decade selected on the “Time Scale”, the corresponding years are loaded in the side column. When you click on the year, the sections of shifts and events of the year should go out. Clicking on the shift tab will load the photos corresponding to the selected shift and year. The selected section of events of the year will lead to the loading of information about the events that have occurred for the given year. When you click on a photo in the shifts section, it should enlarge thanks to AJAX windows and be able to switch to the next / previous photo, as well as close the window.
2.3 Programming and basic codes
2.3.1 Designing templates for basic page types
Typically, WordPress templates are created as follows:
Layout of a regular html document and css styles.
The division of a document into its main constituent parts.
Creating separate php documents for Wordpress templates.
Filling these documents with parts of the code from the original file.
Adding custom tags.
Refinement of the code by editing online or through Notepad ++ with subsequent upload via FTP.
Acting on a given course, a page template was originally created in html:
Other page codes are given in Appendix B.
2.3.2 Developing and adding external modules
The following third-party modules were used to implement the system:
1. Plugin NextGEN Gallery.
The most popular photo gallery plugin for WordPress. NextGEN allows you to create beautiful galleries, it has many features: uploading large images, grouping galleries into albums.
Figure 22 - The initial view of the menu in the JavaScript LavaLamp set
2. Plugin Menu Swapper.
With the help of the plugin it is possible to create any number of special locations. For each specific location, you create your own custom menu.
3. JavaScript LavaLamp set.
Used to create a slider for the horizontal Timeline menu. The initial view of the menu can be seen in Figure 23.
Figure 23 - The initial view of the menu in the JavaScript LavaLamp set
4. Set JavaScript jQuery Vertical Accordion Menu.
Used to create a slider for the vertical navigation menu.
Details on how to use these plug-ins are described in paragraph 3.2 - administrator's guide.
Introduction
The design of information systems always begins with the definition of the purpose of the project. The main task of any successful project is to ensure that at the time of system launch and during the entire period of its operation it is possible to provide:
- the required functionality of the system and the degree of adaptation to the changing conditions of its functioning;
- required throughput systems;
- the required response time of the system to a request;
- trouble-free operation of the system in the required mode, in other words, the readiness and availability of the system to process user requests;
- ease of operation and support of the system;
- the necessary security.
Performance is the main factor that determines the efficiency of a system. Good design is the foundation of a high performance system.
Information systems design covers three main areas:
- designing data objects to be implemented in the database;
- designing programs, screen forms, reports that will ensure the execution of data queries;
- taking into account a specific environment or technology, namely: network topology, hardware configuration, architecture used (file-server or client-server), parallel processing, distributed data processing, etc.
In real conditions, design is a search for a way that satisfies the requirements of the functionality of the system by means of available technologies, taking into account given constraints.
Any project is subject to a number of absolute requirements, for example, the maximum project development time, the maximum financial investment in the project, etc. One of the difficulties of design is that it is not as structured as the analysis of project requirements or the implementation of a particular design solution.
It is believed that a complex system cannot be described in principle. This, in particular, concerns enterprise management systems. One of the main arguments is a change in the conditions for the functioning of the system, for example, a directive change in certain flows of information by the new leadership. Another argument is the scope of the terms of reference, which for a large project can be hundreds of pages, while the technical project may contain errors. The question arises: maybe it’s better not to conduct surveys at all and not to make any technical project, but to write the system “from scratch” in the hope that there will be some miraculous coincidence of the customer’s desire with what the programmers wrote, and also that that all this will work stably?
If you look at it, is the development of the system really so unpredictable and is it really impossible to get information about it? It is likely that an idea of the system as a whole and of the ways (management) envisaged for its development can be obtained through seminars. After that, break the complex system into simpler components, simplify the connections between the components, provide for the independence of the components and describe the interfaces between them (so that changing one component does not automatically entail significant change another component), as well as the possibility of expanding the system and "stubs" for functions that are not implemented in one or another version of the system. Based on such elementary considerations, the description of what is supposed to be implemented in the information system no longer seems so unrealistic. You can follow the classical approaches to the development of information systems, one of which - the "waterfall" scheme (Fig. 1) - is described below. Some other approaches to the development of information systems will be briefly considered, where the use of the elements described in the waterfall scheme is also acceptable. Which approach from those described below to follow (and whether it makes sense to come up with your own approach) is to some extent a matter of taste and circumstances.
The software life cycle is a model for its creation and use. The model reflects its various states, starting from the moment the need for this software arises and ending with the moment it is completely out of use for all users. The following life cycle models are known:
- cascade model. The transition to the next stage means the complete completion of the work at the previous stage.
- Staged model with intermediate control. Software development is carried out in iterations with feedback loops between stages. Inter-stage adjustments can reduce the complexity of the development process compared to the waterfall model; the lifetime of each of the stages is stretched for the entire development period.
- spiral model. Particular attention is paid to the initial stages of development - strategy development, analysis and design, where the feasibility of certain technical solutions verified and justified through prototyping (prototyping). Each turn of the spiral involves the creation of a certain version of the product or any of its components, while the characteristics and goals of the project are specified, its quality is determined, and the work of the next turn of the spiral is planned.
Below we will consider some of the project development schemes.
"Waterfall" - project development scheme
Very often, design is described as a separate stage of project development between analysis and development. However, in reality, there is no clear division of the project development stages - design, as a rule, does not have a clearly defined beginning and end, and often continues at the testing and implementation stages. Speaking about the testing stage, it should also be noted that both the analysis stage and the design stage contain elements of the work of testers, for example, to obtain an experimental justification for choosing a particular solution, as well as to evaluate the quality criteria of the resulting system. At the stage of operation, it is appropriate to talk about the maintenance of the system.
Below we will consider each of the stages, dwelling in more detail on the design stage.
Strategy
Defining a strategy involves examining the system. The main task of the survey is to assess the real scope of the project, its goals and objectives, as well as to obtain definitions of entities and functions at a high level.
At this stage, highly qualified business analysts are involved, who have constant access to the management of the company; the stage involves close interaction with the main users of the system and business experts. The main task of interaction is to obtain the most complete information about the system (a complete and unambiguous understanding of customer requirements) and transfer this information in a formalized form to system analysts for the subsequent analysis stage. As a rule, information about the system can be obtained as a result of conversations or seminars with management, experts and users. Thus, the essence of this business, the prospects for its development and the requirements for the system are determined.
Upon completion of the main stage of the system survey, technicians form likely technical approaches and estimate the costs of hardware, purchased software and development of new software (which, in fact, is assumed by the project).
The result of the strategy definition stage is a document that clearly states what the customer will receive if he agrees to finance the project; when he receives the finished product (work schedule); how much it will cost (for large projects, a schedule of financing at different stages of work should be drawn up). The document should reflect not only the costs, but also the benefits, for example, the payback time of the project, the expected economic effect (if it can be estimated).
The document must describe:
- restrictions, risks, critical factors affecting the success of the project, for example, the response time of the system to a request is a given limitation, and not a desirable factor;
- a set of conditions under which it is supposed to operate the future system: system architecture, hardware and software resources provided to the system, external conditions for its functioning, composition of people and work that ensure the smooth functioning of the system;
- deadlines for completion of individual stages, the form of delivery of work, resources involved in the process of developing the project, measures to protect information;
- description of the functions performed by the system;
- future requirements for the system in the event of its development, for example, the ability of the user to work with the system using the Internet, etc.;
- entities necessary to perform system functions;
- interfaces and distribution of functions between a person and a system;
- requirements for software and information components of software, requirements for DBMS (if the project is supposed to be implemented for several DBMS, then the requirements for each of them, or general requirements for an abstract DBMS and a list of DBMS recommended for this project that satisfy the specified conditions);
- that will not be implemented within the framework of the project.
The work performed at this stage allows us to answer the question of whether it is worth continuing this project and what customer requirements can be met under certain conditions. It may turn out that the project does not make sense to continue, for example, because certain requirements cannot be met for some objective reasons. If a decision is made to proceed with the project, then an idea of the project scope and cost estimate is already available for the next stage of the analysis.
It should be noted that at the stage of choosing a strategy, and at the stage of analysis, and during design, regardless of the method used in the development of the project, one should always classify the planned functions of the system in order of importance. One possible format for representing such a classification, MoSCoW, was proposed in Clegg, Dai and Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.
This abbreviation stands for: Must have - necessary functions; Should have - desirable functions; Could have - possible functions; Won't have - missing features.
The implementation of the functions of the second and third categories is limited by the time and financial framework: we develop what is needed, as well as the maximum possible number of functions of the second and third categories in order of priority.
Analysis
The analysis stage involves a detailed study of business processes (functions defined at the strategy selection stage) and the information necessary for their implementation (entities, their attributes and relationships (relationships)). At this stage, an information model is created, and at the next design stage, a data model is created.
All information about the system collected at the strategy definition stage is formalized and refined at the analysis stage. Particular attention should be paid to the completeness of the transmitted information, the analysis of information for the absence of contradictions, as well as the search for information that is not used at all or duplicated. As a rule, the customer does not immediately form the requirements for the system as a whole, but formulates the requirements for its individual components. Pay attention to the consistency of these components.
Analysts collect and record information in two interrelated forms:
- functions - information about events and processes that occur in business;
- entities - information about things that are important to the organization and about which something is known.
The two classic results of analysis are:
- a hierarchy of functions that breaks down the processing into its component parts (what is done and what it consists of);
- entity-relationship model (Entry Relationship model, ER-model), which describes entities, their attributes and relationships (relationships) between them.
These results are necessary but not sufficient. Sufficient results include data flow diagrams and entity life cycle diagrams. Quite often, analysis errors occur when trying to show the life cycle of an entity in an ER diagram.
Below we will review the three most commonly used structural analysis methodologies:
- Entity-Relationship Diagrams (ERD), which serve to formalize information about entities and their relationships;
- data flow diagrams (Data Flow Diagrams, DFD), which serve to formalize the representation of system functions;
- state transition diagrams (State Transition Diagrams, STD), which reflect the behavior of the system, depending on time; Entity life cycle diagrams belong to this class of diagrams.
Normalization
To prevent anomalies in data processing, normalization is used. The principles of normalization for information model objects are exactly the same as for data models.
Allowed link types. On closer examination of the one-to-one relationship (Figure 7), it almost always turns out that A and B are actually different subsets of the same subject or different points of view on it, just having different names and described differently. links and attributes.
Many-to-one relationships are shown in Fig. eight .
I is a strong enough construct that an entry of entity B cannot be created without simultaneously creating at least one associated entry of entity A.
II is the most common form of communication. It assumes that each and every occurrence of entity A can exist only in the context of one (and only one) occurrence of entity B. In turn, occurrences of B can exist both in connection with occurrences of A, and without it.
III - rarely used. Both A and B can exist without a connection between them.
Many-to-many relationships are shown in Fig. nine .
I - such a construction often takes place at the beginning of the analysis stage and means a connection - either not fully understood and requiring additional permission, or reflecting a simple collective relationship - a doubly linked list.
II - rarely used. Such links are always subject to further detailing.
Let us now consider recursive links (Fig. 10).
I - rare, but occurs. Reflects links of an alternative type.
II - quite often used to describe hierarchies with any number of levels.
III - takes place in the early stages. Often reflects the structure of the "list of materials" (mutual nesting of components). Example: each COMPONENT may consist of one or more (other) COMPONENTS and each COMPONENT may be used in one or more (other) COMPONENTS.
Invalid link types. Invalid relationship types include the following: the mandatory many-to-many relationship (Figure 11) and the set of recursive relationships (Figure 12).
A mandatory many-to-many relationship is basically impossible. Such a connection would mean that none of the occurrences of A can exist without B, and vice versa. In fact, each such construction always turns out to be erroneous.
Data flow diagrams
Logical DFD (Fig. 13) shows data sources and sinks (destinations) external to the system, identifies logical functions (processes) and groups of data elements that link one function to another (streams), and also identifies data storages (accumulators), to which access is being made. Data flow structures and their component definitions are stored and parsed in the data dictionary. Each boolean function(process) can be drilled down using a low-level DFD; when further detail is no longer useful, one moves on to expressing the logic of the function using a process specification (mini-specification). The content of each store is also stored in a data dictionary, and the store data model is exposed using ER diagrams.
In particular, the DFD does not show the processes that control the actual data flow and does not distinguish between valid and invalid paths. DFDs contain many useful information, and in addition:
- allow you to present the system in terms of data;
- illustrate external data feed mechanisms that would require special interfaces;
- allow to represent both automated and manual processes of the system;
- perform data-oriented partitioning of the entire system.
Data flows are used to model the transfer of information (or even physical components) from one part of a system to another. The flows in the diagrams are represented by named arrows, the arrows indicate the direction of information flow. Sometimes information can move in one direction, be processed and returned to its source. Such a situation can be modeled either by two different flows, or by one bidirectional one.
A process transforms an input stream into an output stream according to the action specified by the process name. Each process must have a unique number to reference it within the diagram. This number can be used in conjunction with the diagram number to provide a unique process index throughout the model.
Data storage (data storage) allows you to define data in a number of areas that will be stored in memory between processes. In fact, the storage represents "slices" of data flows in time. The information it contains can be used at any time after it is defined, and the data can be chosen in any order. The name of the repository should identify its contents. In the case when the data flow enters (leaves) the storage and its structure corresponds to the storage structure, it must have the same name, which does not need to be reflected in the diagram.
An external entity (terminator) represents an entity outside the context of the system, which is the source or receiver of system data. Her name must contain a noun, such as "Client". It is assumed that the objects represented by such nodes should not participate in any processing.
Some principles for checking the quality and completeness of the information model
(source - Richard Barker, Case Method: Entity Relationship Modeling, Addison-Wesley, 1990)
If you want to create a high-quality model, you will have to resort to the help of analysts who are well versed in CASE technology. However, this does not mean that only analysts should be involved in the construction and control of the information model. The help of colleagues can also be very helpful. Involve them in checking the goal and in a detailed study of the built model, both in terms of logic and in terms of taking into account aspects of the subject area. Most people find it easier to find flaws in someone else's work.
Regularly present your information model or its individual fragments about which you have doubts for the approval of users. Pay special attention to exceptions to the rules and restrictions.
Entity quality
The main guarantee of the quality of an entity is the answer to the question whether the object is really an entity, that is, an important object or phenomenon, information about which should be stored in the database.
List of verification questions for the entity:
- Does the name of an entity reflect the essence of this object?
- Is there an intersection with other entities?
- Are there at least two attributes?
- Are there no more than eight attributes in total?
- Are there any synonyms/homonyms for this entity?
- Is the entity fully defined?
- Is there a unique identifier?
- Is there at least one connection?
- Is there at least one function for creating, searching, updating, deleting, archiving, and using an entity value?
- Is there a history of changes?
- Is there compliance with the principles of data normalization?
- Does the same entity exist in another application system, perhaps under a different name?
- Is the essence too general?
- Is the level of generalization embodied in it sufficient?
List of screening questions for the subtype:
- Are there any overlaps with other subtypes?
- Does the subtype have any attributes and/or relationships?
- Do they all have their own unique identifiers, or do they all inherit one from the supertype?
- Is there an exhaustive set of subtypes?
- Isn't a subtype an example of an entity occurrence?
- Do you know of any attributes, relationships, and conditions that distinguish this subtype from others?
Attribute Quality
It is necessary to find out whether these are really attributes, that is, whether they describe this entity in one way or another.
List of security questions for an attribute:
- Is the name of an attribute a singular noun that reflects the essence of the property denoted by the attribute?
- Doesn't the attribute name include the entity name (it shouldn't)?
- Does the attribute only have one value at a time?
- Are there duplicate values (or groups) missing?
- Are the format, length, valid values, derivation algorithm, etc. described?
- Could this attribute be an omitted entity that would be useful for another application system (existing or proposed)?
- Is there a description for each party involved, does it accurately reflect the content of the relationship, and does it fit within the accepted syntax?
- Are there only two parties involved?
- Is the degree of connection and obligation specified for each party?
- Is the connection structure allowed?
- Isn't it redundant?
- Doesn't it change over time?
- If the connection is mandatory, does it always reflect the relationship to the entity representing the opposite side?
- Do all link ends covered by an exclusive arc have the same binding type?
- Do all of them refer to the same entity? rice. 15) such a decomposition. Consider the simplest problem of issuing an invoice to a customer when goods are released from a warehouse, provided that the set of goods that the customer wants to purchase is already known (we will not consider in this example product selection problem).
We need to find out if the relationships reflect the really important relationships observed between the entities.
List of verification questions for communication:
Is the connection not portable?
Is the connection design one of the rarely used ones?
For exclusive association:
Obviously, the operation of selecting and calculating discounts can also be broken down into smaller operations, such as calculating discounts for loyalty (the customer buys goods for a long time) and calculating discounts for the quantity of goods purchased. Atomic functions are described in detail, for example using DFD and STD. Obviously, such a description of functions does not exclude additional verbal description (for example, comments).
It should be noted that at the analysis stage, attention should be paid to the functions of analyzing and processing possible errors and deviations from the expected standard of the system. The most critical processes for the operation of the system should be identified and a particularly rigorous error analysis should be provided for them. DBMS error handling (return codes), as a rule, is a separate set of functions or a single function.
Strategy Refinement
At the analysis stage, the hardware and software selected for the final implementation are refined. For this, testing groups and technical specialists can be involved. When designing an information system, it is important to take into account the further development of the system, for example, an increase in the volume of processed data, an increase in the intensity of the flow of requests, changes in the requirements for the reliability of the information system.
At the analysis stage, sets of task models are determined to obtain comparative characteristics of various DBMS that were considered at the stage of determining the strategy for implementing the information system. At the stage of determining the strategy, one DBMS can be selected. There is already much more data about the system at the analysis stage, and they are more detailed. The data obtained, as well as the characteristics transmitted by the testing groups, may show that the choice of the DBMS at the stage of determining the strategy was incorrect and that the selected DBMS cannot satisfy certain requirements of the information system. The same data can be obtained regarding the choice of hardware platform and operating system. Obtaining such results initiates a change in the data obtained at the stage of determining the strategy, for example, the cost estimate for the project is recalculated.
The choice of development tools is also specified at the analysis stage. Because the analysis phase provides a more complete picture of the information system than it did in the strategy definition phase, the work plan can be adjusted. If the development tool selected at the previous stage does not allow one or another part of the work to be completed within the specified time, then a decision is made to change the deadlines (as a rule, this is an increase in the development time) or to change the development tool. When choosing one or another tool, one should take into account the presence of highly qualified personnel who own the selected development tools, as well as the presence of administrators of the selected DBMS. These recommendations will also refine the data of the strategy selection stage (the set of conditions under which the future system is supposed to be operated).
Limitations, risks, critical factors are also specified. If any requirements cannot be satisfied in the information system implemented using the DBMS and software tools selected at the stage of determining the strategy, then this also initiates the refinement and change of the data obtained (ultimately, cost estimates and work plans, and possibly change in customer requirements for the system, for example, their weakening). The features that will not be implemented in the system are described in more detail.
ComputerPress 9 "2001
At present, the information industry has become a new technology industry, brings users great benefits. Therefore, in modern conditions the head of the organization must have knowledge of the methodological foundations of creating IS. Knowledge of the methodological foundations for the creation and use of IS is closely related to the development and improvement of management processes.
The founder of cybernetics (system sciences and control methods) is Norbert Wiener (USA). The works of his followers became the foundation of the theory of automatic control. This is the science of the general laws of receiving, storing, transmitting and transforming information in complex control systems. The use of computer technology for solving control problems led to the development of information theory, coding theory, and an independent scientific direction of computer science was formed. The results of these studies formed the basis for the development of a methodology for the use of hardware and software to solve problems of various practical directions.
Economic objects began to be considered as complex systems, and their management was identified with the information process. The intensive development of the capabilities of computer technology and the scope of its application has led to the creation of human-machine IS in economic objects. The purpose of the IS was not only the information support of production and business processes, the solution of functional management tasks within the organization, but also the information interaction between various related organizations in the production, economic and informational aspects.
Academician V.M. Glushkov, who formulated scientific and methodological provisions and practical recommendations for the creation of an automated information system. The main principles of unified methodological approaches are:
1. The principle of consistency, which is the most important in the creation, operation and development of IS. He considers the studied economic object as a whole. At the same time, it establishes the directions of the production and economic activities of the organization and the specific functions implemented by it; discovers Various types links between its structural elements ensuring the integrity of the system. The principle of consistency involves the conduct of two aspect analysis in the organization, namely macro- and micro-analysis. In macroanalysis, the system and (or) its "elements are considered as part of a system of a higher order. Particular attention is paid to information connections: their directions of movement are established, those connections that are determined by the purpose of the operation and study of the object are identified and analyzed, and then the most preferable, taken into account in the process of designing IS In macroanalysis, all aspects of the organization's activities are studied, its structural components (including activities at each workplace) are analyzed with a view to their functional characteristics, manifested through relationships with other elements and the external environment.
When designing an IS for the organizational structure of managing an economic object, a multi-level hierarchical structure is most characteristic. The hierarchical structure for each level of the system allows various combinations of local optimality criteria with the global criterion of optimality for the functioning of the system as a whole; provides relative flexibility of the control system and the ability to adapt to changing conditions; increases reliability due to the possibility of introducing elemental redundancy, streamlining the directions of information flows. The advantages of hierarchical structures contributed to their widespread use in management systems and determined the organizational and functional approach to the creation of IS. The experience gained at the same time influenced the modern process approach in the design of IS.
The practical significance of applying the system principle lies in the fact that it allows, in an accessible form for analysis, not only to identify the interests of the creators of the system, but also to use computer simulation to study the behavior of the system being designed under specific conditions specified by the experimenter. Therefore, the creation of an IS is based on the modeling method, which makes it possible to find the most acceptable and reasonable design solutions, options for building a system, and thereby ensure the most efficient operation of an economic object.
2. The principle of development, which lies in the fact that IS is created taking into account the possibility of constant replenishment and updating of the system's functions and types of its support. Its essence is that the developing production and management processes are becoming more complex and restructuring the organizational structures of economic objects - this causes the need to increase the computing power of the IS, equipping them with new hardware and software to constantly replenish and update the tasks being solved, expanding the information fund, created in the form databases and data warehouses, knowledge bases.
3. The principle of information, which is aimed at a detailed and comprehensive study of information and information processes that accompany management processes in an economic object. Information is studied in semantic (meaningful), syntactic (sign) and pragmatic (useful) aspects. In addition, the study of information is necessary for the design of automated workstations, systems for transmitting, storing and processing data, protecting information, where the main ones are knowledge of the volume, content and usefulness of information.
At present, an object-oriented method for modeling information processes and automating design work is based on the information approach for the analysis of management processes and the design of information electronic flows.
4. The principle of compatibility, which is to ensure the interaction of IS various kinds, appointments, levels in the process of functioning of the economic object. Therefore, in the design process, the system unity of methodological approaches in solving the problems of information, technical, software compatibility of all IS used should be ensured. The unity of methodological approaches is reflected in the legal documents governing the process of development, documentation, acceptance and operation of IS. These are international and domestic standards (GOST), industry and departmental regulatory materials, regulations, protocols, standards of organizations.
Standards are widely used that regulate language information processing tools, communication technologies and organization of computing, between object interaction, and the like.
5. The principle of standardization and unification, which consists in the need to use standard, unified and standardized elements of the functioning of the IS. This primarily applies to the components of information, technical, software and other IT support subsystems. This principle allows to reduce the time, labor and cost costs for the creation of IS with the maximum possible use of the accumulated experience in the formation of design solutions and the introduction of automation of design work, provides a multi-aspect interaction of IS.
6. The principle of decomposition, which is based on the division of the system into parts and the allocation of individual work packages, creates conditions for a more effective analysis of the current state of management activity, the study of the features of solving functional problems for further modeling specific aspects of management activity and transferring them to automated technology. The principle is used both in studying the features of the properties of elements and the system as a whole, and in creating an IS on a new information technology base.
7. The principle of efficiency, which is to achieve a rational balance between the costs of creating an IS and the target effect obtained during its operation.
The description of the life cycle of an information system involves the use of such concepts:
Process - a chain of works that are sequentially performed;
Stages are successive periods of time during which work is performed. During the stage, work related to different processes can be performed. The concept of its life cycle (LC) is at the heart of the creation and use of an automated information system for managing an economic object. The life cycle of a model for the creation and use of an automated information management system for an economic object, reflecting its various states, starting from the moment of occurrence and the need for it and ending with the moment of complete exit from the use of all users without exception.
Traditionally, the following main stages of the AIS life cycle are distinguished:
Requirements analysis;
Design;
Programming / Implementation;
Testing and debugging;
Operation and maintenance.
Let us consider in more detail the main stages of the AIS life cycle:
1. Requirements analysis is the first phase of AIS development, where customer requirements are specified, formalized and documented. In fact, at this stage, an answer is given to the question: "What should the future system do?", And this is the success of the entire project. In the practice of creating large systems, there are many examples of unsuccessful project implementation precisely because of the incompleteness and fuzziness of defining system requirements.
The list of requirements for AIS should include:
1) a set of conditions under which it is supposed to operate the future system (hardware and software resources provided to the system; external conditions for its functioning, composition of employees and work related to it)
2) a description of the functions to be performed by the system;
3) restrictions in the development process (directive deadlines for the completion of individual stages, available resources, organizational procedures and measures to ensure the protection of information).
The purpose of the analysis is to transform general, fuzzy knowledge about the requirements for the future system into accurate (if possible) definitions.
The result of the stage should be a system requirements model (that is, a system project), which means:
1) system architecture, its functions, external conditions, division of functions between hardware and software parts;
2) interfaces and separation of functions between a person and a system;
3) requirements for software and information components of the software part: necessary hardware resources, database requirements, physical characteristics software component, their interfaces.
The requirements model should include;
1) a complete functional model of the requirements for the future system with the depth of processing to the level of each operation of each official;
2) specifications of lower-level operations;
3) a package of reports and documents on a functional model, including a description of the modeling object, a list of subsystems, requirements for methods and means of communication for information exchange between components, requirements for the characteristics of the system's interconnections with adjacent systems, requirements for system functions;
4) conceptual information model of requirements;
5) a package of reports and documents on the information model;
6) system architecture with reference to the conceptual information model;
7) proposals for organizing a structure to support the system.
Thus, the requirements model contains functional, informational and, possibly, event (if the target system is a real-time system) models. This provides a number of advantages over the traditional model, namely:
1) Traditional development is characterized by the implementation of the initial stages in artisanal non-formalized ways. Therefore, customers and users can see the system for the first time after it has already been largely implemented. Naturally, this system will be different from what they expected. Therefore, to continue to take place a few more iterations of its development or modification, requires additional (and significant) costs of money and time. The key to solving this problem is the requirements model, which allows
Describe, "see" and correct the future system before it is implemented physically;
Reduce the cost of developing and implementing the system;
Evaluate the development in terms of time and results;
Reach mutual understanding between all participants of the work (customers, users, developers, programmers)
To improve the quality of the database being developed, namely: to perform its functional decomposition and design the optimal structure of the integrated database.
2) The requirements model is completely independent and separated from specific developers, does not require maintenance by its creators and can be painlessly transferred to others. Moreover, if for some reason the enterprise is not ready to implement the system based on the requirements model, it can be left "on the shelf" until the need arises.
3) The requirements model can be used for independent development or correction of software tools already implemented on its basis by the programmers of the enterprise automation department.
4) The requirements model can be used for automated and fast training of new employees in a specific area of the enterprise, since its technology is contained in the model.
The requirements analysis stage is the most important among all stages of the life cycle. It significantly affects all subsequent stages, while remaining the least studied and understood process. At this stage, firstly, you need to understand what exactly needs to be done, and secondly, document it, because if the requirements are not fixed and made available to the project participants, then they do not seem to exist. At the same time, the language in which the requirements are formulated should be quite simple and understandable to the customer.
2. Development terms of reference is performed after building the model, contains requirements for the future system. On its basis, the terms of reference are developed to create a system that includes:
Requirements for automated workplaces, their composition and structure, as well as methods and schemes of information interaction between them;
Development of requirements for technical means;
Definition of software requirements;
Development of the topology, composition and structure of the local area network;
Requirements for the stages and terms of work.
3. Design. This stage gives an answer to the question: "How (in what way) will the system meet the requirements for it? The task of this stage
There are studies of the structure of the system 1 of the logical relationships of elements, and issues related to the implementation on a specific platform are not addressed here. Design is seen as an iterative process of obtaining a logical model of the system, along with rigorous goals set for it, as well as writing the specifications of the physical system, satisfies these requirements. This stage is usually divided into two sub-stages:
System architecture design, including the development of the structure and interfaces of components, coordination of functions and technical requirements to components, methods and design standards;
Detailed design, which includes the development of specifications for each component, the interfaces between components, the development of test requirements, and the development of a component integration plan.
In other words, the design is a stage of the life cycle, which determines how to implement the requirements for the LES generated and fixed at the stage of analysis. As a result, an implementation model should be built that demonstrates how the system will satisfy the requirements presented to it (without technical details). In fact, the implementation model is the development and refinement of the requirements model, namely, the design is the bridge between analysis and implementation.
4. Implementation (programming / adaptation). At this stage, the LES is created as a complex of software and hardware (starting with the design and creation of a telecommunications infrastructure and ending with the development and installation of applications).
5. Testing and debugging. The correctness of AIS is its most important property and the main concern of developers. In the ideal case, the correctness of 1C means the absence of errors in it. However, this is not possible for most complex software products (every program contains at least one bug). Therefore, "correct" is usually understood as a software product that works in accordance with the requirements imposed on it, that is, a product for which such conditions have not yet been found in which it will be inoperable.
Establishing correctness is main goal life cycle stages are considered. It should be noted that the stage of testing and debugging is one of the most time-consuming, tedious and unpredictable stages of IS development. On average, for development by traditional methods, this stage takes from 1/2 to 1/3 of the entire development time. On the other hand, testing and debugging is a serious problem: in some cases, testing and debugging a program requires several times more time than programming itself.
Testing is a set of procedures and actions designed to demonstrate the correct operation of the IS in given modes and external conditions. The purpose of testing is to reveal the presence of errors or convincingly demonstrate their absence, which is possible only in some trivial cases. It is important to distinguish between testing and the accompanying concept of "debugging". Debugging is a set of procedures and actions that begin with identifying the very fact that an error exists and end with establishing the exact location, nature of this error, and how to fix it.
The most important and most frequently used in practice is the method of deterministic testing. In this case, specific initial data are used as test standards, consisting of interrelated input and resulting values and the correct sequences of their processing. In the process of testing with given initial values, it is necessary to establish the correspondence of the results of their processing to the reference values.
Complex systems require a large number of tests, and the problem arises of estimating their required number and using methods to reduce them. Therefore, testing (like any other type of activity) is advisable to plan. The test plan should contain:
1) formulation of testing objectives;
2) testing quality criteria to evaluate its results;
3) a testing strategy that ensures the achievement of the specified quality criteria;
4) the need for resources to achieve a given quality criterion for the chosen strategy.
There are systems for automation of testing and debugging (Satna). They are a complex set of algorithmic and software tools designed to automate the analysis of AIS, testing, debugging and assessing its quality, and make it possible to facilitate the modification of AIS components, ensure the detection of errors in the early stages of debugging, increase the percentage of errors that are automatically found.
6. Operation and maintenance. The main tasks of this stage are:
Ensuring the stability of the system and the preservation of information - administration;
Timely modernization and repair of individual elements - technical support;
Adaptation of the capabilities of the system, operated with the current needs of the business of the enterprise - the development of the system.
These works must be included in the operational plan for informatization of the enterprise, which must be formed in compliance with all the conditions of the strategic plan. Otherwise, fragments may appear within the existing system, which in the future will make the effective operation of the system impossible. Now it has become common practice abroad to transfer technical support and partly administration functions to system suppliers or system integrators. This practice is called "outsourcing". Often, functions such as the creation and maintenance of backup data warehouses and execution centers for critical business applications that are activated in the event of a natural disaster or other special conditions are also transferred to third-party enterprises within the scope of outsourcing.
Particular attention at the stage of operation and maintenance should be paid to the issues of staff training and, accordingly, planning investments in this process.
The life cycle is formed in accordance with the principle of top-down design and usually has an iterative character: the implemented stages, starting from the very first, are cyclically repeated in accordance with changes in requirements and external conditions, the introduction of restrictions, etc. At each stage of the life cycle, a certain set of documents and technical solutions is generated, at the same time, for each stage, the documents and decisions obtained at the previous stage are the initial ones. Each stage ends with the verification of the generated documents and solutions in order to verify their compliance with the output.
Existing life cycle models determine the order in which stages are performed during development, as well as the criteria for moving from stage to stage. In accordance with this, the following three models of ZhShch4] are most widely used:
1. The cascade model (70s - 80s) provides for the transition to the next stage after the completion of work at the previous stage and is characterized by a clear separation of data and processing processes (Fig. 2.6).
Rice. 2.6. Cascade model of IP life cycle
2. Staged model with intermediate control (80s - 85s) - an iterative development model with feedback loops between stages. The advantage of this model is that between-stage adjustments provide less labor intensity compared to the waterfall model; on the other hand, the lifetime of each of the stages is extended over the entire development period.
3. Spiral model (86 - 90s) - focuses on the initial stages of the life cycle: requirements analysis, specification design, previous and detailed design. At these stages, the feasibility of technical solutions is checked and justified by creating prototypes. Each turn of the spiral corresponds to a step-by-step model for creating a fragment or version of the system, on which the goals and characteristics of the project are specified, its quality is determined, and the work of the next turn of the spiral is planned. Thus, the details of the project are deepened and consistently concretized, and as a result, a reasonable option is selected, which is brought to implementation (Fig. 2.7.).
Rice. 2.7. Spiral model of IP life cycle
Experts note the following advantages of the spiral model:
Accumulation and reuse of software tools, models and prototypes;
Orientation to the development and modification of the system in the course of its design;
Risk and cost analysis in the design process.
When using the spiral model, there is an accumulation and reuse of design solutions, design tools, models and prototypes of the information system and information technology; orientation is carried out on the development and modification of the system and technology in the process of their design; risk and cost analysis is carried out in the process of designing systems and technologies.
Features of information technology design. Modern information technology is implemented in the conditions of the designed information system.
Aspects of design: technical (hardware and communication complex), software and mathematical (models and programs), methodical (a set of means for implementing management functions), organizational (a description of the workflow and regulations for the actions of the control apparatus), operational (a set of technological, logical, arithmetic actions, implemented automatically).
Introduction
The design of information systems always begins with the definition of the purpose of the project. The main task of any successful project is to ensure that at the time of system launch and during the entire period of its operation it is possible to provide:
- the required functionality of the system and the degree of adaptation to the changing conditions of its functioning;
- required system throughput;
- the required response time of the system to a request;
- trouble-free operation of the system in the required mode, in other words, the readiness and availability of the system to process user requests;
- ease of operation and support of the system;
- the necessary security.
Performance is the main factor that determines the efficiency of a system. Good design is the foundation of a high performance system.
Information systems design covers three main areas:
- designing data objects to be implemented in the database;
- designing programs, screen forms, reports that will ensure the execution of data queries;
- taking into account a specific environment or technology, namely: network topology, hardware configuration, architecture used (file-server or client-server), parallel processing, distributed data processing, etc.
In real conditions, design is a search for a way that satisfies the requirements of the functionality of the system by means of available technologies, taking into account the given restrictions.
Any project is subject to a number of absolute requirements, for example, the maximum project development time, the maximum financial investment in the project, etc. One of the difficulties of design is that it is not as structured as the analysis of project requirements or the implementation of a particular design solution.
It is believed that a complex system cannot be described in principle. This, in particular, concerns enterprise management systems. One of the main arguments is a change in the conditions for the functioning of the system, for example, a directive change in certain flows of information by the new leadership. Another argument is the scope of the terms of reference, which for a large project can be hundreds of pages, while the technical project may contain errors. The question arises: maybe it’s better not to conduct surveys at all and not to make any technical project, but to write the system “from scratch” in the hope that there will be some miraculous coincidence of the customer’s desire with what the programmers wrote, and also that that all this will work stably?
If you look at it, is the development of the system really so unpredictable and is it really impossible to get information about it? It is likely that an idea of the system as a whole and of the ways (management) envisaged for its development can be obtained through seminars. After that, break the complex system into simpler components, simplify the connections between the components, provide for the independence of the components and describe the interfaces between them (so that a change in one component does not automatically entail a significant change in another component), as well as the possibility of expanding the system and "stubs" for unrealizable in one or another version of the system of functions. Based on such elementary considerations, the description of what is supposed to be implemented in the information system no longer seems so unrealistic. You can follow the classical approaches to the development of information systems, one of which - the "waterfall" scheme (Fig. 1) - is described below. Some other approaches to the development of information systems will be briefly considered, where the use of the elements described in the waterfall scheme is also acceptable. Which approach from those described below to follow (and whether it makes sense to come up with your own approach) is to some extent a matter of taste and circumstances.
Rice. 1. Waterfall scheme
The software life cycle is a model for its creation and use. The model reflects its various states, starting from the moment the need for this software arises and ending with the moment it is completely out of use for all users. The following life cycle models are known:
- cascade model. The transition to the next stage means the complete completion of the work at the previous stage.
- Staged model with intermediate control. Software development is carried out in iterations with feedback loops between stages. Inter-stage adjustments can reduce the complexity of the development process compared to the waterfall model; the lifetime of each of the stages is stretched for the entire development period.
- spiral model. Particular attention is paid to the initial stages of development - strategy development, analysis and design, where the feasibility of certain technical solutions is tested and justified through prototyping (prototyping). Each turn of the spiral involves the creation of a certain version of the product or any of its components, while the characteristics and goals of the project are specified, its quality is determined, and the work of the next turn of the spiral is planned.
Below we will consider some of the project development schemes.
"Waterfall" - project development scheme
Very often, design is described as a separate stage of project development between analysis and development. However, in reality, there is no clear division of the project development stages - design, as a rule, does not have a clearly defined beginning and end, and often continues at the testing and implementation stages. Speaking about the testing stage, it should also be noted that both the analysis stage and the design stage contain elements of the work of testers, for example, to obtain an experimental justification for choosing a particular solution, as well as to evaluate the quality criteria of the resulting system. At the stage of operation, it is appropriate to talk about the maintenance of the system.
Below we will consider each of the stages, dwelling in more detail on the design stage.
Strategy
Defining a strategy involves examining the system. The main task of the survey is to assess the real scope of the project, its goals and objectives, as well as to obtain definitions of entities and functions at a high level.
At this stage, highly qualified business analysts are involved, who have constant access to the management of the company; the stage involves close interaction with the main users of the system and business experts. The main task of interaction is to obtain the most complete information about the system (a complete and unambiguous understanding of customer requirements) and transfer this information in a formalized form to system analysts for the subsequent analysis stage. As a rule, information about the system can be obtained as a result of conversations or seminars with management, experts and users. Thus, the essence of this business, the prospects for its development and the requirements for the system are determined.
Upon completion of the main stage of the system survey, technicians form likely technical approaches and estimate the costs of hardware, purchased software and development of new software (which, in fact, is assumed by the project).
The result of the strategy definition stage is a document that clearly states what the customer will receive if he agrees to finance the project; when he receives the finished product (work schedule); how much it will cost (for large projects, a schedule of financing at different stages of work should be drawn up). The document should reflect not only the costs, but also the benefits, for example, the payback time of the project, the expected economic effect (if it can be estimated).
The document must describe:
- restrictions, risks, critical factors affecting the success of the project, for example, the response time of the system to a request is a given limitation, and not a desirable factor;
- a set of conditions under which it is supposed to operate the future system: system architecture, hardware and software resources provided to the system, external conditions for its functioning, composition of people and work that ensure the smooth functioning of the system;
- deadlines for completion of individual stages, the form of delivery of work, resources involved in the process of developing the project, measures to protect information;
- description of the functions performed by the system;
- future requirements for the system in the event of its development, for example, the ability of the user to work with the system using the Internet, etc.;
- entities necessary to perform system functions;
- interfaces and distribution of functions between a person and a system;
- requirements for software and information components of software, requirements for DBMS (if the project is supposed to be implemented for several DBMS, then the requirements for each of them, or general requirements for an abstract DBMS and a list of DBMS recommended for this project that satisfy the specified conditions);
- that will not be implemented within the framework of the project.
The work performed at this stage allows us to answer the question of whether it is worth continuing this project and what customer requirements can be met under certain conditions. It may turn out that the project does not make sense to continue, for example, because certain requirements cannot be met for some objective reasons. If a decision is made to proceed with the project, then an idea of the project scope and cost estimate is already available for the next stage of the analysis.
It should be noted that at the stage of choosing a strategy, and at the stage of analysis, and during design, regardless of the method used in the development of the project, one should always classify the planned functions of the system in order of importance. One possible format for representing such a classification, MoSCoW, was proposed in Clegg, Dai and Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.
This abbreviation stands for: Must have - necessary functions; Should have - desirable functions; Could have - possible functions; Won't have - missing features.
The implementation of the functions of the second and third categories is limited by the time and financial framework: we develop what is needed, as well as the maximum possible number of functions of the second and third categories in order of priority.
Analysis
The analysis stage involves a detailed study of business processes (functions defined at the strategy selection stage) and the information necessary for their implementation (entities, their attributes and relationships (relationships)). At this stage, an information model is created, and at the next design stage, a data model is created.
All information about the system collected at the strategy definition stage is formalized and refined at the analysis stage. Particular attention should be paid to the completeness of the transmitted information, the analysis of information for the absence of contradictions, as well as the search for information that is not used at all or duplicated. As a rule, the customer does not immediately form the requirements for the system as a whole, but formulates the requirements for its individual components. Pay attention to the consistency of these components.
Analysts collect and record information in two interrelated forms:
- functions - information about events and processes that occur in business;
- entities - information about things that are important to the organization and about which something is known.
The two classic results of analysis are:
- a hierarchy of functions that breaks down the processing into its component parts (what is done and what it consists of);
- entity-relationship model (Entry Relationship model, ER-model), which describes entities, their attributes and relationships (relationships) between them.
These results are necessary but not sufficient. Sufficient results include data flow diagrams and entity life cycle diagrams. Quite often, analysis errors occur when trying to show the life cycle of an entity in an ER diagram.
Below we will review the three most commonly used structural analysis methodologies:
- Entity-Relationship Diagrams (ERD), which serve to formalize information about entities and their relationships;
- data flow diagrams (Data Flow Diagrams, DFD), which serve to formalize the representation of system functions;
- state transition diagrams (State Transition Diagrams, STD), which reflect the behavior of the system, depending on time; Entity life cycle diagrams belong to this class of diagrams.
ER diagrams
ER diagrams (Figure 2) are used to design data and are a standard way of defining data and relationships between them. Thus, the detailing of data warehouses is carried out. The ER diagram contains information about the entities of the system and how they interact, includes the identification of objects that are important for the subject area (entities), the properties of these objects (attributes) and their relationships with other objects (links). In many cases, the information model is very complex and contains many objects.
Rice. 2. An example of an ER diagram
An entity is displayed as a rectangle with the name of the entity at the top (for example, TITLES). The box can list the attributes of an entity; attributes of ER-diagrams, typed in bold1, are key (so Title Identity is a key attribute of the TITLES entity, other attributes are not key).
A relationship is represented by a line between two entities (blue lines in the figure).
The single line on the right (Figure 3) means "one", the "bird's foot" on the left means "many", and the relationship is read along the line, such as "one to many". A vertical bar means “required”, a circle means “optional”, for example, for each publication in TITLE, a publisher must be indicated in PUBLISHERS, and one publisher in PUBLISHERS can issue several titles in TITLES. It should be noted that links are always commented (an inscription on the line depicting the link).
Rice. 3. ER diagram element
Let us also give an example (Fig. 4) of the image of the reflexive relationship "employee", where one employee can manage several subordinates and so on down the hierarchy of positions.
Note that such a relationship is always optional, otherwise it would be an infinite hierarchy.
Rice. 4. ER diagram of a reflexive relation
Entity attributes can be key - they are in bold; mandatory - they are preceded by the "*" sign, that is, their value is always known, optional (optional) - they are preceded by O, that is, the values \u200b\u200bof this attribute at some point may be absent or undefined.
arcs
If an entity has a set of mutually exclusive relationships with other entities, then such relationships are said to be in an arc. For example, a bank account can be issued either for legal entity, or for individual. A fragment of the ER diagram for this type of relationship is shown in fig. 5.
Rice. 5. Arc
In this case, the attribute OWNER of the ACCOUNT entity has a special meaning for this entity - the entity is divided into types by categories: "for an individual" and "for a legal entity". The resulting entities are called subtypes, and the original entity becomes a supertype. To understand whether a supertype is needed or not, it is necessary to establish how many of the same properties have different subtypes. It should be noted that the abuse of subtypes and supertypes is a fairly common mistake. They are depicted as shown in Fig. 6.
Rice. 6. Subtypes (right) and supertype (left)
Normalization
To prevent anomalies in data processing, normalization is used. The principles of normalization for information model objects are exactly the same as for data models.
Allowed link types. On closer examination of the one-to-one relationship (Figure 7), it almost always turns out that A and B are actually different subsets of the same subject or different points of view on it, just having different names and described differently. links and attributes.
Rice. 7. One-to-one relationships
Many-to-one relationships are shown in Fig. eight.
Rice. 8. Many-to-One Relationships
I is a strong enough construct that an entry of entity B cannot be created without simultaneously creating at least one associated entry of entity A.
II is the most common form of communication. It assumes that each and every occurrence of entity A can exist only in the context of one (and only one) occurrence of entity B. In turn, occurrences of B can exist both in connection with occurrences of A, and without it.
III - rarely used. Both A and B can exist without a connection between them.
Many-to-many relationships are shown in Fig. nine.
Rice. 9. Many-to-Many Relationships
I - such a construction often takes place at the beginning of the analysis stage and means a connection - either not fully understood and requiring additional permission, or reflecting a simple collective relationship - a doubly linked list.
II - rarely used. Such links are always subject to further detailing.
Let us now consider recursive links (Fig. 10).
Rice. 10. Recursive links
I - rare, but occurs. Reflects links of an alternative type.
II - quite often used to describe hierarchies with any number of levels.
III - takes place in the early stages. Often reflects the structure of the "list of materials" (mutual nesting of components). Example: each COMPONENT may consist of one or more (other) COMPONENTS and each COMPONENT may be used in one or more (other) COMPONENTS.
Invalid link types. Invalid relationship types include the following: the mandatory many-to-many relationship (Figure 11) and the set of recursive relationships (Figure 12).
Rice. 11. Invalid many-to-many relationships
A mandatory many-to-many relationship is basically impossible. Such a connection would mean that none of the occurrences of A can exist without B, and vice versa. In fact, each such construction always turns out to be erroneous.
Rice. 12. Invalid recursive links
Data flow diagrams
Logical DFD (Fig. 13) shows data sources and sinks (destinations) external to the system, identifies logical functions (processes) and groups of data elements that link one function to another (streams), and also identifies data storages (accumulators), to which access is being made. Data flow structures and their component definitions are stored and parsed in the data dictionary. Each logical function (process) can be detailed using the lower level DFD; when further detail is no longer useful, one moves on to expressing the logic of the function using a process specification (mini-specification). The content of each store is also stored in a data dictionary, and the store data model is exposed using ER diagrams.
Rice. 13. DFD Example
In particular, the DFD does not show the processes that control the actual data flow and does not distinguish between valid and invalid paths. DFDs contain a lot of useful information, and in addition:
- allow you to present the system in terms of data;
- illustrate external data feed mechanisms that would require special interfaces;
- allow to represent both automated and manual processes of the system;
- perform data-oriented partitioning of the entire system.
Data flows are used to model the transfer of information (or even physical components) from one part of a system to another. The flows in the diagrams are represented by named arrows, the arrows indicate the direction of information flow. Sometimes information can move in one direction, be processed and returned to its source. Such a situation can be modeled either by two different flows, or by one bidirectional one.
A process transforms an input stream into an output stream according to the action specified by the process name. Each process must have a unique number to reference it within the diagram. This number can be used in conjunction with the diagram number to provide a unique process index throughout the model.
Data storage (data storage) allows you to define data in a number of areas that will be stored in memory between processes. In fact, the storage represents "slices" of data flows in time. The information it contains can be used at any time after it is defined, and the data can be chosen in any order. The name of the repository should identify its contents. In the case when the data flow enters (leaves) the storage and its structure corresponds to the storage structure, it must have the same name, which does not need to be reflected in the diagram.
An external entity (terminator) represents an entity outside the context of the system, which is the source or receiver of system data. Her name must contain a noun, such as "Client". It is assumed that the objects represented by such nodes should not participate in any processing.
STD State Transition Diagrams
The life cycle of an entity belongs to the class of STD diagrams (Fig. 14). This diagram reflects the change in the state of an object over time. For example, consider the state of a product in a warehouse: a product can be ordered from a supplier, delivered to a warehouse, stored in a warehouse, undergo quality control, sold, rejected, returned to a supplier. The arrows in the diagram show the allowed state changes.
Rice. 14. Life cycle diagram example
There are several different options for displaying such diagrams, the figure shows only one of them.
Some principles for checking the quality and completeness of the information model
(source - Richard Barker, Case Method: Entity Relationship Modeling, Addison-Wesley, 1990)
If you want to create a high-quality model, you will have to resort to the help of analysts who are well versed in CASE technology. However, this does not mean that only analysts should be involved in the construction and control of the information model. The help of colleagues can also be very helpful. Involve them in checking the goal and in a detailed study of the built model, both in terms of logic and in terms of taking into account aspects of the subject area. Most people find it easier to find flaws in someone else's work.
Regularly present your information model or its individual fragments about which you have doubts for the approval of users. Pay special attention to exceptions to the rules and restrictions.
Entity quality
The main guarantee of the quality of an entity is the answer to the question whether the object is really an entity, that is, an important object or phenomenon, information about which should be stored in the database.
List of verification questions for the entity:
- Does the name of an entity reflect the essence of this object?
- Is there an intersection with other entities?
- Are there at least two attributes?
- Are there no more than eight attributes in total?
- Are there any synonyms/homonyms for this entity?
- Is the entity fully defined?
- Is there a unique identifier?
- Is there at least one connection?
- Is there at least one function for creating, searching, updating, deleting, archiving, and using an entity value?
- Is there a history of changes?
- Is there compliance with the principles of data normalization?
- Does the same entity exist in another application system, perhaps under a different name?
- Is the essence too general?
- Is the level of generalization embodied in it sufficient?
List of screening questions for the subtype:
- Are there any overlaps with other subtypes?
- Does the subtype have any attributes and/or relationships?
- Do they all have their own unique identifiers, or do they all inherit one from the supertype?
- Is there an exhaustive set of subtypes?
- Isn't a subtype an example of an entity occurrence?
- Do you know of any attributes, relationships, and conditions that distinguish this subtype from others?
Attribute Quality
It is necessary to find out whether these are really attributes, that is, whether they describe this entity in one way or another.
List of security questions for an attribute:
- Is the name of an attribute a singular noun that reflects the essence of the property denoted by the attribute?
- Doesn't the attribute name include the entity name (it shouldn't)?
- Does the attribute only have one value at a time?
- Are there duplicate values (or groups) missing?
- Are the format, length, valid values, derivation algorithm, etc. described?
- Could this attribute be an omitted entity that would be useful for another application system (existing or proposed)?
- Could it be a missed connection?
- Is there somewhere a reference to the attribute as a "project feature" that should disappear when moving to the application layer?
- Is there a need for a history of changes?
- Does its value depend only on the given entity?
- If the value of an attribute is required, is it always known?
- Is there a need to create a domain for this and similar attributes?
- Does its value depend only on some part of the unique identifier?
- Does its value depend on the values of some attributes not included in the unique identifier?
Connection quality
We need to find out if the relationships reflect the really important relationships observed between the entities.
List of verification questions for communication:
- Is there a description for each party involved, does it accurately reflect the content of the relationship, and does it fit into the accepted syntax?
- Are there only two parties involved?
Is the connection not portable?
- Is the degree of connection and obligation specified for each party?
- Is the connection structure allowed?
Is the connection design one of the rarely used ones?
- Isn't it redundant?
- Doesn't it change over time?
- If the connection is mandatory, does it always reflect the relationship to the entity representing the opposite side?
For exclusive association:
- Do all link ends covered by an exclusive arc have the same binding type?
- Do all of them refer to the same entity?
- Usually arcs cross branching ends - what can you say about this case?
- A connection can only be covered by one arc. Is it so?
- Are all bond ends covered by an arc included in the unique identifier?
System functions
Analysts often have to describe fairly complex business processes. In this case, one resorts to functional decomposition, which shows the division of one process into a number of smaller functions until each of them can no longer be broken down without loss of meaning. The final product of decomposition is a hierarchy of functions, at the lowest level of which there are functions that are atomic in terms of semantic load. Let us give a simple example (Fig. 15) of such a decomposition. Consider the simplest problem of issuing an invoice to a customer when goods are released from a warehouse, provided that the set of goods that the customer wants to purchase is already known (we will not consider the problem of choosing goods in this example).
Rice. 15. Decomposition Example
Obviously, the operation of selecting and calculating discounts can also be broken down into smaller operations, such as calculating discounts for loyalty (the customer buys goods for a long time) and calculating discounts for the quantity of goods purchased. Atomic functions are described in detail, for example using DFD and STD. Obviously, such a description of functions does not exclude additional verbal description (for example, comments).
It should be noted that at the analysis stage, attention should be paid to the functions of analysis and processing of possible errors and deviations from the expected standard of the system. The most critical processes for the operation of the system should be identified and a particularly rigorous error analysis should be provided for them. DBMS error handling (return codes), as a rule, is a separate set of functions or a single function.
Strategy Refinement
At the analysis stage, the hardware and software selected for the final implementation are refined. For this, testing groups and technical specialists can be involved. When designing an information system, it is important to take into account the further development of the system, for example, an increase in the volume of processed data, an increase in the intensity of the flow of requests, changes in the requirements for the reliability of the information system.
At the analysis stage, sets of task models are determined to obtain comparative characteristics of various DBMS that were considered at the stage of determining the strategy for implementing the information system. At the stage of determining the strategy, one DBMS can be selected. There is already much more data about the system at the analysis stage, and they are more detailed. The data obtained, as well as the characteristics transmitted by the testing groups, may show that the choice of the DBMS at the stage of determining the strategy was incorrect and that the selected DBMS cannot satisfy certain requirements of the information system. The same data can be obtained regarding the choice of hardware platform and operating system. Obtaining such results initiates a change in the data obtained at the stage of determining the strategy, for example, the cost estimate for the project is recalculated.
The choice of development tools is also specified at the analysis stage. Since the analysis phase provides a more complete picture of the information system than it did in the strategy definition phase, the work plan can be adjusted. If the development tool selected at the previous stage does not allow one or another part of the work to be completed within the specified time, then a decision is made to change the deadlines (as a rule, this is an increase in the development time) or to change the development tool. When choosing one or another tool, one should take into account the presence of highly qualified personnel who own the selected development tools, as well as the presence of administrators of the selected DBMS. These recommendations will also refine the data of the strategy selection stage (the set of conditions under which the future system is supposed to be operated).
Limitations, risks, critical factors are also specified. If any requirements cannot be satisfied in the information system implemented using the DBMS and software tools selected at the stage of determining the strategy, then this also initiates the refinement and change of the data obtained (ultimately, cost estimates and work plans, and possibly change in customer requirements for the system, for example, their weakening). The features that will not be implemented in the system are described in more detail.