Basic approaches to software development. Technological approaches to software development. Economic Theory for Managers

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 received software product.

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

Modern technology Software development 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– Processes life cycle Software" software development process contains the following stages of the software life cycle:

1) analysis system requirements and areas 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 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 life cycle 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 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 should 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.”

Software development models Waterfall Cascading model Spiral Extreme Programming UI Prototyping Incremental W-Model Testing Unified development process software(USDP) MSF Methodology

Waterfall model Requirements analysis Developing a product specification Design Developing a product architecture Implementation Developing source code Integrating individual parts of source code Testing and eliminating defects

Extreme Programming Analysis of initial requirements Design Integration Implementation Testing New requirements Analysis/Approval/modification of development plan Release of product

UI Prototyping Product release Software development taking into account changes Clarification of requirements and specifications Changing the prototype and finalizing some functionality Basic functionality Interface prototype Preliminary specification

Incremental development Iteration 1 Iteration 2…. Requirements analysis Design Implementation Component testing Integration Testing of the 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 allocated objects Ø The deployment model describes the distribution of software across computers. Ø The implementation model describes the internal organization program code. Ø A test model consists of test components, test procedures and various test options.

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

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

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

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

Typical components of a software product architecture and typical software requirements Ø Possibility of implementing the developed architecture. Ø Redundant 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; Ø Ø Ø Does the specification include an overview of the architecture and its rationale. Are the major program components, their responsibilities, and interactions with other components adequately defined? Whether all the functions specified in the requirements specification are implemented by a reasonable number of system components. Is there a description of the most important classes and their rationale? Is a description of the organization of the database provided? Are all business rules defined? Is their impact on the system described?

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

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

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

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

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

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

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

So, the essence 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 into tasks and so on until specific procedures. At the same time, the IS maintains the integrity of the presentation, where all components are interconnected. When developing a system "bottom up", from individual tasks to the entire system, integrity is lost, problems arise when describing information interaction individual components.

The basic principles of the structural approach are:

o principle " divide and rule";

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

The main ones of these principles are:

o abstraction - highlighting the essential aspects of the system;

o consistency - validity and consistency of system elements;

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

Methodological foundations of software creation technologies

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

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

o difficulties of the designed system;

o the necessary completeness of its description;

o knowledge and skills of project participants;

o time allocated for design.

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

CASE technology is a set of software design methods, as well as a set of tools that allow you to visually model subject area, analyze this model at all stages of software development and maintenance and develop applications 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.

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 allocated objects. The deployment model describes the distribution of software across computers.

Lesson No. 20
General principles and approaches to software development

Software development models

Vodopadnaya
Cascade model
Spiral
Extreme Programming
Incremental
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)

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

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 size teams. 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. are designed and created software systems. 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 mathematical modeling: tutorial . 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 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: 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 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. "Dialogue-MEPhI" 2003 "Practice" functional modeling with AllFusion Process Modeler 4.1. (BPwin) Where? For what? How?" publishing "Dialog-MEPhI" 2004 Dubeykovsky modeling with AllFusion Process Modeler (BPwin). publishing "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "Methodology of structural analysis and design SADT" 1993 classic work on SADT methodology. Analysis of systems: IDEF technologies, Modeling and analysis of systems. Workshop M.: Finance and Statistics, 2001. “Structural business models: DFD technologies” http://www. asp? ItemId=5810 "Theory and practice of business process reorganization" 2003/ P50.1.. Methodology of functional modeling. 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.

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 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 They Are Created software systems. Tom DeMarco - Deadline. A novel about project management. Tom De Marco, Timothy Lister - Waltzing with the Bears. Tom DeMarco, 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