So, the essence of the structural approach to the development of EIS software lies in its decomposition (partitioning) into automated functions: the system is divided into functional subsystems, which, in turn, are divided into subfunctions, those into tasks, and so on up to specific procedures. At the same time, the system retains a holistic view in which all constituent components are interconnected. When developing a "bottom-up" system, from individual tasks to the entire system, integrity is lost, 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 - the principle of organizing the constituent parts of the system into hierarchical tree structures with the addition of new details at each level.

The selection of 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 of these principles are:

1. The principle of abstraction - highlighting the essential aspects of the system and distraction from the non-essential.

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

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

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

· DFD (Data Flow Diagrams) - diagrams of data flows;

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

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

In almost all methods of the structural approach (structural analysis), two groups of modeling tools are used at the stage of formation of software requirements:

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

2. Diagrams modeling data and their relationships (ERD).

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

At the stage of formation of requirements for software, 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 (using SADT models as usually limited to this stage only, since they were not originally intended for software design). With the help of ERD, the description of the data used in the organization at the conceptual level is performed, regardless of the means of implementing the database (DBMS).

Waterfall model Requirements analysis Design Implementation Integration Testing Product specification drafting Product architecture drafting Source code development Integration of source code parts Testing and debugging

The Unified Software Development Process (USDP) Use Case Model describes the cases in which an 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 dedicated objects. The deployment model describes the distribution of software across computers. The implementation model describes the internal organization of the program code. The test model consists of test components, test procedures, and different test cases.

Typical software product architecture components 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 Input-output data Error handling

Typical Software Product Architecture Components and Typical Software Requirements Fault tolerance is a set of system properties that enhance system reliability by detecting errors, recovering, and isolating bad consequences for the system. When designing any real system to ensure fault tolerance, it is necessary to anticipate all possible situations that can lead to a 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 the system as a result of an error to a completely inoperable state. A failure is an error in the operation of the system that does not lead to the failure of the system. The fewer failures and failures for a certain period of time, the more reliable the system is considered.

Typical components of the software product architecture and typical software requirements Possibilities of implementing the developed architecture. Possibilities of implementing the developed architecture. redundant functionality. redundant functionality. Deciding on the purchase of ready-made software components. Deciding on the purchase of ready-made software components. Change strategy. Change strategy.

Is the general organization of the program clearly described; whether the specification includes an overview of the architecture and its rationale. Is the general organization of the program clearly described; whether the specification includes an overview of the architecture and its rationale. Are the main components of the program adequately defined, their areas of responsibility and interaction with other components. Are the main components of the program adequately defined, their areas of responsibility and interaction with other components. 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. Are the most important classes described and justified. Are the most important classes described and justified. Whether a description of the organization of the database is given. Whether a description of the organization of the database is given. 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 make a conclusion about the quality of the architecture:

A checklist of questions that allows you to make a conclusion about the quality of the architecture: Is the user interface design strategy described. Whether the user interface design strategy is described. Is it done user interface modular so that its changes do not affect the rest of the system. Whether the user interface is made modular so that changes to it do not affect the rest of the system. Whether a description of the I/O strategy has been provided. Whether a description of the I/O strategy has been provided. Whether a performance analysis of the system that will be implemented using this architecture has been carried out. Whether a performance analysis of the system that will be implemented using this architecture has been carried out. Has the reliability analysis of the designed system been carried out? Has the reliability analysis of the designed system been carried out? Has an analysis of the scalability and extensibility of the system been carried out? Has an analysis of the scalability and extensibility of the system been carried out?

Software refactoring Code is repeated; method implementation is too large; 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. You should try to keep the number of parameters to a reasonable minimum; individual parts of the class change independently of other parts of the class; Refactoring involves adapting software to new hardware and new operating systems, new development tools, new requirements, and software architecture and functionality. This is a change in the internal structure of the software without changing its external behavior, designed to ensure the modification of the software. Reasonable reasons to refactor:

Software refactoring when changing the program requires a parallel change of several classes. If such a situation arises, it is necessary to reorganize the classes in order to minimize the places of possible changes in the future; 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 make the implementation of the case block, and call it the required number of times in the program; related data members used together are not organized into classes. If you repeatedly use the same set of data elements, then it is advisable to consider combining this data and placing operations performed on them in a separate class;

A 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 elementary data type is overloaded. To describe the essence of the real world, it is better to use a class than to overload any existing data type; the class has too limited functionality. It is better to get rid of this class by transferring its functionality to another class; "stray" data is passed along the chain of methods. Data that is passed to a method only to be passed to another method is called stray data. When such situations arise, try to change the architecture of classes and methods to get rid of them.

Refactoring the media object does nothing. If the role of a class is to redirect method calls to other classes, then it's best to eliminate that proxy 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; place comments in the source code;

A 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 a few 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 in such a way that it gives access to the new class only to the methods it needs; the code contains global variables. Only variables that are actually used by the entire program should be global. All other variables must either be local or must become properties of some object; the program contains code that may someday be needed. When developing a system, it is advisable to provide for places where source code can be added in the future.

Software Development Models Waterfall Waterfall Spiral Extreme Programming UI Prototyping Incremental W-Model Testing Unified Software Development Process (USDP) MSF Methodology

Waterfall model Requirements analysis Write product specification Design Write product architecture Implementation Develop source code Integrate separate parts of source code Test and fix defects

Extreme Programming Initial Requirements Analysis Design Integration Implementation Testing New Requirements Review/Approve/Modify Development Plan Release Product

UI Prototyping Product release Development of software with changes Clarification of requirements and specifications Modification of the prototype and improvement of some functionality Basic functionality Interface prototype Preliminary specification

Incremental Development Iteration 1 Iteration 2 …. Requirements Analysis Design Implementation Component Testing Integration Testing the Whole Whole Iteration N

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 selected objects Ø The deployment model describes the distribution of software across computers. Ø The implementation model describes the internal organization of the program code. Ø The test model consists of test components, test procedures and different test cases

Unified Software Development Process (USDP) Requirements Gathering Iter 1…. Iter N Designing Iter 1…. Iter N Implementation of Iter 1…. Iter N Designing Iter 1…. Iter N Testing Iter 1…. Iter N

Typical software product architecture components and typical software requirements Ø Ø Ø Ø Program organization Main system classes Data organization Business rules User interface Resource management Security Performance Scalability Interaction with other systems (integration) Internationalization, localization Input-output data Error handling

Typical Software Product Architecture Components and Typical Software Requirements Fault tolerance is a set of system properties that enhance system reliability by detecting errors, recovering, and isolating bad consequences for the system. When designing any real system to ensure fault tolerance, it is necessary to anticipate all possible situations that can lead to a 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 the system as a result of an error to a completely inoperable state. A failure is an error in the operation of the system that does not lead to the failure of the system. The fewer failures and failures for a certain period of time, the more reliable the system is considered.

Typical components of a software product architecture and typical software requirements Reliability curve N t 1 t The farther, the harder it will be to find an error. The more complex the system, the greater the likelihood of failures and failures.

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

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

A checklist of questions that allows you to make a conclusion about the quality of the architecture: Ø Is the user interface design strategy described. Ø Whether the user interface is made modular so that changes to it do not affect the rest of the system. ØWhether the description of the data input/output strategy is given. Ø Whether the performance analysis of the system that will be implemented using this architecture has been carried out. Ø Whether the reliability analysis of the designed system has been carried out. Ø Whether the analysis of issues of scalability and extensibility of the system has been carried out.

Software Refactoring Refactoring involves adapting software to new hardware and new operating systems, new development tools, new requirements, and software architecture and functionality. This is a change in the internal structure of the software without changing its external behavior, designed to ensure the modification of the software. Reasonable reasons for refactoring: Code is repetitive; method implementation is too large; 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. You should try to keep the number of parameters to a reasonable minimum; individual parts of the class change independently of other parts of the class;

Software refactoring when changing the program requires a parallel change of several classes. If such a situation arises, it is necessary to reorganize the classes in order to minimize the places of possible changes in the future; 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 make the implementation of the case block, and call it the required number of times in the program; related data members used together are not organized into classes. If you repeatedly use the same set of data elements, then it is advisable to consider combining this data and placing operations performed on them in a separate class;

A 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 elementary data type is overloaded. To describe the essence of the real world, it is better to use a class than to overload any existing data type; the class has too limited functionality. It is better to get rid of this class by transferring its functionality to another class; "stray" data is passed along the chain of methods. Data that is passed to a method only to be passed to another method is called stray data. When such situations arise, try to change the architecture of classes and methods to get rid of them.

Refactoring the media object does nothing. If the role of a class is to redirect method calls to other classes, then it's best to eliminate that proxy 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; place comments in the source code;

A 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 a few 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 in such a way that it gives access to the new class only to the methods it needs; the code contains global variables. Only variables that are actually used by the entire program should be global. All other variables must either be local or must become properties of some object; the program contains code that may someday be needed. When developing a system, it is advisable to provide for places where source code can be added in the future.

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 of decomposition of systems: 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 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 relationships between them, and the behavior of the system in terms of messaging between objects.

So, the essence of the structural approach to the development of IS software lies in its decomposition into automated functions: the system is divided into functional subsystems, which in turn are divided into subfunctions, they are divided into tasks, and so on up to specific procedures. At the same time, IS preserves the integrity of the representation, where all components are interconnected. When developing a system "from the bottom up", from individual tasks to the entire system, integrity is lost, 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. The selection of two basic principles does not mean that the remaining principles are secondary, since ignoring any of them can lead to unpredictable consequences.

The main of these principles are:

o abstraction - highlighting the essential aspects of the system;

o consistency - validity and consistency of the elements of the system;

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

Methodological foundations of software development technologies

Visual modeling. A software model is generally called 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 different people with specific interests, roles, or tasks.

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

o the difficulties of the designed system;

o the necessary completeness of its description;

o knowledge and skills of project participants;

o time allotted for design.

Visual modeling has 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 automating software development, has now acquired a new meaning, covering most of the 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.

Annotation: A flexible approach to software development, 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 focused on the use of an iterative approach, in which software is created gradually, in small steps, including the implementation of a certain set of requirements. It is assumed that the requirements may change. Teams using agile methodologies are formed from versatile developers who perform various tasks in the process of creating a software product.

When using agile methodologies, risk minimization is carried out 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 in a specific period of time. In each iteration, a workable version of the software system is created, in which the most priority (for this iteration) customer requirements. Each iteration performs all the tasks necessary to create workable software: planning, requirements analysis, design, coding, testing, and documentation. While a single iteration is generally not enough to release new version product, it is understood that the current software ready for release at the end of each iteration. At the end of each iteration, the team re-prioritizes the requirements for the software product, possibly making adjustments to the system development.

Principles and meaning of agile development

For the agile development methodology, key postulates are declared that allow teams to achieve high performance:

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

People and interaction. People are the most important part of success. Individual team members and good communications are essential for high-performing teams. To facilitate communication, agile practices involve frequent discussions of work results and changes to 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. To communicate effectively in meetings, team members must adhere to the following key rules of conduct:

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

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

Working software is more important than comprehensive documentation. All agile methodologies highlight the need to deliver small pieces of working software to the customer at predetermined intervals. Software, as a rule, must pass the level of unit testing, testing at the system level. The amount of documentation should be kept to a minimum. During the design process, the team should keep up to date a short document containing the rationale for the decision and a description of the structure.

Cooperation with the customer is more important than formal agreements under the contract. 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 the decisions made on the software, express their 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. In the process of creating a software product, they often change customer requirements. Customers often don't know exactly what they want until they see it working. software. Agile methodologies look for feedback from customers in the process of creating a software product. Responsiveness to change is essential to create a product that delivers customer satisfaction and business value.

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

1. The highest priority is to satisfy the customer's wishes by delivering useful software in a short time, followed by continuous updates. Agile practices include fast initial release and frequent updates. The goal of the team is to deliver a working version within a few weeks of starting the project. Going forward, software systems with incremental functionality should ship every few weeks. The customer can start commercial operation of the system if he considers it functional enough. Also, the customer can simply get acquainted with the current version of the software, provide feedback with comments.
2. Don't ignore changing requirements, even late in development. Flexible processes allow changes to be taken into account to ensure the competitive advantage of the customer. Teams using agile methodologies strive to make the program structure of high quality, with minimal impact of changes on the system as a whole.
3. Deliver new working versions of the software frequently, at intervals of one week to two months, with a preference for shorter deadlines. At the same time, the goal is to deliver a program that meets the needs of the user, with a minimum of accompanying documentation.
4. Customers and developers must work together throughout the project. It is believed that for a successful project, customers, developers, and all stakeholders must communicate often and in many ways to purposefully improve the software product.
5. Projects should be implemented by motivated people. Give the project team a healthy working environment, provide the support they need, and trust that the team members will get the job done.
6. The most effective and productive method of conveying information to the development team and exchanging opinions within it is a face-to-face conversation. In agile projects, the main mode of communication is simple human interaction. Written documents are created and updated incrementally as the software is developed and only when necessary.
7. A working program is the main indicator of project progress. The approach of an agile project to completion is judged by how well the current program meets the customer's requirements.
8. Agile processes encourage long-term development. Customers, developers and users must be able to maintain a constant pace indefinitely.
9. A relentless focus on engineering excellence and quality design enhances the returns on agile technologies. Agile team members strive to create quality code by regularly refactoring.
10. Simplicity is the art of achieving more by doing less. Team members solve current tasks as simply and efficiently as possible. If there is a problem in the future, then it is possible to make changes to the quality code at no great cost.
11. The best architectures, requirements, and designs come from self-organizing teams. In flexible teams, tasks are assigned not to individual members, but to the team as a whole. The team itself decides how best to implement the requirements of the customer. Team members work collaboratively on all aspects of the project. Each participant is allowed to contribute to the common cause. No team member is solely responsible for the architecture, requirements, or tests.
12. The team should regularly think about how to become even more effective, and then adjust and fine-tune their behavior accordingly. An agile team constantly adjusts its organization, rules, agreements, and relationships.

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