So, the essence of the structural approach to EIS software development lies in its decomposition (breakdown) into automated functions: the system is divided into functional subsystems, which, in turn, are divided into subfunctions, those into tasks, and so on down to specific procedures. At the same time, the system maintains a holistic view in which all components are interconnected. When developing a system "bottom-up", from individual tasks to the entire system, integrity is lost, and problems arise when describing the information interaction of individual components.

All the most common methods of the structural approach are based on a number of general principles:

1. The principle of “divide and conquer”;

2. The principle of hierarchical ordering is the principle of organizing the components of a system into hierarchical tree structures with the addition of new details at each level.

Isolating two basic principles does not mean that the remaining principles are secondary, because ignoring any of them can lead to unpredictable consequences (including the failure of the entire project"). The main ones of these principles are:

1. The principle of abstraction - highlighting the essential aspects of the system and abstracting from the unimportant.

2. The principle of consistency, validity and consistency of system elements.

3. Structuring principle data - data must be structured and hierarchically organized.

In the structural approach, there are mainly two groups of tools that describe the functional structure of the system and the relationships between data. Each group of funds corresponds certain types models (diagrams), the most common among them are:

· DFD (Data Flow Diagrams) - data flow diagrams;

· SADT (Structured Analysis and Design Technique - methodology of structural analysis and design) - models and corresponding functional diagrams: notations IDEF0 (functional modeling of systems), IDEF1х (conceptual modeling of databases), IDEF3х (construction of systems for assessing the quality of an object's work; graphical description of the flow processes, interaction of processes and objects that are changed by these processes);

· ERD (Entity - Relationship Diagrams) - entity-relationship diagrams.

Almost all methods of the structural approach (structural analysis) at the stage of forming software requirements use two groups of modeling tools:

1. Diagrams illustrating the functions that the system must perform and the relationships between these functions - DFD or SADT (IDEF0).

2. Diagrams that model data and their relationships (ERD).

The specific form of the listed diagrams and the interpretation of their designs depend on the stage of the software life cycle.

At the stage of forming software requirements, SADT models and DFD are used to build the “AS-IS” model and the “TO-BE” model, thus reflecting the existing and proposed structure of the organization’s business processes and the interaction between them (the use of SADT models as are usually limited to this stage only, since they were not originally intended for software design). With the help of ERD, a description of the data used in the organization is carried out at the conceptual level, regardless of the database implementation tools (DBMS).

Now in software engineering there are two main approaches to the development of IS software, the fundamental difference between which is due to different ways system decomposition: a functional-modular (structural) approach, which is based on the principle of functional decomposition, in which the structure of the system is described in terms of the hierarchy of its functions and the transfer of information between individual functional elements, and object oriented approach, which uses object decomposition, describes the structure of the IS in terms of objects and connections between them, and the behavior of the system in terms of the exchange of messages between objects.

So, the essence of the structural approach to IS software development lies in its decomposition into automated functions: the system is divided into functional subsystems, which in turn are divided into subfunctions, which are divided into tasks and so on down to specific procedures. At the same time, the IS maintains the integrity of the presentation, where all components are interconnected. When developing a system "from the bottom up", from individual tasks to the entire system, integrity is lost, and problems arise when describing the information interaction of individual components.

The basic principles of the structural approach are:

o principle " divide and rule";

o principle hierarchical ordering - the principle of organizing component systems into hierarchical tree structures with the addition of new details at each level. Highlighting two basic principles does not mean that the remaining principles are secondary, since ignoring any of them can lead to unpredictable consequences.

The main ones of these principles are:

o abstraction - highlighting the essential aspects of the system;

o consistency - validity and consistency of system elements;

o data structuring - data must be structured and hierarchically organized.

Methodological foundations of creation technologies software

Visual modeling. In general, a software model is a formalized description of a software system at a certain level of abstraction. Each model defines a specific aspect of the system, uses a set of diagrams and documents in a given format, and reflects the thoughts and activities of various people with specific interests, roles, or tasks.

Graphical (visual) models are tools for visualizing, describing, designing and documenting system architecture. The composition of the models used in each specific project and the degree of their detail generally depend on the following factors:

o difficulties of the designed system;

o the necessary completeness of its description;

o knowledge and skills of project participants;

o time allocated for design.

Visual modeling greatly influenced the development of CASE tools in particular. The concept of CASE (Computer Aided Software Engineering) is used in a broad sense. The original meaning of this concept, limited only to the tasks of automation of software development, has now acquired new meaning, covering most software life cycle processes.

CASE technology is a set of software design methods, as well as a set of tools that allow you to visually model a subject area, analyze this model at all stages of software development and maintenance, and develop an application in accordance with the information needs of users. Most existing CASE tools are based on structural or object-oriented analysis and design methods, using specifications in the form of diagrams or texts to describe external requirements, relationships between system models, system behavior dynamics, and software architecture.

In the first part, we chose to compare software development methodologies such indicators as the methodology’s relationship to iterative development and the degree of formality in the design of working materials and in the development process in general. In this part, we use these indicators to compare the most well-known software development methods.

We'll see how it goes…

Alas, this is the most difficult category to describe - after all, it includes both the product of the frantic throwing of a beginner trying to complete his first project at any cost, as well as quite mature and established methodologies that have absorbed many years of diverse experience of specific development teams and are even described in internal regulations Since people who are able to develop their own methodology, as a rule, can themselves evaluate it in terms of iterativeness and formalization, we will focus on beginners. Unfortunately, most often this means that development rules either do not exist at all, or they have been developed and adopted, but are not followed. It is natural in such conditions to be extremely low level development formalism. So everything is clear with this.

Development “How it turns out”

What about the iterative approach? Alas, as a rule, it is not used in such projects. First of all, because it would have made it possible to assess the project even in the first iterations as extremely dubious and requiring urgent intervention from higher management to restore order. Indeed, in an iterative project, the programmer’s traditional answer that he has everything 90% ready lasts only until the completion of the first iteration...

Structural methodologies

Structural methodologies

Structural methods are a group of methodologies developed, as a rule, even before the widespread use of object-oriented languages. All of them involve waterfall development. Although, as it turned out, even in that article, which is often cited as the first presentation of the waterfall approach, it was said that it is advisable to start the project with the development of a prototype, that is, carry out at least two iterations.

Nevertheless, the basis of these methodologies is a consistent transition from work to work and the transfer of the results (documents) of the next stage to the participants of the next one.

Also, all of these methodologies require a highly formalized approach, although statements about a reasonable amount of documentation can be found in them. One of the non-obvious examples that software development methodologies developed not only in the West is a quote from a book published in our country in the early 1980s, which states that the degree of formalization of a programming task should be determined based on how well the analyst and programmer. And this despite the fact that the subject of the book involved the development of rather critical, as they are now called, systems, errors in which lead to serious losses or even disasters.

Agile methodologies

Agile methodologies are based on ten principles, of which we will name only those that determine the assessment of these methodologies according to selected parameters:

• the main thing is to satisfy the customer and provide him with the product as soon as possible;
• new product releases should appear every few weeks, or at most months;
• most effective method transfer of knowledge to development participants and between them - personal communication;
• a working program is the best indicator of development progress.

Thus, these methods are clearly focused on iterative software development and minimal formalization of the process. However, regarding the second point, it is necessary to make a reservation: the named methods are focused on the minimum level of formalization acceptable for a given project. At least one of the methodologies included in the group of flexible ones - Crystal - has modifications designed to carry out processes with different numbers of participants and different criticality of the software being developed (software criticality is determined by the possible consequences of errors, which can vary from minor financial losses to error correction before catastrophic ones). So that further comparison with flexible methodologies is not pointless, we present brief descriptions several of them.

eXtreme Programming, or XP (extreme programming)

The XP methodology, developed by Kent Beck, Ward Cunningham, and Ron Jeffries, is the best known of the agile methodologies today. Sometimes the very concept of “agile methodologies” is explicitly or implicitly identified with XP, which preaches communication, simplicity, feedback and courage. It is described as a set of practices: the planning game, short releases, metaphors, simple design, refactoring, test-forward development, pair programming, shared code ownership, 40-hour work weeks, always-on customer presence, and code standards. Interest in XP grew from the bottom up - from developers and testers, tortured by the painful process, documentation, metrics and other formalism. They did not reject discipline, but they were unwilling to pointlessly adhere to formal requirements and were looking for new, fast and flexible approaches to developing high-quality programs.

When using XP, careful preliminary software design is replaced, on the one hand, by the constant presence of a customer in the team, ready to answer any question and evaluate any prototype, and on the other, by regular code revisions (so-called refactoring). Carefully commented code is considered the basis of project documentation. A lot of attention in the methodology is paid to testing. As a rule, for each new method, a test is first written, and then the actual method code is developed until the test begins to run successfully. These tests are stored in test suites that are automatically executed after any code change.

While pair programming and the 40-hour work week are perhaps the most well-known features of XP, they are supportive in nature and contribute to high developer productivity and reduced development errors.

Crystal Clear

Crystal is a family of methodologies that determine the required degree of formalization of the development process depending on the number of participants and the criticality of the tasks.

The Crystal Clear methodology is inferior to XP in terms of performance, but is extremely easy to use. It requires minimal effort to implement because it is focused on human habits. It is believed that this methodology describes the natural order of software development that is established in sufficiently qualified teams, if they are not engaged in the targeted implementation of another methodology.

Key Features of Crystal Clear:

• iterative incremental development;
• automatic regression testing;
• users are invited to actively participate in the project;
• the composition of the documentation is determined by the project participants;
• Typically, code version control tools are used.

In addition to Crystal Clear, the Crystal family includes several other methodologies designed to handle larger or more critical projects. They have slightly more stringent requirements for the scope of documentation and supporting procedures such as change and version control.

Feature Driven Development

Feature Driven Development (FDD) operates with the concept of a function or feature of a system, which is quite close to the concept of a use case used in RUP. Perhaps the most significant difference is an additional restriction: “each function must allow implementation in no more than two weeks.” That is, if the use case is small enough, it can be considered a function, and if it is large, then it must be divided into several relatively independent functions.

FDD includes five processes, with the last two repeated for each function:

• development of a general model;
• compiling a list of necessary system functions;
• planning work on each function;
• function design;
• function construction.

Work on a project involves frequent builds and is divided into iterations, each of which is implemented using a specific set of functions.

Developers in FDD are divided into “class masters” and “chief programmers”. The main programmers involve the owners of the involved classes in working on the next property. By comparison, in XP there are no individuals responsible for classes or methods.

Common features

The list of flexible methodologies is currently quite wide. Nevertheless, the methodologies we have described provide a very complete picture of the entire family.

Almost all flexible methodologies use an iterative approach, in which only a limited amount of work associated with the release of the next release is planned in detail.

Almost all flexible methodologies are focused on the most informal approach to development. If the problem can be solved during a normal conversation, then it is better to do just that. Moreover, to formalize decision in the form of paper or electronic document it is necessary only when it is impossible to do without it.

Agile methodologies

GOST standards

GOSTs, like the CMM model requirements described in the next section, are not methodologies. As a rule, they do not describe the software development processes themselves, but only formulate certain requirements for the processes, which are met to varying degrees by various methodologies. Comparing requirements using the same criteria by which we compare methodologies will help you immediately decide which methodologies should be used if you need to carry out development in accordance with GOST.

Currently in Russia, the old GOSTs of the 19th and 34th series and the newer GOST R ISO IEC 122207 are in force. GOSTs of the 19th and 34th series are strictly focused on the cascade approach to software development. Development in accordance with these GOSTs is carried out in stages, each of which involves the implementation of strictly defined work, and ends with the release of a fairly large number of very formalized and extensive documents. Thus, immediately strict adherence to these standards not only leads to a waterfall approach, but also ensures a very high degree of formalization of development.

GOST requirements

GOST 12207, in contrast to the standards of the 19th and 34th series, describes software development as a set of main and auxiliary processes that can operate from the beginning to the completion of the project. The life cycle model can be selected based on the characteristics of the project. Thus, this GOST does not explicitly prohibit the use of an iterative approach, but also does not explicitly recommend its use. GOST 12207 is also more flexible in terms of requirements for the formality of the development process. It contains only instructions on the need to document the main results of all processes, but there are no lists of required documents and instructions regarding their content.

Thus, GOST 12207 allows for iterative and less formalized software development.

Development process maturity models (CMM, CMMI)

In addition to state and international standards, there are several approaches to certification of the development process. The most famous of them in Russia are, apparently, CMM and CMMI.

CMM (Capability Maturity Model) is a maturity model of software creation processes, which is designed to assess the level of maturity of the development process in a particular company. According to this model, there are five levels of development process maturity. The first level corresponds to development “as it happens,” when developers approach each project as if it were a feat. The second corresponds to more or less established processes, when you can count with reasonable confidence on a positive outcome of the project. The third corresponds to the presence of developed and well-described processes used in development, and the fourth corresponds to the active use of metrics in the management process to set goals and monitor their achievement. Finally, the fifth level refers to the company's ability to optimize the process as needed.

CMM and CMMI requirements

After the advent of CMM, specialized maturity models began to be developed to create information systems, for the supplier selection process and some others. Based on them, an integrated CMMI (Capability Maturity Model Integration) model was developed. In addition, CMMI made an attempt to overcome the shortcomings of CMM that had emerged by that time - the exaggeration of the role of formal descriptions of processes, when the presence of certain documentation was rated much higher than just a well-established but not described process. However, CMMI is also focused on using a very formalized process.

Thus, the basis of the CMM and CMMI models is the formalization of the development process. They aim developers to implement a process described in detail in regulations and instructions, which, in turn, cannot but require the development of a large volume of project documentation for appropriate control and reporting.

The connection between CMM and CMMI and iterative development is more indirect. Formally, neither one nor the other puts forward specific requirements for adhering to a waterfall or iterative approach. However, according to some experts, CMM is more compatible with the waterfall approach, while CMMI also allows for the use of an iterative approach.

RUP

Of course, RUP is an iterative methodology. Although the mandatory requirement to complete all phases or a certain minimum number of iterations is not formally indicated anywhere in RUP, the entire approach is focused on the fact that there are quite a lot of them. Limited quantity iterations does not allow you to fully take advantage of all the benefits of RUP. At the same time, RUP can also be used in practically waterfall projects, which actually include only a couple of iterations: one in the “Build” phase, and the other in the “Transfer” phase. By the way, in waterfall projects this number of iterations is actually used. After all, testing and trial operation of the system involves making corrections, which may involve certain actions related to analysis, design and development, that is, in fact, they are another pass through all phases of development.

RUP methodology

As for the formality of the methodology, RUP presents the user with a very wide range of possibilities. If you do all the work and tasks, create all the artifacts, and conduct all the reviews quite formally (with an official reviewer, preparing a full review in the form of an electronic or paper document, etc.), RUP can turn out to be an extremely formal, ponderous methodology. At the same time, RUP allows you to develop only those artifacts and perform only those jobs and tasks that are necessary in a specific project. And selected artifacts can be executed and reviewed with arbitrary degrees of formality. You can demand detailed elaboration and careful execution of each document, the provision of an equally carefully completed and executed review, and even, following old practice, approval of each such review by the scientific and technical council of the enterprise. Or can we limit ourselves by email or a sketch on paper. In addition, there is always one more possibility: to form a document in your head, that is, to think about the relevant issue and make a constructive decision. And if this decision concerns only you, then limit yourself, for example, to a comment in the program code.

Thus, RUP is an iterative methodology with a very wide range possible solutions in terms of formalizing the development process.

Let's summarize the second part of the article. RUP, unlike most other methodologies, allows you to choose in a wide range the degree of formalization and iterativeness of the development process, depending on the characteristics of projects and the developing organization.

We will discuss why this is so important in the next part.

Waterfall model Requirements analysis Design Implementation Integration Testing Creating a product specification Creating a product architecture Source code development Integrating individual parts of the source code Testing and eliminating defects

The Unified Software Development Process (USDP) Use Case Model describes the cases in which the application will be used. The analytical model describes the base classes for the application. The design model describes the connections and relationships between classes and allocated objects. The deployment model describes the distribution of software across computers. The implementation model describes internal organization program code. A test model consists of test components, test procedures, and various options testing

Typical components of a software product architecture and typical software requirements Program organization Basic system classes Data organization Business rules User interface Resource management Security Performance Scalability Interaction with other systems (integration) Internationalization, localization Data input/output Error handling

Typical components of a software product architecture and typical software requirements Fault tolerance is a set of system properties that increases its reliability by detecting errors, recovering and localizing bad consequences for the system. When designing any real system to ensure fault tolerance, it is necessary to provide for all possible situations that can lead to system failure and develop mechanisms for handling failures. Reliability is the ability of a system to withstand various failures and failures. Failure is the transition of a system to a completely inoperable state as a result of an error. Failure is an error in the operation of the system that does not lead to system failure. The fewer failures and failures over a certain period of time, the more reliable the system is considered.

Typical components of a software product architecture and typical software requirements. Possibilities for implementing the developed architecture. Possibility of implementing the developed architecture. Redundant functionality. Redundant functionality. Making a decision to purchase ready-made software components. Making a decision to purchase ready-made software components. Change strategy. Change strategy.

Is the overall organization of the program clearly described; whether the specification includes an overview of the architecture and its rationale. Is the overall organization of the program clearly described; whether the specification includes an overview of the architecture and its rationale. Are the major components of the program, their responsibilities and interactions with other components adequately defined? Are the major components of the program, their responsibilities and interactions with other components adequately defined? Whether all the functions specified in the requirements specification are implemented by a reasonable number of system components. Whether all the functions specified in the requirements specification are implemented by a reasonable number of system components. Is there a description of the most important classes and their rationale? Is there a description of the most important classes and their rationale? Is a description of the organization of the database provided? Is a description of the organization of the database provided? Are all business rules defined? Are all business rules defined? Is their impact on the system described? Is their impact on the system described? A checklist of questions that allows you to draw a conclusion about the quality of the architecture:

Checklist of questions that allows you to judge the quality of the architecture: Is the user interface design strategy described? Is the user interface design strategy described? Is the user interface made modular so that changes to it do not affect the rest of the system. Is the user interface made modular so that changes to it do not affect the rest of the system. Is there a description of the data input/output strategy? Is there a description of the data input/output strategy? Has the performance of the system that will be implemented using this architecture been analyzed? Has the performance of the system that will be implemented using this architecture been analyzed? Has the reliability analysis of the designed system been carried out? Has the reliability analysis of the designed system been carried out? Has the scalability and extensibility of the system been analyzed? Has the scalability and extensibility of the system been analyzed?

Software refactoring Code is repeated; the method implementation is too large; there is too much nesting of loops, or the loop itself is very large; the class has poor connectivity (properties and methods of the class should describe only 1 object); a class interface does not form a consistent abstraction; The method takes too many parameters. It is necessary to try to keep the number of parameters reasonably minimal; individual parts of the class change independently of other parts of the class; Refactoring involves adapting software to new hardware and to new operating systems, new development tools, new requirements, as well as software architecture and functionality. This is a change in the internal structure of the software without changing its external behavior, designed to ensure modification of the software. Reasonable reasons for refactoring:

Software refactoring: When changing a program, several classes need to be changed in parallel. If such a situation arises, it is necessary to reorganize classes in order to minimize the places of possible changes in the future; you have to change several inheritance hierarchies in parallel; you have to change several case blocks. It is necessary to modify the program in such a way as to implement the case block, and call it the required number of times in the program; related data elements used together are not organized into classes. If you repeatedly use the same set of data elements, then it is useful to consider combining these data and placing the operations performed on them in a separate class;

Software refactoring method uses more elements of another class than its own. This means that the method needs to be moved to another class and called from the old one; the primitive data type is overloaded. To describe an entity real world It's better to use some class than to overload any existing type data; The class has too limited functionality. It is better to get rid of this class by moving its functionality to another class; “stray” data is transmitted through a chain of methods. Data that is passed to a method only to be passed on to another method is called "stray". If such situations arise, try to change the architecture of classes and methods to get rid of them.

Refactoring the software proxy object does nothing. If the role of a class is to redirect method calls to other classes, then it is best to eliminate such an intermediary object and make calls to other classes directly; one class knows too much about another class. In this situation, it is necessary to make the encapsulation more strict to ensure that the heir has minimal knowledge of its parent; the method has an unfortunate name; data members are public. This blurs the line between interface and implementation, inevitably breaks encapsulation, and limits program flexibility; post comments on source code;

The software refactoring subclass uses only a small fraction of the methods of its ancestors. This situation occurs when a new class is created only to inherit several methods from the base class, and not to describe any new entity. In order to avoid this, it is necessary to transform the base class so that it gives the new class access only to the methods it needs; the code contains global variables. Only those variables that are actually used by the entire program should be global. All other variables must be either local or must become properties of some objects; the program contains code that may be needed someday. When developing a system, it is advisable to provide places where source code can be added in the future.

Annotation: The flexible approach to software creation and the basic principles of flexible development are considered. A list of techniques is provided that, to a certain extent, correspond to the principles of flexible software development. The key values ​​and principles of agile development are analyzed.

You can download the presentation for this lecture.

Purpose of the lecture:

Gain an understanding of the purpose and basic principles of agile software development.

Introduction

Agile software development methodology is focused on using an iterative approach, in which software is created gradually, in small steps, including the implementation of a specific set of requirements. It is assumed that the requirements may change. Agile teams are made up of versatile developers who perform various tasks in the process of creating a software product.

When using agile methodologies, risks are minimized by reducing development to a series of short cycles called iterations, lasting 2-3 weeks. An iteration is a set of tasks scheduled to be completed over a specific period of time. In each iteration, a workable version of the software system is created, which implements the highest priority (for this iteration) customer requirements. Each iteration performs all the tasks necessary to create working software: planning, requirements analysis, design, coding, testing, and documentation. Although a single iteration is usually not sufficient for release new version product, it is assumed that the current software ready for release at the end of each iteration. At the end of each iteration, the team reassesses the priorities of the requirements for the software product, possibly making adjustments to the development of the system.

Principles and meaning of agile development

The agile development methodology has declared key postulates that allow teams to achieve high productivity:

• people and their interactions;
• delivery of working software;
• cooperation with the customer;
• reaction to change.

People and interaction. People are the most important component success. Individual team members and good communication are important for high-performing teams. To facilitate communication, agile methods involve frequent discussions about work results and changes in decisions. Discussions can be held daily for a few minutes and at the end of each iteration with an analysis of the results of the work and a retrospective. For effective communication during meetings, team members should adhere to the following key rules of conduct:

• respect for the opinions of each team member;
• be truthful in all communications;
• transparency of all data, actions and decisions;
• confidence that each participant will support the team;
• commitment to the team and its goals.

To create high-performance teams in flexible methodologies, in addition to an effective team and good communications, perfect software tools are needed.

Working software is more important than comprehensive documentation. All agile methodologies emphasize the need to deliver small pieces of working software to the customer via specified intervals. Software, as a rule, must pass the level of unit testing, testing at the system level. In this case, the amount of documentation should be minimal. During the design process, the team should maintain an up-to-date short document containing the rationale for the decision and a description of the structure.

Cooperation with the customer is more important than formal contractual agreements. In order for the project to be successfully completed, regular and frequent communication with the customer is necessary. The customer must regularly participate in the discussion of decisions made on the software, express his wishes and comments. Involving the customer in the software development process is necessary to create a quality product.

Responding quickly to change is more important than following a plan. The ability to respond to change largely determines the success of a software project. During the process of creating a software product, the customer requirements. Customers very often don’t know exactly what they want until they see something that works. software. Agile methodologies seek feedback from customers during the process of creating a software product. Responsiveness to change is essential to creating a product that satisfies the customer and provides business value.

The tenets of agile development are supported by 12 principles. Specific agile development methodologies define processes and rules that more or less adhere to these principles. Agile creation methodologies software products are based on the following principles:

1. The highest priority is to satisfy the wishes of the customer through the delivery of useful software in a short time, followed by continuous updates. Agile methodologies involve rapid delivery of the initial version and frequent updates. The team's goal is to deliver a working version within a few weeks of starting the project. Further software systems with progressively more functionality should be shipped every few weeks. The customer can start industrial operation system, if he considers it to be functional enough. Also, the customer can simply familiarize himself with current version software, provide your feedback with comments.
2. Do not ignore changing requirements, even at late stages of development. Agile processes allow you to accommodate changes to provide a competitive advantage to the customer. Teams using agile methods strive to ensure a high-quality program structure, with minimal impact of changes on the system as a whole.
3. Deliver new working versions of software frequently, at intervals of one week to two months, with a preference for shorter deadlines. The goal is to deliver a program that meets the user's needs with a minimum of accompanying documentation.
4. Clients and developers must work together throughout the entire project. It is believed that for successful project customers, developers and all interested parties must communicate frequently and extensively to purposefully improve the software product.
5. Projects must be implemented by motivated people. Create normal working conditions for the project team, ensure necessary support and trust that team members will get things done.
6. The most effective and efficient method of conveying information to the development team and exchanging opinions within it is face-to-face conversation. In agile projects, the main mode of communication is simple human interaction. Written documents are created and updated gradually as software is developed and only when necessary.
7. A working program is the main indicator of progress in a project. The approach to completion of an agile project is judged by how well the currently available software meets the customer's requirements.
8. Agile processes promote long-term development. Customers, developers and users must be able to maintain a constant pace indefinitely.
9. A relentless focus on technical excellence and quality design increases the impact of agile technologies. Agile team members strive to produce quality code by refactoring regularly.
10. Simplicity is the art of achieving more by doing less. Team members solve current problems as simply and efficiently as possible. If any problem arises in the future, it is possible to make changes to high-quality code without great expense.
11. The most best architecture, requirements and projects are issued by self-organizing teams. In agile teams, tasks are assigned not to individual members, but to the team as a whole. The team decides how best to implement the customer's requirements. Team members work together on all aspects of the project. Each participant is allowed to contribute to the common cause. There is no team member who is solely responsible for the architecture, requirements, or tests.
12. The team must regularly think about how to become even more effective, and then adjust and adjust their behavior accordingly. An agile team continually adjusts its organization, rules, agreements, and relationships.

The above principles, to a certain extent, correspond to a number of software development methodologies: