1. Purpose of programming technology. History of the development of programming technology. Types of software projects. Components of programming technology. Project, product, process and people

2. Program life cycle. The cyclical nature of development. Basic concepts of programming technology. Processes and models. Phases and turns. Milestones and artifacts. Stakeholders and employees.

3. Identification and analysis of requirements. Software requirements. Requirements development flowchart. Requirements management.

4. Architectural and detailed design. Implementation and coding. Testing and verification. Quality control process. White box and black box methods. Inspections and reviews. Testing goals. Verification, validation and system testing. Maintenance and ongoing development.

5. Models of the development process. Waterfall and conveyor models. Spiral and incremental models. Flexible development process models.

6. Construction of a process model. Identify process requirements. Phases, milestones and artifacts used. Choosing a process architecture. Procedure for carrying out a standard project. Documented procedures.

7. Development team models. Collective nature of development. Optimal team size. Subordination of project participants. Team development and staff development. Specialization, cooperation and interaction.

8. Development team models. Hierarchical team model. Surgical team method. Peer team model.

9. The nature of programming. The science of programming. The art of programming. The craft of programming. Programming paradigms. Structured programming. Logic programming. Object-oriented programming.

10. Software architecture. Event management. Client/server architecture. Services. Three-layer architecture. Program design. Conceptual design. Logical design. Detailed design.

1. Novikov approaches to software development" http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Extreme programming. – St. Petersburg: Peter, 2002.

3. Development technology software. – St. Petersburg. : Peter, 2004.

4. Brooks Jr. software systems are designed and created. M.: Nauka, 1975; new edition of the translation: The Mythical Man-Month. SPb.: SYMBOL+, 1999.

5. Algorithms + data structures = programs. M., Mir, 1978.

6. Systematic programming. Introduction. M.: Mir, 1977.

7. Structured programming. M.: Mir, 1975.

8. Programming discipline. M.: Mir, 1978.

9. Software development technologies. – St. Petersburg: Peter, 2002.

10. Terekhov programming. M.: BINOM, 2006.

11. Rambo J. Unified software development process. St. Petersburg: Peter, 2002.

Economic theory for managers

Basic microeconomic theories. Examples of application in the analysis of economic processes. Basic macroeconomic theories. Examples of application in the analysis of economic processes. Principles and methods of managing economic processes. Tools for assessing the level of development of economic processes Problems of expanded reproduction. Factors of economic growth of the Russian economy. Criteria and indicators of sustainable development. Smoothing out cyclical fluctuations. The role of the multiplier and accelerator in assessing the pace of economic development. Production functions in economics. Examples of application in the analysis of economic processes. Profit. Calculation of indicators affecting profit, graphic image break-even point. Methodology for implementing investment policy.

Course of economic theory: textbook for universities / Ed. . –Kirov: “ASA”, 2004. Kolemaev - mathematical modeling. Modeling of macroeconomic processes and systems: textbook. M.: UNITY-DANA, 2005. Bazhin cybernetics. Kharkov: Consul, 2004. Leushin workshop on methods of mathematical modeling: textbook. Nizhny Novgorod State tech. univ. - N. Novorod, 2007. Politicians about economics: Lectures of Nobel laureates in economics. M.: Modern economics and law, 2005. Cheremnykh. Advanced level: Textbook.-M.:INFRA-M, 2008. Evolution of mini-economy institutions. Institute of Economics, Ural Branch of the Russian Academy of Sciences, - M.: Nauka, 2007.

Technologies for development and management decision making [N]

Decision making as the basis of a manager’s activity. Introduction to decision theory. Basic concepts of decision theory. Business management models and their impact on decision making. Various ways classification of solutions. Classifications: according to the degree of formality, according to the degree of routine, according to frequency, according to urgency, according to the degree of achievement of goals, according to the method of choosing an alternative. Basic methods of decision making. Volitional methods of decision making. Goals of decision making. Time when searching for solutions. Basic mistakes Mathematical methods of decision making. Mathematical aspects of decision theory. Operations research. Mathematical approach to decision making. Decision tree. Models of development and decision making. Game theory. Mathematical methods of decision making. Mathematical aspects of decision theory. Models of queuing theory. Inventory management models. Linear programming model. Transport tasks. Simulation modeling. Network analysis. Economic analysis. Limitations of rational models. Features of development and decision-making in a group. A method for determining group cohesion based on the degree of connectivity of sets. Methods for making collective decisions. Consensus method. Voting methods. Creative methods of decision making. Brainstorm. Conference of ideas. Ship's Council. De Bono's "Thinking Hats" method. Theory of inventive problem solving (TRIZ). The perfect end solution. Examples of problems and their solutions using TRIZ. Application of TRIZ methods when making unique and creative decisions. Methods for developing solution ideas and adapting them to the situation. Goal tree model. Strategy for coordinating interests. Formation of decisions to coordinate interests. Methods for determining the interests of counterparties. Decision support systems (expert systems). History of the creation of decision-making systems. Classification of decision-making systems. Typical structure of an expert system. Methods of presenting knowledge. Methods of logical inference. Application expert systems on practice.

I. Decision Making Theory: Textbook. - M.: Exam, 2006. - 573 p. I. Decision making. Theory and methods for developing management decisions. Tutorial. - M.: MarT, 2005. - 496 pp. Development of management decisions - M.: Publishing House "Delo", 2004 - 392 pp. G. Expert assessments and decision making. - M.: Patent, 1996. - 271 p. Taha // Introduction to Operations Research = Operations Research: An Introduction. - 7th ed. - M.: “Williams”, 2007. - P. 549-594. G. Theil. Economic forecasts and decision making. M.: “Progress” 1970. K. D. Lewis. Methods for forecasting economic indicators. M.: “Finance and Statistics” 1986. G. S. Kildishev, A. A. Frenkel. Time series analysis and forecasting. M.: “Statistics” 1973. O. Kim, C. W. Muller, U. R. Klekka and others. Factor, discriminant and cluster analysis. M.: “Finance and Statistics” 1989. Effective manager. Book 3. Decision making. – MIM LINK, 1999 Turevsky and management of a motor transport enterprise. - M.: Higher School, 2005. , ; edited by . System analysis in management: tutorial. – M.: Finance and Statistics, 2006. , Tinkov: textbook. – M.: KNORUS, 2006.

Modeling business processes in integrated management systems

By what principles are business processes distinguished? What is the problem of a holistic description of business processes? What is a system, what properties does it have? The role of systems analysis in business process modeling? Process as an object of control. Process environment. Basic elements of a business process. Advantages and disadvantages of functional and process management. PDCA management cycle. Stages of the process management cycle. PDCA Cycle and Requirements Implementation ISO standard 9001:2008. SADT methodology (Structured Analysis and Design Technique - method of structural analysis and design). Essence. Basic provisions. How is the functional model of activity represented in the IDEF0 methodology? What do the activities in the functional model diagrams mean, how are they displayed according to the IDEF0 methodology? What are the arrows in functional model diagrams for, what are their types and types? DFD methodology. Essence. Basic components of DFD diagrams. What are the features of DFD diagrams and what is described in them? What are the features of DFD diagram objects? What do the arrows on a DFD diagram mean? IDEF3 methodology. Essence. Documentation and modeling tools. What are the features of IDEF3 diagrams and what is described in them? What are the features of IDEF3 diagram objects? And the shooter? Classification of processes. Typical business processes. Reengineering and its technology. When is it advisable to use reengineering when managing a company? Monitoring and measuring processes. Indicators of organizational processes. Numerical and rating assessments of processes.

"Modeling business processes with AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI" 2003 "Creating information systems with AllFusion Modeling Suite" ed. "Dialog-MEPhI" 2003 "Practice of functional modeling with AllFusion Process Modeler 4.1. (BPwin) Where? Why? How?" ed. "Dialogue-MEPhI" 2004 Dubeykovsky modeling with AllFusion Process Modeler (BPwin). ed. "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "Methodology of structural analysis and design SADT" 1993 classic work on the SADT methodology. Cheremnykh analysis of systems: IDEF-technologies, Modeling and analysis of systems. IDEF technologies. Workshop. M.: Finance and Statistics, 2001. “Structural business models: DFD technologies” http://www. /Level4.asp? ItemId=5810 "Theory and practice of business process reorganization" 2003/ P50.1.. Functional modeling methodology. M.: Gosstandart of Russia, 2000. http://www. IDEF0, IDEF3, DFD http://www. Modeling business processes using BPwin http://www. /department/se/devis/7/ IDEF0 in modeling business management processes http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

Evaluating the effectiveness of software products

1. IT architecture

2. Domains of management processes.

3. List of processes in the Planning and Organization domain

4. List of domain processes Acquisition and Implementation

5. List of processes in the Operation and Maintenance domain

6. List of processes in the Monitoring and Evaluation domain

7. Characteristics of the levels of the process maturity model

9. KPI and KGI their relationship and purpose

1. 10.General IT controls and application controls. Areas of responsibility and responsibilities of business and IT.

Cobit 4.1 Russian edition.

Legal regulation of the creation and use of intellectual property

1. List intellectual rights on the results of intellectual activity and reveal their content.

2. List the types of agreements for the disposal of exclusive rights. Describe each of these agreements on the disposal of exclusive rights.

4. Describe the main provisions of legal protection of a Computer Program as an object of copyright.

5. Compare the main provisions of legal protection of the Database as an object of copyright and as an object of related rights.

6. Describe the conditions for patentability of objects of patent rights: inventions; utility models; industrial designs.

7. Expand the content of the patentability criteria for an invention: novelty; inventive step; industrial applicability.

8. Describe the conditions and procedure for obtaining a patent for an invention, utility model or industrial design, as well as the conditions ensuring the validity of patents and their validity periods.

9. Define “know-how” and list the conditions during the creation of which legal protection of production secrets arises and is carried out.

10. List the protected means of individualization and give their comparative characteristics.

1. Intellectual property rights in Russian Federation, textbook // M, Prospekt, 2007

2., Intellectual Property Law, textbook // M, RIOR, 2009.

Project and software development management [I]

What is methodology, why is it needed. General structure of the methodology, main elements of the methodology. Principles for designing your own methodology. Examples of various artifacts, roles, competencies, boundary conditions. The structure of methodology according to Cowburn, methodology metrics. Cowburn's design criteria. Criteria for choosing a methodology, Cowburn matrix. Project life cycle. Waterfall and iterative models life cycle. Limits of applicability for waterfall and iterative models. RUP as an example of iterative methodology. Basic concepts of RUP, limits of applicability. The role of humans in software development. Agile methodologies, basic principles of agile methodologies. The reason for the emergence of flexible methodologies. Scrum as an example of flexible methodology. Roles, artifacts, activities in Scrum. Scrum applicability limits. Extreme Programming (XP) Ideas, values, basic practices, limits of applicability. Similarities and differences between Scrum and XP. Requirements collection and management. Basic practices, terms, principles. Approaches to documenting a project and product, main types of documents. Examples of requirements management practices from the methodologies discussed in the course. Software development planning. Types of plans, risk management, popular risks. Examples of development planning practices from the methodologies discussed in the course. Testing in software development. The concept of assembly (build) software product. Basic testing methods, terms. Examples of testing practices from the methodologies discussed in the course. The concept of assembly (build), methods of storing code, tools. Two principles for organizing work with a version control system. Features of the product release/display process for different product categories, examples of practices. Modern software architecture concepts, multi-tier architectures,architecture criteria. List necessary solutions when designing software, approaches to choosing a data storage system.

Kent Beck - Extreme Programming Frederick Brooks - The Mythical Man-Month or How They Are Created software systems. Tom DeMarco - Deadline. A novel about project management. Tom De Marco, Timothy Lister - Waltzing with the Bears. Tom de Marco, Timothy Lister - Human factor_ successful projects and teams. Alistair Cowburn - Each project has its own methodology. Alistair Cowburn - People as non-linear and the most important components in creating software. Andriy Orlov - Notes of an automation engineer. Professional confession. Philipp Kratchen - Introduction to the Rational Unified Process. Henrik Kniberg - Scrum and XP: notes from the front lines. Presentations of lectures on the course

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 organization components systems into hierarchical tree structures with new details added 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 tools corresponds to certain types of 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).

1.Coding

At the software development stage, the following main actions are performed: coding; testing; development of a PP help system; creation of user documentation; creating a version and installation of software,

Coding is the process of converting high-level and low-level design results into a finished software product. In other words, when coding, the compiled PP model is described using the chosen programming language, which can be any of existing languages. The choice of language is carried out either at the request of the customer, or taking into account the problem being solved and personal experience developers.

When coding, you must follow the standard for the selected language, for example, for the C language it is ANSI C, and for C++ it is ISO/IEC 14882 “Standard for the C++ ProgrammingLanguage”.

In addition to the generally accepted standard for a programming language, a company may also develop its own additional requirements for the rules for writing programs. They mainly concern the rules for formatting program text.

Following the standard and company rules allows you to create a program that works correctly, is easy to read, and understandable to other developers, containing information about the developer, creation date, name and purpose, as well as the necessary data for configuration management.

At the coding stage, the programmer writes programs and tests them himself. This type of testing is called unit testing. All issues related to software testing are discussed in Chapter. 10, the testing technology that is used at the software development stage is also described here. This technology is called testing "glass box" (glassbox); sometimes it is also called testing "white box" (whitebox) as opposed to the classical concept of a “black box”.

In black box testing, a program is treated as an object whose internal structure is unknown. The tester enters data and analyzes the result, but he does not know exactly how the program works. When selecting tests, a specialist looks for input data and conditions that are interesting from his point of view, which can lead to non-standard results. He is interested primarily in those representatives of each class of input data for which most likely Errors in the program under test may appear.

When testing a “glass box” the situation is completely different. The tester (in this case the programmer himself) develops tests based on knowledge of the source code to which he has access full access. As a result, he receives the following benefits.

1. Direction of testing. The programmer can test the program in parts, develop special test subroutines that call the module under test and transmit to it the data of interest to the programmer. It is much easier to test a separate module as a “glass box”.

2.Full code coverage. The programmer can always determine which code fragments work in each test. He sees which other branches of the code remain untested and can select the conditions under which they will be tested. Below we describe how to track the degree of code coverage of the tests performed.

3. Ability to control the flow of commands. The programmer always knows which function should be executed next in the program and what its current state should be. To find out whether a program works as he thinks, a programmer can include debugging commands that display information about its execution, or use a special program to do this. software called a debugger. The debugger can do a lot of useful things: monitor and change the sequence of execution of program commands, show the contents of its variables and their addresses in memory, etc.

4.Ability to monitor data integrity. The programmer knows which part of the program should change each data element. By monitoring the state of the data (using the same debugger), he can identify errors such as data being changed by the wrong modules, their incorrect interpretation, or unsuccessful organization. The programmer can automate testing himself.

5.Vision of internal boundary points. IN source code those boundary points of the program that are hidden from outside view are visible. For example, several completely different algorithms may be used to perform a certain action, and without looking at the code, it is impossible to determine which one the programmer chose. Another common example would be an overflow problem in a buffer used to temporarily store input data. The programmer can immediately tell at what amount of data the buffer will overflow, and he does not need to conduct thousands of tests.

6. Possibility of testing determined by the selected algorithm. Testing data processing that uses very complex computational algorithms may require special technologies. Classic examples include matrix transformation and data sorting. A tester, unlike a programmer, needs to know exactly what algorithms are used, so he has to turn to specialized literature.

Glass box testing is part of the programming process. Programmers do this work constantly, they test each module after it is written, and then again after integrating it into the system.

When performing unit testing, you can use either structural or functional testing technology, or both.

Structural testing is a type of glass box testing. Its main idea is the correct choice of the software path to be tested. In contrast to him functional testing falls into the category of black box testing. Each program function is tested by entering its input data and analyzing its output. At the same time, the internal structure of the program is very rarely taken into account.

Although structural testing is much more powerful theoretical basis, most testers prefer functional testing. Structural testing lends itself better mathematical modeling, but this does not mean at all that it is more effective. Each technology allows you to identify errors missed when using the other. From this point of view, they can be called equally effective.

The object of testing can be not only the full path of the program (the sequence of commands that it executes from start to finish), but also its individual sections. It is absolutely unrealistic to test all possible ways of executing a program. Therefore, testing specialists identify from all possible paths those groups that absolutely need to be tested. For selection they use special criteria called coverage criteria (coveragecriteria), which determine a very real (even if quite large) number of tests. These criteria are sometimes called logical coverage criteria, or completeness criteria.

3. Development of a help system for the software product. Creating User Documentation

It is advisable to appoint one of the project employees as a technical editor of the documentation. This employee may also perform other work, but his main task should be the analysis of documentation, even if other employees are also developing it.

It often happens that several people work on the creation of software, but none of them bears full responsibility for its quality. As a result, the software not only does not benefit from the fact that it is developed by more people, but also loses, since each subconsciously shifts responsibility to the other and expects that his colleagues will do this or that part of the work. This problem is solved by appointing an editor who bears full responsibility for the quality and accuracy of technical documentation.

reference system The PP is formed on the basis of the material developed for the user manual. It is formed and created by the person responsible for performing this work. It can be either a technical editor or one of the developers together with the technical editor.

A well-documented PP has the following advantages.

1. Ease of use. If the software is well documented, then it is much easier to apply. Users learn it faster, make fewer mistakes, and as a result do their work faster and more efficiently.

2. Lower cost technical support. When the user cannot figure out how to perform the actions he needs, he calls the PCB manufacturer's technical support service. Running such a service is very expensive. A good manual helps users solve problems on their own and reduce the need to contact the technical support team.

3. High reliability. Incomprehensible or sloppy documentation makes the software less reliable, because its users are more likely to make mistakes and find it difficult to understand what caused them and how to deal with their consequences.

Ease of maintenance. A huge amount of money and time is spent on analyzing problems that are caused by user errors. Changes made in new software releases are often simply changes to the interface of old functions. They are introduced so that users finally figure out how to use the software and stop calling technical support. Good guide to a large extent

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 possible consequences errors that can range from minor financial losses to correct errors 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, formalize the decision made 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 cascade approach, but also provides a very high degree 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 government 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 for the creation of 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 formally the obligation to complete all phases or some minimum number iterations are not indicated anywhere in RUP; the entire approach is focused on the fact that there are quite a lot of them. The limited number of iterations does not allow the full benefits of RUP to be fully exploited. 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.

Today in software engineering there are two main approaches to the development of EIS software, the fundamental difference between which is due to different ways decomposition of systems. The first approach is called functional-modular or structural. It 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. The second, object-oriented approach uses object decomposition. In this case, the structure of the system is described in terms of objects and connections between them, and the behavior of the system is described in terms of the exchange of messages between objects.

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 automated system maintains a holistic view in which 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.

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

the principle of “divide and conquer” (see subsection 2.1.1);

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.

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

the principle of abstraction - highlighting the essential aspects of the system and abstracting from the unimportant;

principle of consistency - validity and consistency of system elements;

principle of data structuring - data must be structured and hierarchically organized.

The structural approach uses mainly 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 of which are:

DFD (Data Flow Diagrams) - data flow diagrams;

SADT (Structured Analysis and Design Technique - method of structural analysis and design) - models and corresponding functional diagrams;

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

Data flow diagrams and entity-relationship diagrams are the most commonly used types of models in CASE tools.

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 (use of SADT models , as a rule, are limited to only this stage, 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 a conceptual level, independent of the database implementation tools (DBMS).

At the design stage, DFDs are used to describe the structure of the designed software system, and they can be refined, expanded and supplemented with new designs. Similarly, ERDs are refined and supplemented with new constructs that describe the representation of data at a logical level suitable for subsequent generation of a database schema. These models can be supplemented with diagrams reflecting the software system architecture, block diagrams programs, hierarchy of screen forms and menus, etc.

The listed models together provide a complete description of EIS software, regardless of whether the system is existing or newly developed. The composition of the diagrams in each specific case depends on the complexity of the system and the required completeness of its description.

The subject area for most of the diagram examples given in this chapter is the tax system of the Russian Federation, the most complete description of which is contained in the Tax Code of the Russian Federation. Information Technology, used in the tax system of the Russian Federation, have certain features.