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. Software development technology. – 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, graphical representation of the 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. Different ways to classify 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 of expert systems in 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: textbook. – 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 implementation of ISO 9001:2008 requirements. 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 the intellectual rights to the results of intellectual activity and disclose 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 the 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 life cycle models. 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) of a 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 concepts of software architecture, multi-level architectures, architecture criteria. List of necessary decisions when designing software, approaches to choosing a data storage system.

Kent Beck - Extreme Programming Frederick Brooks - The Mythical Man-Month or how software systems are created. 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 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. Principle of data structuring - 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 software model is described using the chosen programming language, which can be any of the 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 the personal experience of the 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 primarily interested in those representatives of each class of input data in which errors in the program under test are most likely to occur.

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 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 it does, a programmer can include debugging commands that display information about its progress, or use a special software tool called a debugger to do this. 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 the 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 all the time; they test each module after writing it, 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 has a much stronger theoretical basis, most testers prefer functional testing. Structural testing lends itself better to mathematical modeling, but this does not mean 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.

The PP help system 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 of 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 management to a great extent

When considering software development technology, it is necessary to use a systematic approach, which involves considering not some individual aspects of the software development problem, but the problem as a whole. The systems approach is implemented in space and time.

A systematic approach in time considers the sequence of stages of software creation from the moment of formation of an unmet need for software until it is resolved and support in operation of the resulting software product.

Systematic approach in "space" involves considering the software being developed as part of the system. At the same time, on the basis of studying the information needs of the system, which will include the developed software, the goals and set of software functions are formulated, and prototypes of software tools are analyzed. Software requirements are generated and documented.

Modern software development technology considers programming as one of the development stages in a chain of successive stages of the development cycle. All these stages are united by the concept of the software life cycle and must be supported by appropriate software and hardware tools.

In accordance with the international standard ISO/IEC 12207 “information technology - Software life cycle processes”, the software development process contains the following stages of the software life cycle:

1) analysis of system requirements and scope of application;

2) design of system architecture;

3) analysis of software requirements (specifications, external interfaces);

4) software architecture design;

5) detailed design of each software unit;

6) software coding (programming)

7) testing of software units;

8) integration (software combination) and testing of a set of software units;

9) software qualification tests (comprehensive testing);

10) system integration software structure units must be integrated with hardware units;

11) system qualification tests;

12) software installation.

Thus, the software development process starts from the system where the software will be used and ends again in the system.

After the development stages in the software life cycle, the stage of software operation and maintenance during operation follows. Sometimes a list of stages of the software life cycle is given with some generalizations (enlargements) of the given 12 stages. For example, the stages of system design and determination of software requirements, software package design, software algorithm design, programming (coding), autonomous software debugging, integrated software debugging, software operation.

Neglecting the stages of software design, the desire to immediately start programming without sufficiently elaborating algorithms and issues of interaction of software structural units often leads to a chaotic software development process with little chance of success.

Spiral model of software life cycle. “Heavy and lightweight” (fast) software development technologies

The considered life cycle (LC) model is a cascade type model. This type of life cycle model is good for software for which it is possible to fully and accurately formulate all software requirements at the very beginning of development.

Scheme of a spiral life cycle software. However, the real software creation process does not always fit into such a rigid scheme and there is often a need to return to previous stages with clarification or revision of the decisions made.

Software, like other complex systems for which the initial requirements are not complete enough, is characterized by an iterative development process. Moreover, for some types of software it is even desirable to move on to the next stage as quickly as possible. At the same time, the shortcomings that are inevitable with such hasty work are eliminated at the next iteration or remain forever.

The main task is to achieve working software as quickly as possible, thereby activating the process of clarifying and supplementing requirements. This is the so-called spiral model of software life cycle.

At each turn of the spiral, a version of the product is created, software requirements are specified, and the work of the next turn is planned. The spiral model of software life cycle reflects the objectively existing process of iterative software development (Fig. 8.2).

It is believed that the spiral scheme of software lifecycle is intended not so much for hasty developers, but for software whose low-quality first versions are acceptable for the functional purpose of the software.

There is a direction of “Fast Technologies” of software development (Agile Software Development), which provides ideological justification for the views associated with the spiral model of life cycle. These technologies are based on four ideas:

The interactive interaction of individuals is more important than formal procedures and tools,

Working software is more important than having documentation for it,

Cooperation with the customer is more important than formal contracts,

Quick response to external changes is more important than strict adherence to plans.

Rice. 8.2 - Scheme of spiral life cycle software

In other words, fast technologies are aimed at replacing formal and labor-intensive documented interaction procedures during development with interactive ones, which is possible with a small project size, selected employee qualities, placing developers and customers “in the same room” and for developing software for non-critical systems.

The correctness of these principles to a certain extent, when software development is carried out by a small number of qualified and dedicated “fans”) for the development of certain types of software, is difficult to dispute. However, Agile technologies, and their ideologists recognize this, are applicable in software projects of a certain class and scale, just like the spiral life cycle model in general, namely where software errors lead to some inconvenience or loss of recoverable funds.

Where malfunctioning software leads to a threat to human life or large material losses, comprehensive, well-thought-out technologies must be used to ensure the reliability of the software product.

With an increase in the scale of a software project and an increase in the number of people participating in it, the need for rigid development technology that makes up a cascade software lifecycle increases. Documentation is needed here, since the loss of any of the developers is possible at any time, it is necessary to formalize inter-program connections, manage software changes, etc. It is not for nothing that the cascade life cycle model is included in software development standards. At the same time, it also allows you to implement an iterative development process due to the stipulated stages in the design of STS and software for them.

For very large software projects (a team of developers of more than 100), development technology is a key factor influencing not only the quality of the software, but also the very possibility of its creation.

“Heavy and lightweight” software development technologies . Developers of many types of software consider the waterfall life cycle model to be too regimented, too documented and heavy, and therefore irrational. There is a direction of “Fast Technologies” (light technologies) of software development (Agile Software Development), which provides ideological justification for these views. These technologies are based on four ideas:

1. interactive interaction of individuals is more important than formal procedures and tools,

2. working software is more important than having documentation for it,

3. cooperation with the customer is more important than formal contracts with him,

4. quick response to external changes is more important than strict adherence to planned plans.

The correctness of these principles, except for the third to a certain extent (software development is carried out by a small number of qualified programmers - “fans” who do not need control and additional motivation) for software development is difficult to dispute. However, Agile technologies, and this is recognized by their ideologists, are applicable in software projects of a certain class and scale, as well as the spiral life cycle model in general, namely where software errors lead to some inconvenience or loss of recoverable funds and where software requirements are constantly changing , since they were poorly defined in advance, and rapid adaptation to these changes is required.

Fast technologies – attempts to reach a compromise between strict development discipline and its complete absence in the name of reducing the flow of papers accompanying development. Fast technologies cannot ensure high reliability of a software product precisely because of the minimization of papers that legally confirm the responsibility of the developer.

An example of Agile technologies is Extreme Programming (XP). Iterations in XP are very short and consist of four operations: coding, testing, listening to the customer, designing. The principles of XP - minimalism, simplicity, customer participation, short cycle, close interaction between developers - they should sit in the same room, daily operational meetings with the customer seem reasonable and have long been used not only in fast technologies, but in XP they are taken to extreme values.

An analysis of many software projects has shown that lightweight technologies that preach the principles of self-organization, emphasizing the use of individual abilities of developers, short development iterations in a spiral model, XP, SCRUM are common and often also lead to success, making the most of the features of working in small teams.

Where incorrectly functioning software leads to a threat to human life or to large material losses, orderly, fully thought-out and predictable formalized “heavy” technologies should be used, ensuring the reliability of the software product even in the case of mid-skilled developers. With an increase in the scale of the software project, an increase in the number of participants In this area, the need for a rigid and formal development technology that fixes the responsibility of each development participant that makes up the cascade software life cycle is increasing. It’s not for nothing that the cascade life cycle model is included in software development standards.

In large development teams, the problem of management comes to the fore.

For very large software projects, issues of orderly, coordinated development: structuring, integration, ensuring the correct interaction of programs, organizing the correct and coordinated implementation of inevitable changes are key and influence the very possibility of their creation.

In small software projects, algorithmic refinements and the influence of individual talented individuals play a decisive role, while in large projects these factors are leveled out and do not have a decisive influence on the progress of development.

Software developers with average capabilities, which is the majority, and who maintain technological discipline within the right technology, must develop software of the required quality. “Keep order and he will support you.”

Computer science, cybernetics and programming

Iteration N Unified Software Development Process USDP The 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 dedicated objects. The deployment model describes the distribution of software across computers.

Lesson No. 20
General principles and approaches to software development

Software development models

1. Vodopadnaya
2. Cascade model
3. Spiral
4. Extreme Programming
5. Incremental
6. MSF methodology

Waterfall model

Spiral model

Incremental development

Requirements analysis

Design

Implementation

Component

testing

Integration

Testing

one whole

Iteration 1 Iteration 2…. Iteration N

Unified Software Development Process (USDP)

1. Use case model describes the cases in which the application will be used.
2. The analytical model describes the base classes for the application.
3. The design model describes the connections and relationships between classes and selected objects
4. The deployment model describes the distribution of software across computers.
5. The implementation model describes the internal organization of the program code.
6. A test model consists of test components, test procedures, and various test cases.

MSF methodology

Typical software product architecture components and typical software requirements

fault tolerancea set of system properties that increases its reliability by detecting errors, restoring 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 the ability of the system to withstand various failures and failures.

Refusal this is a system transitionas a result of the error into a completely inoperable state.

Crash 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.

As well as other works that may interest you
57355.		Variety of organic compounds, their classification. Organic substances of living nature	48.5 KB
	The diversity of organic compounds is determined by the unique ability of carbon atoms to connect with each other by simple and multiple bonds to form compounds with an almost unlimited number of atoms connected in chains: cycles, bicycles, tricycles, polycycles, frameworks, etc.
57359.		Processing of verbal information models	291 KB
	Basic concepts: model; information model; verbal information model; annotation; abstract. Synopsis Synopsis from lat. Create a note for 2. Save the document in its own folder under the name Note.
57361.		Number and figure 3. Aligning numbers at boundaries 3. Writing numbers 3. Aligning the number of objects	35.5 KB
	How many creatures are there Who ranks first Who ranks last Who ranks at number 1 Who ranks at number 2 Name the neighbors of the hedgehog. Who is the right-handed squirrel Who is the left-handed giraffe Who is the greatest Who is the least Who stands in the middle of the creatures Gra Show me, don’t have mercy.