Software life cycle (SOFTW). Life Cycle and Development Stages by Software Life Cycle

Software development is impossible without understanding the so-called software life cycle. An ordinary user may not need to know this, but it is desirable to learn the basic standards (it will be said later why this is necessary).

What is the life cycle in the formal sense?

Under the life cycle of any, it is customary to understand the time of its existence, starting from the development stage and until the moment of complete abandonment of use in the chosen field of application, up to the complete removal of the application from use.

In simple terms, information systems in the form of programs, databases, or even operating systems are in demand only if the data and the opportunities they provide are relevant.

It is believed that the definition of life cycle does not apply in any way to test applications, such as beta versions, which are the most unstable in operation. The software life cycle itself depends on many factors, among which one of the main roles is played by the environment in which the program will be used. However, one can distinguish General terms used in defining the life cycle concept.

Initial requirements

• formulation of the problem;
• analysis of mutual requirements of future software to the system;
• design;
• programming;
• coding and compilation;
• testing;
• debugging;
• implementation and maintenance of the software product.

Software development consists of all the above-mentioned stages and cannot do without at least one of them. But to control such processes, special standards are established.

Software Life Cycle Process Standards

Among the systems that predetermine the conditions and requirements for such processes, today only three main ones can be named:

• GOST 34.601-90;
• ISO/IEC 12207:2008;
• Oracle CDM.

There is a Russian analogue for the second international standard. This is GOST R ISO / IEC 12207-2010, which is responsible for systems and software engineering. But the life cycle software, described in both rules, is essentially identical. This is explained quite simply.

Types of software and updates

By the way, for most of the currently known multimedia programs, they are the means of saving the main configuration parameters. The use of this type of software is, of course, rather limited, but understanding the general principles of working with the same media players does not hurt. And that's why.

In fact, they have a software life cycle only at the level of the update period for the version of the player itself or the installation of codecs and decoders. And audio and video transcoders are essential attributes of any audio or video system.

Example based on FL Studio

Initially, the virtual studio-sequencer FL Studio was called Fruity Loops. Life cycle The software in its primary modification has expired, but the application has been somewhat transformed and acquired its current form.

If we talk about the stages of the life cycle, at first, at the stage of setting the task, several mandatory conditions were set:

• creating a drum module similar to rhythm machines like the Yamaha RX, but using one-shot samples or WAV sequences recorded live in studios;
• integration into Windows operating systems;
• the ability to export the project in WAV, MP3 and OGG formats;
• project compatibility with the additional application Fruity Tracks.

At the development stage, the tools of the C programming languages ​​were used. But the platform looked rather primitive and did not allow the end user required quality sound.

In this regard, at the stage of testing and debugging, the developers had to follow the path of the German corporation Steinberg and apply Full Duplex mode support in the requirements for the main sound driver. The quality of the sound has become higher and allows you to change the tempo, pitch and apply additional FX effects in real time.

The end of the life cycle of this software is considered to be the release of the first official version of FL Studio, which, unlike its ancestors, already had a full-fledged sequencer interface with the ability to edit parameters on a virtual 64-channel mixing console with unlimited addition of audio tracks and MIDI tracks.

This was not limited. At the project management stage, support was introduced for connecting plug-ins in the VST format (first the second, and then the third version), once developed by Steinberg. Roughly speaking, any virtual synthesizer that supports VST-host could connect to the program.

It is not surprising that soon any composer could use analogues of the "iron" models, for example, the complete sets of sounds of the once popular Korg M1. Further more. The use of modules like Addictive Drums or the universal Kontakt plug-in made it possible to reproduce the live sounds of real instruments recorded with all shades of articulation in professional studios.

At the same time, the developers tried to achieve maximum quality by creating support for ASIO4ALL drivers, which turned out to be head and shoulders above the Full Duplex mode. Accordingly, the bitrate also increased. To date, the quality of the exported audio file can be 320 kbps at a sampling rate of 192 kHz. This is professional sound.

As for the initial version, its life cycle could be called completely finished, but such a statement is relative, since the application has only changed its name and gained new features.

Development prospects

What are the stages of the software life cycle is already clear. But the development of such technologies is worth mentioning separately.

Needless to say, any software developer is not interested in creating a fleeting product that is unlikely to stay on the market for a few years. In the future, everyone is looking at its long-term use. This can be achieved in different ways. But, as a rule, almost all of them come down to the release of updates or new versions of programs.

Even in the case of Windows, such trends can be seen with the naked eye. It is unlikely that today there will be at least one user using systems like modifications 3.1, 95, 98 or Millennium. Their life cycle ended after the release of the XP version. But server versions based on NT technologies are still relevant. Even Windows 2000 today is not only very up-to-date, but even surpasses the latest developments in some installation or security parameters. The same applies to the NT 4.0 system, as well as a specialized modification of Windows Server 2012.

But in relation to these systems, support is still declared at the highest level. But the sensational Vista in its time is clearly experiencing the decline of the cycle. Not only did it turn out to be unfinished, but there were so many errors in itself and gaps in its security system that one can only guess how such an untenable solution could be released to the software market.

But if we talk about the fact that the development of software of any type (control or application) does not stand still, it is only possible. After all, today it concerns not only computer systems, but also mobile devices, in which the technologies used are often ahead of the computer sector. The emergence of processor chips based on eight cores - than not the most best example? But not every laptop can boast of having such a hardware.

Some additional questions

As for the understanding of the software life cycle, it is possible to say that it ended at some specific point in time, it is very conditional, because software products still have support from the developers who created them. Rather, the ending refers to legacy applications that do not meet the requirements of modern systems and cannot work in their environment.

But even taking into account technical progress many of them may soon become untenable. That's when you will have to make a decision either to release updates, or to completely revise the entire concept that was originally incorporated into the software product. Hence the new cycle, which involves changing the initial conditions, the development environment, testing and possible long-term application in a certain area.

But in computer technology Today, preference is given to the development of automated control systems (ACS), which are used in production. Even operating systems, in comparison with specialized programs, lose.

The same Visual Basic-based environments remain much more popular than Windows systems. And we are not talking about application software for UNIX systems at all. What can I say, if almost all communication networks of the same United States work exclusively for them. By the way, systems like Linux and Android were also originally created on this platform. Therefore, most likely, UNIX has much more prospects than other products combined.

Instead of total

It remains to add that in this case only general principles and stages of the software life cycle. In fact, even the initial tasks can differ very significantly. Accordingly, differences can be observed at other stages.

But the basic technologies for developing software products with their subsequent maintenance should be clear. For the rest, one should take into account the specifics of the software being created, the environments in which it is supposed to work, and the capabilities of the programs provided to the end user or production, and much more.

In addition, sometimes life cycles can depend on the relevance of development tools. If, for example, some programming language becomes obsolete, no one will write programs based on it, and even more so - implement them in automated control systems in production. Here, not even programmers, but marketers come to the fore, who must respond in a timely manner to changes in the computer market. And there are not so many such specialists in the world. Highly qualified personnel capable of keeping abreast of the market are becoming the most in demand. And it is they who are often the so-called "gray cardinals", on which the success or failure of a certain software product in the IT field depends.

Although they do not always understand the essence of programming, they are clearly able to determine software life cycle models and the duration of their use, based on global trends in this area. Effective management often produces more tangible results. Yes, at least PR technologies, advertising, etc. The user may not need some application, but if it is actively advertised, the user will install it. This is already, so to speak, a subconscious level (the same effect of the 25th frame, when information is put into the user's mind regardless of himself).

Of course, such technologies are prohibited in the world, but many of us do not even realize that they can still be used and affect the subconscious in a certain way. What is the “zombification” of news channels or Internet sites worth, not to mention the use of more powerful means, such as exposure to infrasound (this was used in one opera production), as a result of which a person may experience fear or inadequate emotions.

Returning to the software, it is worth adding that some programs use a sound signal at startup to attract the user's attention. And studies show that such applications are more viable than other programs. Naturally, the life cycle of the software also increases, no matter what function it was originally assigned to. And this, unfortunately, is used by many developers, which raises doubts about the legality of such methods.

But it is not for us to judge this. It is possible that in the near future tools will be developed to identify such threats. So far, this is only a theory, but, according to some analysts and experts, there is very little left before practical application. If they are already creating copies of the neural networks of the human brain, then what can I say?

Software life cycle

The software life cycle is a period of time that begins from the moment a decision is made on the need to create a software product and ends at the moment of its complete withdrawal from operation. (IEEE Std 610.12)

The need to determine the stages of the software life cycle (LC) is due to the desire of developers to improve the quality of software through optimal development management and the use of various quality control mechanisms at each stage, from task setting to software authoring. The most general representation of the software life cycle is a model in the form of basic stages - processes, which include:

System analysis and justification of software requirements;

Preliminary (sketch) and detailed (technical) software design;

Development of software components, their integration and software debugging in general;

Testing, trial operation and replication of software;

Regular operation of the software, maintenance of operation and analysis of the results;

Maintenance of software, its modification and improvement, creation of new versions.

This model is generally accepted and complies with both domestic regulatory documents in the field of software development and foreign ones. From the point of view of ensuring technological safety, it is advisable to consider in more detail the features of the representation of the stages of the life cycle in foreign models, since it is foreign software that is the most likely carrier of software defects of the sabotage type.

Software Life Cycle Standards

GOST 34.601-90

ISO/IEC 12207:1995 (Russian analogue - GOST R ISO/IEC 12207-99)

Graphical representation of life cycle models allows you to visually highlight their features and some properties of processes.

Initially, a cascade model of the life cycle was created, in which major stages began one after another using the results of previous work. It provides for the sequential implementation of all stages of the project in a strictly fixed order. The transition to the next stage means the complete completion of the work at the previous stage. The requirements defined at the requirements formation stage are strictly documented in the form of terms of reference and fixed for the entire duration of the project development. Each stage culminates in the release of a complete set of documentation sufficient for development to be continued by another development team. The inaccuracy of any requirement or its incorrect interpretation as a result leads to the fact that you have to “roll back” to the early phase of the project and the required revision not only knocks the project team out of schedule, but often leads to a qualitative increase in costs and, it is possible, to the termination of the project in the form in which it was originally conceived. The main fallacy of the authors of the waterfall model is the assumption that the design goes through the whole process once, the designed architecture is good and easy to use, the design of the implementation is reasonable, and errors in the implementation are easily eliminated with testing. This model assumes that all errors will be concentrated in the implementation, and therefore their elimination occurs evenly during component and system testing. Thus, the waterfall model for large projects is not very realistic and can only be effectively used to create small systems.

The most specific is the spiral model of the life cycle. In this model, attention is focused on the iterative process of the initial stages of design. At these stages, concepts, requirements specifications, preliminary and detailed design are sequentially created. At each round, the content of the work is specified and the appearance of the software being created is concentrated, the quality of the results obtained is assessed, and the work of the next iteration is planned. At each iteration, the following are evaluated:

The risk of exceeding the terms and cost of the project;

The need to perform another iteration;

The degree of completeness and accuracy of understanding the requirements for the system;

The expediency of terminating the project.

Standardization of software life cycle is carried out in three directions. The first direction is organized and stimulated by the International Organization for Standardization (ISO - International Standard Organization) and the International Electrotechnical Commission (IEC - International Electro-technical Commission). At this level, standardization of the most common technological processes that are important for international cooperation is carried out. The second direction is being actively developed in the USA by the Institute of Electrical and Electronics Engineers (IEEE - Institute of Electrotechnical and Electronics Engineers) together with the American National Standards Institute (ANSI). The ISO/IEC and ANSI/IEEE standards are mostly advisory in nature. The third direction is stimulated by the US Department of Defense (Department of Defense-DOD). DOD standards are mandatory for firms working on behalf of the US Department of Defense.

To design software for a complex system, especially a real-time system, it is advisable to use a system-wide life cycle model based on the integration of all famous works within the considered basic processes. This model is intended for use in planning, scheduling, managing various software projects.

It is advisable to divide the set of stages of this life cycle model into two parts, which differ significantly in the features of the processes, technical and economic characteristics, and factors influencing them.

In the first part of the life cycle, system analysis, design, development, testing and testing of software is carried out. The range of works, their complexity, duration and other characteristics at these stages depend significantly on the object and development environment. The study of such dependencies for different classes of software makes it possible to predict the composition and main characteristics of work schedules for new versions of software.

The second part of the life cycle, which reflects support for the operation and maintenance of software, is relatively weakly related to the characteristics of the object and development environment. The range of work at these stages is more stable, and their complexity and duration can vary significantly, and depend on the mass application of the software. For any model of life cycle provision High Quality software systems possible only with the use of regulated technological process at each of these stages. Such a process is supported by development automation tools, which it is advisable to choose from existing ones or create taking into account the development object and the list of works adequate to it.

On March 1, 2012, the Federal Agency for Technical Regulation and Metrology of the Russian Federation adopted the GOST R ISO/IEC 12207-2010 standard “Information technology. System and software engineering. Software life cycle processes”, identical to the international standard ISO/IEC 12207:2008 “System and software engineering - Software life cycle processes”.

This standard, using established terminology, establishes overall structure software life cycle processes that can be used as a reference in the software industry. The standard defines the processes, activities and tasks that are used in the acquisition of a software product or service, as well as in the delivery, development, intended use, maintenance and discontinuation of software products.

Software life cycle processes

Standard groups different kinds activities that can be performed during the life cycle of software systems, into seven process groups. Each of the life cycle processes within these groups is described in terms of purpose and desired outputs, lists of actions and tasks to be performed to achieve those results.

• agreement processes - two processes;
• project organizational support processes - five processes;
• project processes - seven processes;
• technical processes - eleven processes;
• software implementation processes - seven processes;
• software support processes - eight processes;
• software reuse processes - three processes.
• Main:
  • Acquisition (actions and tasks of the customer purchasing the software)
  • Delivery (activities and tasks of the supplier who supplies the customer with a software product or service)
  • Development (actions and tasks performed by the developer: creating software, drawing up design and operational documentation, preparing test and training materials, etc.)
  • Operation (actions and tasks of the operator - the organization operating the system)
  • Maintenance (actions and tasks performed by the accompanying organization, that is, the maintenance service). Maintenance - making changes to the software in order to correct errors, improve performance or adapt to changing operating conditions or requirements.
• Auxiliary
  • Documentation (formalized description of information created during the software lifecycle)
  • Configuration management (application of administrative and technical procedures throughout the software life cycle to determine the state of software components, manage its modifications).
  • Quality assurance (ensuring that the IS and the processes of its life cycle comply with the specified requirements and approved plans)
  • Verification (determining that software products, which are the results of some action, fully satisfy the requirements or conditions due to previous actions)
  • Certification (determination of the completeness of compliance of the specified requirements and the created system with their specific functional purpose)
  • Joint assessment (assessment of the state of work on the project: control of planning and management of resources, personnel, equipment, tools)
  • Audit (determination of compliance with the requirements, plans and terms of the contract)
  • Problem resolution (analysis and resolution of problems, regardless of their origin or source, that are discovered during development, operation, maintenance or other processes)
• Organizational
  • Management (activities and tasks that can be performed by any party managing their processes)
  • Creation of infrastructure (selection and maintenance of technology, standards and tools, selection and installation of hardware and software used to develop, operate or maintain software)
  • Improvement (assessment, measurement, control and improvement of life cycle processes)
  • Training (initial training and subsequent ongoing staff development)

Each process includes a number of activities. For example, the acquisition process covers the following steps:

1. Acquisition Initiation
2. Preparation of bids
3. Preparation and adjustment of the contract
4. Supplier oversight
5. Acceptance and completion of works

Each action includes a number of tasks. For example, the preparation of bids should include:

1. Formation of requirements for the system
2. Formation of a list of software products
3. Setting conditions and agreements
4. Description of technical limitations (system operation environment, etc.)

Software life cycle stages, relationship between processes and stages

Software life cycle model- a structure that determines the sequence of execution and the relationship of processes, actions and tasks throughout the life cycle. The life cycle model depends on the specifics, scale and complexity of the project and the specific conditions in which the system is created and operates.

The GOST R ISO/IEC 12207-2010 standard does not offer a specific life cycle model. Its provisions are common to any life cycle models, methods and technologies for creating IP. It describes the structure of life cycle processes without specifying how to implement or perform the activities and tasks included in these processes.

The software lifecycle model includes:

1. stages;
2. The results of the work at each stage;
3. Key events - points of completion of work and decision-making.

Software life cycle. Stages and stages

The IS life cycle is a series of events that occur with the system in the process of its creation and use.

Stage- a part of the software creation process, limited by a certain time frame and ending with the release of a specific product (models, software components, documentation), determined by the requirements specified for this stage.

The life cycle is traditionally modeled as a number of successive stages (or stages, phases). Currently, there is no generally accepted division of the life cycle of a software system into stages. Sometimes a stage is singled out as a separate item, sometimes it is included as an integral part of a larger stage. The actions performed at one stage or another may vary. There is no uniformity in the names of these stages.

Traditionally, the following main stages of the software life cycle are distinguished:

Requirements analysis,

Design,

Coding (programming),

Testing and debugging,

Operation and maintenance.

Software life cycle. Cascade model

cascade model (70-80s) ≈ assumes the transition to the next stage after the completion of work on the previous stage,

The main achievement of the waterfall model is the completeness of the stages. This enables cost and time planning. In addition, project documentation is formed, which has completeness and consistency.

The waterfall model is applicable to small software projects with well-defined and unchanging requirements. The real process can reveal failures at any stage, which leads to a rollback to one of the previous stages. The model of such software production is cascade-return

Software life cycle. Staged model with intermediate control

step-by-step model with intermediate control (80-85) ≈ iterative software development model with cycles feedback between stages. The advantage of this model is that inter-stage adjustments are less labor intensive than the waterfall model; however, the lifetime of each of the stages is stretched over the entire development period,

Main stages of problem solving

The purpose of programming is to describe data processing processes (hereinafter referred to as simply processes).

Data (data) is the presentation of facts and ideas in a formalized form suitable for transfer and processing in some process, and information (information) is the meaning that is given to data when they are presented.

Data processing is the execution of a systematic sequence of actions on data. Data are presented and stored on data carriers.

The set of data carriers used in any data processing is called the information medium (data medium).

The set of data contained at any time in the information environment is the state of the information environment.

A process can be defined as a sequence of successive states of some information environment.

To describe the process means to determine the sequence of states of the information environment. In order for the required process to be generated automatically on some computer according to a given description, this description must be formalized.

Software quality criteria

A commercial product (product, service) must meet the requirements of the consumer.

Quality is an objective characteristic of a product (product, service), showing the degree of consumer satisfaction

Quality characteristics:

› performance- the system works and implements the required functions.

› Reliability– the system works without failures and failures.

› Recoverability.

› Efficiency- the system performs its functions in the best possible way.

› Economic efficiency- the minimum cost of the final product with the maximum profit.

Quality characteristics:

› Accounting human factor - ease of use, speed of learning to work with software, ease of maintenance, making changes.

› Portability(mobility) - portability of code to another platform or system.

› Functional completeness- possibly the most complete implementation external functions.

› Calculation accuracy

Algorithm properties.

Efficiency means the possibility of obtaining a result after performing a finite number of operations.

Certainty consists in the coincidence of the results obtained, regardless of the user and the applied technical means.

mass character lies in the possibility of applying the algorithm to a whole class of tasks of the same type, differing in specific values ​​of the initial data.

discreteness - the possibility of dividing the process of calculations prescribed by the algorithm into separate stages, the possibility of highlighting sections of the program with a certain structure.

Ways to describe algorithms

There are the following ways of describing (representing) algorithms:

1. verbal description;

2. description of the algorithm using mathematical formulas;

3. graphical description of the algorithm in the form of a block diagram;

4. description of the algorithm using pseudocode;

5. a combined method of depicting an algorithm using verbal, graphic, and other methods .

6. using Petri nets.

Verbal description algorithm is a description of the structure of the algorithm in natural language. For example, for devices household appliances, as a rule, an instruction manual is attached, i.e. a verbal description of the algorithm in accordance with which this device should be used.

Graphic description algorithm in the form of a flowchart is a description of the structure of the algorithm using geometric shapes with communication lines.

The block diagram of an algorithm is a graphical representation of a method for solving a problem, which uses special characters to display operations.

The symbols that make up the block diagram of the algorithm are defined by GOST 19.701-90. This GOST complies with the international standard for the design of algorithms, therefore, flowcharts of algorithms, designed in accordance with GOST 19.701-90, in different countries are clearly understood.

Pseudocode– description of the structure of the algorithm in a natural, but partially formalized language. Pseudocode uses some formal constructions and common mathematical symbolism. There are no strict syntax rules for writing pseudocode.

Let's consider the simplest example. Let it be necessary to describe the algorithm for displaying the largest value of two numbers on the monitor screen.

Figure 1 - An example of the description of the algorithm in the form of a block diagram

Description of the same algorithm in pseudocode:

2. Number input: Z, X

3. If Z > X then Conclusion Z

4. Otherwise output X

Each of the above methods of depicting algorithms has both advantages and disadvantages. For example, the verbal method is verbose and lacks clarity, but it makes it possible to better describe individual operations. The graphical method is more visual, but it often becomes necessary to describe some operations in verbal form. Therefore, when developing complex algorithms, it is better to use a combined method.

Types of algorithms

linear;

branching;

cyclic.

· Linear algorithm- a set of commands (instructions) executed sequentially one after another.

· Branching Algorithm- an algorithm containing at least one condition, as a result of checking which the computer provides a transition to one of two possible steps.

· Cyclic algorithm- an algorithm that provides for repeated repetition of the same action (the same operations) on new initial data. Most of the calculation methods and enumeration of options are reduced to cyclic algorithms. Program cycle - a sequence of commands (series, loop body) that can be executed repeatedly (for new initial data) until a certain condition is satisfied.

C. Data types.

A data type is a description of the range of values ​​that a variable of the specified type can take. Each data type is characterized by:
1. the number of bytes occupied (size)
2. the range of values ​​that a variable of this type can take.

All data types can be divided into the following types:
1. simple (scalar) and complex (vector) types;
2. basic (system) and user (defined by the user).
In C language, the basic type system is made up of four data types:
1. symbolic,
2. integer,
3. real single precision,
4. real double precision.

Structure of a C program.

1. Operators of the C++ language

Operators control the execution of a program. The operator set of the C++ language contains all the control constructs of structured programming.
A compound statement is delimited by curly braces. All other statements end with a semicolon.
Empty operator - ;
An empty statement is a statement consisting of only a semicolon. It can appear anywhere in the program where the syntax requires a statement. The execution of an empty statement does not change the state of the program.
Compound operator - (...)
The action of a compound statement is to sequentially execute the statements contained in it, except in those cases when any statement explicitly transfers control to another place in the program.
Exception Handling Operator

try(<операторы> }
catch(<объявление исключения>) { <операторы> }
catch(<объявление исключения>) { <операторы> }
...
catch(<объявление исключения>) { <операторы> }

Conditional operator

if (<выражение>) <оператор 1>

switch operator

switch(<выражение>)
( case<константное выражение 1>: <операторы 1>
case<константное выражение 2>: <операторы 2>
...
case<константное выражение N>: <операторы N>
}
The switch statement is designed to select one of several alternative ways of program execution. The evaluation of a switch statement begins with the evaluation of the expression, after which control is transferred to the operator marked with a constant expression equal to the evaluated value of the expression. The switch statement is exited by the break statement. If the value of the expression is not equal to any constant expression, then control is transferred to the operator marked with the default keyword, if any.
Loop statement with precondition

while (<выражение>) <оператор>

Loop statement with postcondition

do<оператор>while<выражение>;
In C++, this operator differs from the classical implementation of a loop with a postcondition in that when the expression is true, the loop continues, rather than exiting the loop.
Step Loop Operator

for([<начальное выражение>];
[<условное выражение>];
[<выражение приращения>])
<оператор>
The body of the for statement is executed until the conditional expression becomes false (equal to 0). The start expression and increment expression are commonly used to initialize and modify loop parameters and other values. The start expression is evaluated once before the first test of the conditional expression, and the increment expression is evaluated after each execution of the statement. Any of the three loop header expressions, and even all three, can be omitted (just remember to leave the semicolons). If the conditional expression is omitted, then it is considered true, and the loop becomes infinite.
The step-by-step loop operator in the C++ language is a flexible and convenient construction, so the loop operator with the while precondition is used very rarely in the C++ language, because in most cases it is more convenient to use the for statement.
Break operator

break;
The break statement interrupts the execution of while, do, for, and switch statements. It can only be contained in the body of these statements. Control is transferred to the program statement following the interrupted one. If a break statement is written inside nested while, do, for, switch statements, then it only terminates the statement that immediately encloses it.
continuation operator

continue;
The continuation operator transfers control to the next iteration in the while, do, for loop statements. It can only be contained in the body of these statements. In do and while statements, the next iteration begins with the evaluation of the conditional expression. In the for statement, the next iteration starts by evaluating the increment expression, and then the conditional expression is evaluated.
return statement

return [<выражение>];
The return statement terminates the execution of the function that contains it and returns control to the calling function. Control is passed to the point of the calling function

if (boolean expression)

operator;

if (boolean expression)

operator_1;

operator_2;

<логическое выражение> ? <выражение_1> : <выражение_2>;

If the value of the logical expression is true, then expression_1 is evaluated, otherwise expression_2 is evaluated.

switch (integer type expression)

case value_1:

sequence_of_operators_1;

case value_2:

sequence_of_operators_2;

case value_n:

sequence_of_operators_n;

default:

sequence_of_operators_n+1;

branch default may not be described. It is executed if none of the above expressions is satisfied.

loop operator.

Turbo C provides the following constructs for programming loops: while, do while And for . Their structure can be described as follows:

Loop with condition check at the top:

Select statement

If the actions to be performed in the program depend on the value of some variable, a select statement can be used. At the same time, in C++, only numeric variables can be used as variables in a select statement. IN general view The select statement entry looks like this:

switch(variable)
{
case value1:
actions1
break;

case value2:
actions2
break;
...

default:
default actions
}

The break keyword must be added to the end of each branch. It stops the execution of the select operation. If you do not write it, after performing actions from one selection branch, the execution of actions from the following branches will continue. However, sometimes such a selection property is useful, for example, if you need to perform the same actions for different values ​​of a variable.

switch(variable)
{
case value1:
case value2:
actions1
break;

case value3:
actions2
break;
...
}

Sample use of select:

int n, x;
...
switch(n)
{
case 0:
break; //if n is 0, then do nothing

case 1:
case 2:
case 3:
x = 3 * n; //if n is equal to 1, 2 or 3, then perform some actions
break;

case 4:
x=n; //if n is equal to 4, then perform other actions
break;

default:
x = 0; //for all other values ​​of n, perform the default actions
}

C.Cycle: loop with parameter

General form records

for (parameter initialization; end condition check; parameter correction) (

block of operations;

for - parametric loop (loop with a fixed number of repetitions). To organize such a cycle, it is necessary to carry out three operations:

§ parameter initialization- assigning an initial value to the cycle parameter;

§ end condition check- comparison of the parameter value with some boundary value;

§ parameter correction- changing the value of the parameter with each passage of the loop body.

These three operations are written in parentheses and separated by a semicolon (;). As a rule, the loop parameter is an integer variable.
Parameter initialization is done only once - when the for loop starts executing. The termination condition is checked before each possible execution of the loop body. When the expression becomes false (equal to zero), the loop ends. The parameter correction is carried out at the end of each execution of the loop body. The parameter can either increase or decrease.

Example

#include
int main() (

for(num = 1; num< 5; num++)

printf("num = %d\n",num);

Si. Loop with precondition

General notation

while(expression) (

block of operations;
}

If the expression is true (not equal to zero), then the block of operations enclosed in curly braces is executed, then the expression is checked again. The sequence of actions, consisting of checking and executing a block of operations, is repeated until the expression becomes false (equal to zero). In this case, the loop is exited and the operation after the loop statement is executed.

Example

intk=5;
int i=1;
intsum=0;
while(i<=k) {

When constructing a while loop, it is necessary to include constructs that change the value of the expression being checked so that in the end it becomes false (equal to zero). Otherwise, the loop will be executed indefinitely (infinite loop), for example

block of operations;
}

while is a loop with a precondition, so it is quite possible that the body of the loop will not be executed even once if, at the time of the first check, the condition under test is false.

Si. Loop with postcondition

Loop with do...while postcondition

General notation

block of operations;

) while(expression);

Loop with postcondition

The do...while loop is a loop with a postcondition, where the truth of the expression is checked after all the operations included in the block delimited by curly braces have been performed. The loop body is executed until the expression becomes false, that is, the loop body with the postcondition is executed even though would once.

It is better to use the do...while loop in those cases when at least one iteration must be performed, or when the initialization of the objects participating in the condition test occurs inside the loop body.

Example. Enter a number from 0 to 10

#include
#include
int main() (

system("chcp 1251");

printf("Enter a number from 0 to 10: ");

scanf("%d", &num);

) while((num< 0) || (num > 10));

printf("You entered the number %d", num);

getchar(); getchar();

Function definition

Consider the definition of a function using the example of the sum function.

In C and C++, functions do not have to be defined until the moment they are used, but they must be declared earlier. But even after all this, in the end, this function must be defined. After that, the prototype of the function and its definition are linked, and this function can be used.

If a function has been previously declared, it must be defined with the same return value and data types, otherwise a new, overloaded function will be created. Note that function parameter names do not have to be the same.

Topic: Classical and flexible models of LCPP: definition, description, distinctive features, sequence of stages. Methods for choosing a model of the ZhCPP in the development of software in various subject areas.

Information source https://www.intuit.ru/studies/courses/3632/874/print_lecture/14297

Models and stages of software life cycle

The software life cycle model is understood as a structure that determines the sequence of execution and the relationship of processes, actions and tasks throughout the software life cycle. The life cycle model depends on the specifics, scale and complexity of the project and the specific conditions in which the system is created and operates.

The ISO/IEC 12207 standard does not propose a specific life cycle model and software development methods. Its provisions are common to any life cycle models, methods and technologies of software development. The standard describes the structure of the software life cycle processes, but does not specify how to implement or perform the activities and tasks included in these processes.

The life cycle model of any specific software determines the nature of the process of its creation, which is a set of works ordered in time, interconnected and united in stages (phases), the implementation of which is necessary and sufficient to create software that meets the specified requirements.

The stage (phase) of software creation is understood as part of the software creation process, limited by some time frame and ending with the release of a specific product (software models, software components, documentation, etc.), determined by the requirements specified for this stage. The stages of software creation are distinguished for reasons of rational planning and organization of work, ending with the specified results. The software life cycle usually includes the following stages:

1. formation of software requirements;
2. design (development of a system project);
3. implementation (can be broken down into sub-steps: detailed design, coding);
4. testing (can be broken down into stand-alone and complex testing and integration);
5. commissioning (implementation);
6. operation and maintenance;
7. decommissioning.

Some experts introduce an additional initial stage - feasibility study systems. This refers to the software and hardware system for which software is created, purchased or modified.

The stage of formation of software requirements is one of the most important and determines to a large extent (even decisive!) The success of the entire project. The beginning of this stage is to obtain an approved and approved system architecture with the inclusion of basic agreements on the distribution of functions between hardware and software. This document should also contain a confirmation of the general idea of ​​the functioning of the software, including the main agreements on the distribution of functions between the person and the system.

The stage of formation of software requirements includes the following stages.

1. Planning work ahead of the project. The main tasks of the stage are the definition of development goals, preliminary economic evaluation project, building a schedule of work, creating and training a joint working group.
2. Conducting a survey of the activities of an automated organization (object), within the framework of which a preliminary identification of requirements for a future system is carried out, determining the structure of the organization, determining the list of target functions of the organization, analyzing the distribution of functions by departments and employees, identifying functional interactions between departments, information flows within departments and between them , objects external to the organization and external information influences, analysis of existing means of automating the organization's activities.

Building a model of the activity of an organization (object), which provides for the processing of survey materials and the construction of two types of models:

• "AS-IS" ("as is") model, which reflects the current state of affairs in the organization at the time of the survey and allows you to understand how the this organization, as well as identify bottlenecks and formulate proposals for improving the situation;
• "TO-BE" model ("as it should be"), reflecting the idea of ​​new technologies of the organization's work.

Each of the models should include a complete functional and informational model of the organization's activities, as well as (if necessary) a model that describes the dynamics of the organization's behavior. Note that the constructed models are of independent practical importance, regardless of whether the enterprise develops and implements an information system, since they can be used to train employees and improve the business processes of the enterprise.

The result of the completion of the stage of formation of software requirements are software specifications, functional, technical and interface specifications, for which their completeness, verifiability and feasibility are confirmed.

The design stage includes the following steps.

1. Development of a software system project. At this stage, the answer to the question "What should the future system do?" is given, namely: the architecture of the system, its functions, external operating conditions, interfaces and distribution of functions between users and the system, requirements for software and information components, the composition of performers and deadlines are determined. development, software debugging plan and quality control.

   The basis of the system project is the models of the designed system, which are built on the "TO-BE" model. The result of the development of a system project should be an approved and confirmed specification of software requirements: functional, technical and interface specifications, for which their completeness, verifiability and feasibility are confirmed.

2. Development of a detailed (technical) project. At this stage, the actual software design is carried out, including the design of the system architecture and detailed design. Thus, the answer to the question is given: "How to build a system so that it satisfies the requirements?"

The result of detailed design is the development of a verified software specification, including:

• formation of a hierarchy of software components, inter-module interfaces for data and control;
• specification of each software component, name, purpose, assumptions, sizes, call sequence, input and output data, erroneous outputs, algorithms and logic circuits;
• formation of physical and logical data structures up to the level of individual fields;
• development of a plan for the distribution of computing resources (time of central processors, memory, etc.);
• verification of the completeness, consistency, feasibility and validity of the requirements;
• preliminary integration and debugging plan, user guide and acceptance test plan.

The completion of the stage of detailed design is the end-to-end control of the project or critical block analysis of the project.

Implementation stage – execution of the following works.

1. Development of a verified detailed specification for each subroutine (a block of no more than 100 source commands of a high-level language).

   External specifications must contain the following information:

   • module name - the name used to call the module is indicated (for a module with several inputs, there must be separate specifications for each input);
   • function - defines the function or functions performed by the module;
   • list of parameters (number and order) passed to the module;
   • input parameters - an exact description of all data returned by the module (the behavior of the module under any input conditions must be determined);
   • external effects (printing a message, reading a request from the terminal, etc.).
2. Module logic design and module programming (coding).
3. Checking the correctness of the modules.
4. Module testing.
5. Description of the database down to the level of individual parameters, symbols and bits.
6. Acceptance test plan.
7. User guide.
8. Preliminary plan for integration and debugging. The content of the subsequent stages basically coincides with the corresponding processes of the software life cycle. In general, technological stages are distinguished based on considerations of reasonable and rational planning and organization of work. A possible variant of the relationship and stages of work with the software life cycle processes is shown in the figure.

Rice. 1.

Types of software life cycle models

Waterfall model (classic life cycle)

This model owes its appearance to W. Royce (1970). The model has another name - a waterfall (waterfall). The peculiarity of the model is that the transition to the next stage is carried out only after the work at the previous stage is fully completed; Returns to completed stages are not provided.

Rice. 2.

The requirements for the developed PS, determined at the stages of formation and analysis, are strictly documented in the form of TOR and are fixed for the entire duration of the project development. Each stage ends with the release of a complete set of documentation (TOR, EP, TP, RP), sufficient for development to be continued by another development team. The criterion for the quality of development with this approach is the accuracy of fulfilling the specifications of the TOR. The main attention of developers is focused on achieving the optimal values ​​of the technical characteristics of the developed PS - performance, amount of memory occupied, etc.

Advantages waterfall model:

• at each stage, a complete set is formed project documentation, which meets the criteria for completeness and consistency;
• the stages of work performed in a logical sequence allow you to plan the timing of the completion of all work and the corresponding costs.

The cascade approach has proven itself well in building PSs, for which all requirements can be fully and clearly formulated at the very beginning of the project. As long as all this is controlled by standards and various state acceptance commissions, the scheme works well.

Flaws waterfall model:

• identification and elimination of errors is carried out only at the testing stage, which can be significantly extended;
• real projects often require deviation from the standard sequence of steps;
• the cycle is based on the precise formulation initial requirements to the PS, in reality, at the beginning of the project, the requirements of the customer are only partially determined;
• the results of the work are available to the customer only after the completion of the project.

Iterative model of life cycle of PS

With the growth of commercial projects, it became clear that it is not always possible to work out the project of the future system in detail, since many aspects of its functioning in dynamic areas of activity (business) change while the system is being created. It was necessary to change the development process to ensure that the necessary corrections were made after the completion of any stage of development. This is how the iterative model of the life cycle of the PS appeared, called the model with intermediate control or the model with cyclic repetition of phases.

Rice. 3.

In an iterative model, design and programming deficiencies can be eliminated later by partially returning to the previous stage. The lower the error detection rate, the more expensive it is to fix it. If the cost of efforts required to detect and eliminate errors at the stage of writing the code is taken as one, then the cost of identifying and eliminating an error at the stage of developing requirements will be 5-10 times less, and the cost of identifying and eliminating an error at the maintenance stage will be 20 times less. more.

Rice. 4.

In such situation great value acquires the stage of formulating requirements, drawing up specifications and creating a system plan. Software architects are personally responsible for all subsequent changes to design decisions. The volume of documentation amounts to thousands of pages, the number of approval meetings is huge. Many projects never leave the planning stage, falling into analysis paralysis. One possible way to exclude similar situations is prototyping.

Prototyping

Often the customer cannot formulate requirements for input, processing or output of data for a future software product. The developer may doubt the suitability of the product for the operating system, in the form of a dialogue with the user, or the effectiveness of the algorithm. In such cases, it is advisable to use prototyping. The main purpose of prototyping is to remove the uncertainty in the requirements of the customer. Modeling (prototyping) is the process of creating a model of the required product.

The model can take the following forms.

1. Paper mockup (hand-drawn diagram of human-machine dialogue) or PC-based mockup.
2. A working layout that implements some of the required functionality.
3. An existing program whose characteristics need to be improved.

As shown in the figure, prototyping is based on repeated iterations in which the customer and the developer participate.

Rice. 5.

The sequence of actions for prototyping is shown in the figure. Prototyping begins with the collection and specification of requirements for the software system being created. The developer and the customer jointly define the goals of the software, establish which requirements are known and which are to be redefined. Then the rapid design is carried out. It focuses on features that should be visible to the user. Rapid design leads to the construction of a layout. The layout is evaluated by the customer and is used to clarify the software requirements. Iterations continue until the layout reveals all the requirements of the customer and enables the developer to understand what needs to be done.

The advantage of prototyping is the ability to ensure that complete system requirements are defined. Layout Disadvantages:

• the customer can take the layout for the product;
• the developer may mistake the layout for the product.

The shortcomings should be explained. When the customer sees a working version of the PS, he ceases to realize that in the pursuit of a working version of the PS, many quality issues and accompaniment convenience systems. When the developer tells the customer about this, the response may be indignation and a demand for the speedy transformation of the layout into a working product. This negatively affects the management of software development.

Rice. 6.

On the other hand, in order to quickly get a working layout, the developer often makes certain compromises. For example, not the most suitable programming languages ​​or operating system may be used. For a simple demonstration, an inefficient (simple) algorithm may be used. After some time, the developer forgets about the reasons why these tools are not suitable. As a result, a far from ideal selected option is integrated into the system.

Before looking at other software life cycle models that have replaced waterfall model, we should dwell on the strategies for designing software systems. It is the software design strategy that largely determines the software life cycle model.

Software Design Strategies

There are three strategies for constructing software systems:

• single pass (cascade strategy discussed above) - a linear sequence of design steps;
• incremental strategy. At the beginning of the process, all user and system requirements are determined, the rest of the construction is carried out as a series of versions. The first version implements part of the planned features, the next version implements additional features and so on until a complete system is obtained;
• evolutionary strategy. The system is also built as a series of versions, but not all requirements are defined at the beginning of the process. Requirements are specified as a result of development of versions. Characteristics of software design strategies in accordance with the requirements of the IEEE/EIA 12207 standard are shown in Table 1.

incremental model

The incremental model is a classic example of an incremental design strategy. It combines elements of a sequential waterfall model with an iterative layout philosophy (proposed by B. Boehm as an improvement waterfall model). Each line sequence here generates a supplied software increment. For example, word processing software in the 1st increment (version) implements basic file processing, editing and documentation functions; in the 2nd increment - more sophisticated editing and documentation capabilities; in the 3rd increment - spelling and grammar check; in the 4th increment - page layout capabilities.

The first increment results in a base product that implements the basic requirements (however, many auxiliary requirements remain unrealized). The plan for the next increment involves modifying the base product to provide additional features and functionality.

By its nature, the incremental process is iterative, but unlike breadboarding, the incremental model provides a working product at each increment.

A diagram of such a software life cycle model is shown in the figure. One of the modern implementations of the incremental approach is extreme programming (focused on very small increments of functionality).

Rice. 7.

Spiral software life cycle model

spiral model is a classic example of an evolutionary design strategy. The model (author B. Boehm, 1988) is based on the best properties of the classical life cycle and prototyping, to which a new element is added - risk analysis, which is absent in these paradigms. The model defines four activities represented by the four quadrants of the spiral.

Rice. 8.

1. Planning is the definition of goals, options and constraints.
2. Risk analysis – analysis of options and risk recognition/selection.
3. Engineering is the next level of product development.
4. Evaluation - evaluation by the customer of the current design results.

Integrating aspect spiral model is obvious when considering the radial dimension of the helix. With each iteration, more and more full versions PS. In the first turn of the spiral, initial goals, options and constraints are defined, risk is recognized and analyzed. If the risk analysis reveals the uncertainty of the requirements, the prototyping used in the design quadrant comes to the aid of the developer and the customer.

Modeling can be used to further identify problematic and refined requirements. The customer evaluates the engineering (design) work and makes proposals for modifications (customer evaluation quadrant). The next phase of planning and risk analysis is based on customer suggestions. In each cycle through the spiral, the results of the risk analysis are formed in the form of "continue, do not continue." If the risk is too great, the project may be stopped.

In most cases, the spiral continues, with each step pushing developers towards a more general system model. Each loop in the spiral requires a construct (lower right quadrant), which can be implemented by a classic lifecycle or mockup. Note that the number of development activities (occurring in the lower right quadrant) increases as you move away from the center of the spiral.

These actions are numbered and have the following content:

1. – initial requirements gathering and project planning;
2. – the same work, but based on the recommendations of the customer;
3. – risk analysis based on initial requirements;
4. – risk analysis based on customer response;
5. – transition to an integrated system;
6. – initial layout of the system;
7. – next level layout;
8. – designed system;
9. - Evaluation by the client.

Advantages spiral model:

1. most realistically (in the form of evolution) reflects software development;
2. allows you to explicitly take into account the risk at each stage of the development evolution;
3. includes a systematic approach step in the iterative development structure;
4. uses simulation to reduce risk and improve the software product.

Flaws spiral model:

• comparative novelty (there is no sufficient statistics on the effectiveness of the model);
• increased requirements for the customer;
• Difficulties in monitoring and managing development time.

The spiral development process model is the most common at present. Its most famous variants are RUP (Rational Unified Process) from Rational and MSF (Microsoft Solution Framework). UML (Unified Modeling Language) is used as a modeling language. The creation of the system is supposed to be carried out iteratively, moving in a spiral and passing through the same stages, at each turn to refine the characteristics of the future product. It would seem that now everything is fine: only what can be foreseen is planned, what is planned is being developed, and users begin to get acquainted with the product in advance, having the opportunity to make the necessary adjustments.

However, this requires very large funds. Indeed, if earlier it was possible to create and dissolve groups of specialists as needed, now all of them must constantly participate in the project: architects, programmers, testers, instructors, etc. Moreover, the efforts various groups should be synchronized to reflect design decisions in a timely manner and make necessary changes.

Rational Unified Process

Rational unified process(Rational Unified Process, RUP) is one of the best software development methodologies. Based on the experience of many successful software projects, RUP allows you to create complex software systems based on industrial development methods. The prerequisites for the development of RUP originated in the early 1980s. at the Rational Software corporation. In early 2003, Rational acquired IBM. One of the main pillars that RUP relies on is the process of creating models using the Unified Modeling Language (UML).

RUP is one of the spiral software development methodologies. The methodology is maintained and developed by Rational Software. The Common Knowledge Base uses the Unified Modeling Language (UML) as the modeling language. Iterative and incremental software development in RUP involves dividing a project into several projects that are executed sequentially, and each development iteration is clearly defined by a set of goals to be achieved at the end of the iteration. The final iteration assumes that the set of goals of the iteration must exactly match the set of goals specified by the customer of the product, that is, all requirements must be met.

The process involves the evolution of models; an iteration of the development cycle uniquely corresponds to a particular version of the software model. Each of the iterations contains controls software lifecycle: analysis and design (modeling), implementation, integration, testing, implementation. In this sense, RUP is an implementation spiral model, although it is quite often depicted in the form of a graph-table.

This figure shows two dimensions: the horizontal axis represents time and shows the temporal aspects of the process life cycle; the vertical axis represents the disciplines that define the physical structure of the process. You can see how the emphasis in the project changes over time. For example, early iterations spend more time on requirements; in later iterations, more time is devoted to implementation. The horizontal axis is formed from time periods - iterations, each of which is an independent development cycle; the purpose of the cycle is to bring some predetermined tangible refinement to the final product that is useful from the point of view of stakeholders.

Rice. 9.

Along the time axis, the life cycle is divided into four main phases.

1. Start (Inception) - the formation of the concept of the project, an understanding of what we are creating, an idea of ​​​​the product (vision), the development of a business plan (business case), the preparation of a prototype program or a partial solution. This is the phase of collecting information and analyzing requirements, defining the image of the project as a whole. The goal is to get support and funding. In the final iteration, the result of this stage is the terms of reference.
2. Design, development (Elaboration) - clarification of the plan, understanding how we create it, design, planning the necessary actions and resources, detailing the features. The stage ends with an executable architecture, when all architectural decisions are made and risks are taken into account. An executable architecture is running software that demonstrates the implementation of major architectural decisions. In the final iteration, this is a technical project.
3. Implementation, creation of the system (Construction) is the stage of expanding the functionality of the system embedded in the architecture. In the final iteration, this is a working draft.
4. Implementation, deployment (Transition). Creation of the final version of the product. Product implementation phase, delivery of the product to a specific user (replication, delivery and training).

The vertical axis consists of disciplines, each of which can be described in more detail in terms of the tasks performed, the roles responsible for them, the products that are input to the tasks and released during their execution, etc.

Along this axis are the key disciplines of the RUP life cycle, which are often called processes in Russian, although this is not entirely true from the point of view of this methodology, supported by IBM (and / or third-party) tools.

1. Business analysis and modeling ( Business modeling ) provides the implementation of the principles of modeling in order to study the organization's business and accumulate knowledge about it, optimize business processes and make decisions about their partial or complete automation.
2. Requirements management is about taking information from stakeholders and transforming it into a set of requirements that define the content of the system being developed and describe in detail the expectations of what the system should do.
3. Analysis and design (Analysis and design) covers the procedures for transforming requirements into intermediate descriptions (models) representing how these requirements should be implemented.
4. Implementation covers code development, developer-level testing, and integration of components, subsystems, and the entire system in accordance with established specifications.
5. Testing is devoted to assessing the quality of the product being created.
6. Deployment covers the operations that take place in delivering products to customers and making the product available to end users.
7. Configuration management and change management (Configuration management) is dedicated to synchronizing intermediate and final products and managing their development during the project and finding hidden problems.
8. Project Management is dedicated to project planning, risk management, project progress monitoring and continuous evaluation of key indicators.
9. Management environment (Environment) includes elements of the formation of the development environment information system and support for project activities.

Depending on the specifics of the project, any IBM Rational tools, as well as third-party tools, can be used. The RUP recommends following six practices for successful project development: iterative development; requirements management; use of modular architectures; visual modeling; quality checking; change tracking.

An integral part of RUP are artifacts (artefact), precedents ( precedent) and roles (role). Artifacts are some of the products of the project that are generated or used in it when working on the final product. Use cases are sequences of actions performed by the system to produce an observable result. In fact, any result of the work of an individual or a group is an artifact, whether it is an analysis document, a model element, a code file, a test script, a description of an error, etc. Certain specialists are responsible for creating one or another type of artifact. Thus, RUP clearly defines the responsibilities - roles - of each member of the development team at one stage or another, that is, when and who should create this or that artifact. The entire process of developing a software system is considered in RUP as a process of creating artifacts - from initial analysis documents to executable modules, user manuals, and so on.

For computer support of RUP processes, IBM has developed a wide range of tools:

• Rational Rose-CASE- visual modeling tool information systems, which has the ability to generate code elements. A special edition of the product - Rational Rose RealTime - allows you to get an executable module at the output;
• Rational Requisite Pro is a requirements management tool that allows you to create, structure, prioritize, track, control requirements changes that occur at any stage in the development of application components;
• Rational ClearQuest is a change management and bug tracking product that integrates tightly with testing and requirements management tools and provides a single environment for linking all bugs and documents to each other;
• Rational SoDA is a product for automatically generating project documentation that allows you to set a corporate standard for internal company documents. It is also possible to bring the documentation to existing standards (ISO, CMM);
• Rational Purify, Rational Quantify Rational PureCoverage, testing and debugging tools;
• Rational Visual Quantify is a performance measurement tool for C/C++, Visual Basic, and Java developers of applications and components; helps to identify and eliminate bottlenecks in software performance;
• Rational Visual PureCoverage - automatically detects areas of code that are not tested;
• Rational ClearCase is a software configuration management product (Rational's Software Configuration Management, SCM) that allows version control of all project documents. It can be used to maintain multiple versions of projects at the same time, quickly switching between them. Rational Requisite Pro supports updates and tracks changes in the requirements for the development team;
• SQA TeamTest tool test automation;
• Rational TestManager is a test management system that brings together all test-related tools, artifacts, scripts, and data;
• Rational Robot - a tool for creating, modifying and automatically running tests;
• SiteLoad, SiteCheck - tools for testing Web sites for performance and broken links;
• Rational PerformanceStudio - Measure and predict the performance characteristics of systems.

This set of products is constantly being improved and expanded. For example, the recent product IBM Rational Software Architect (RSA) is part of the IBM Software Development Platform, a set of tools that support the software systems development life cycle. The IBM Rational Software Architect product is designed to build models of software systems being developed using the unified modeling language UML 2.0, primarily models of the architecture of the application being developed. However, RSA combines the features of software products such as Rational Application Developer, Rational Web Developer, and Rational Software Modeler, thereby enabling architects and analysts to create various views of the information system under development using the UML 2.0 language, and developers to perform development J2EE, XML, web services, etc.

Following the principles of RUP, Rational Software Architect allows you to create the necessary models within the workflows of disciplines such as:

• business analysis and modeling (Business modeling);
• requirements management (Requirements);
• analysis and design (Analysis and Design);
• implementation (Implementation).

In addition, Rational Software Architect supports model-driven development (MDD) technology, which allows you to model software at various levels of abstraction with traceability.

MSF (Microsoft Solution Framework)

In 1994, in an effort to get the most out of IT projects, Microsoft released a set of guidelines for effectively designing, developing, implementing, and maintaining solutions built on top of its technology. This knowledge is based on the experience gained by Microsoft while working on big projects on software development and maintenance, the experience of Microsoft consultants and the best that the IT industry has accumulated to date. All this is presented in the form of two interrelated and well complementary knowledge areas: Microsoft Solutions Framework (MSF) and Microsoft Operations Framework (MOF).

It should be noted that Microsoft has developed based on common methods MSF methodologies for applied and specialized applications. Moreover, Microsoft certifies experts specifically for applied knowledge in the application of MSF (for example, MCTS 74-131 certification in expertise in project management methodology). Before learning about MSF methods, you must first determine which application of MSF you have in mind.

The most popular application variants of MSF developed by Microsoft are:

• methodology for implementing solutions in the field of project management;
• IT project management methodology based on MSF and Agile methodologies.

The importance of applied variants of MSF is emphasized by the fact that in the "pure version" the MSF methodology itself is not used by Microsoft in its IT projects. Microsoft Consulting Services projects use a hybrid methodology between MSF and Agile. Despite the external significant differences between the applied versions of MSF developed by Microsoft experts, the base of MSF methods for them remains common and reflects common methodological approaches to iterative project management.

MOF is designed to provide organizations building mission-critical IT solutions based on Microsoft products and technologies with technical guidance on how to achieve their reliability, availability, accompaniment convenience(supportability) and manageability (manageability). MOF addresses issues related to the organization of personnel and processes; technologies and management in conditions of complex (complex), distributed (distributed) and heterogeneous (heterogeneous) IT environments. MOF is based on best practices collected in the IT Infrastructure Library (ITIL) compiled by the Central Computer and Telecommunications Agency, a UK government agency.

Creating a business solution within the allotted time and budget requires a proven methodological foundation. MSF provides proven methodologies for planning, designing, developing and implementing successful IT solutions. With its flexibility, scalability and lack of rigid guidelines, MSF is able to meet the needs of any size organization or project team. The MSF methodology consists of principles, models and disciplines for managing personnel, processes, technological elements and issues related to all these factors that are typical for most projects. MSF consists of two models and three disciplines. They are detailed in 5 whitepapers. It is better to start studying MSF with models (project team model, process model), and then move on to disciplines (project management discipline, risk management discipline, training management discipline).

The MSF process model represents a general methodology for the development and implementation of IT solutions. The peculiarity of this model is that, due to its flexibility and the absence of rigidly imposed procedures, it can be applied in the development of a very wide range of IT projects. This model combines the properties of two standard production models: cascade (waterfall) and spiral (spiral). The process model in MSF 3.0 has been further innovative: it covers the entire lifecycle of a solution, from its inception to implementation. This approach helps project teams focus on the business value of the solution, as that value becomes real only after implementation is complete and the product is in use.

The MSF process is focused on "milestones" - the key points of the project, characterizing the achievement within its framework of any significant (intermediate or final) result. This result can be evaluated and analyzed, which means answering the questions: "Did the project team come to an unambiguous understanding of the goals and scope of the project?", "Is the action plan sufficiently prepared?", "Does the product meet the approved specification?", " Does the solution meet the needs of the customer? etc.

The MSF process model takes into account constant change design requirements. It proceeds from the fact that the development of a solution should consist of short cycles that create a progressive movement from the simplest versions of the solution to its final form.

The features of the MSF process model are:

• a phase and milestone approach;
• iterative approach;
• an integrated approach to the creation and implementation of solutions.

The process model includes such main phases of the development process as:

• concept development (Envisioning);
• planning (Planning);
• development (Developing);
• stabilization (Stabilizing);
• implementation (Deploying).

In addition, there are a large number of intermediate milestones that show the achievement of certain progress in the course of the project and break down large segments of work into smaller, observable sections. For each phase of the process model, MSF defines:

• what (what artifacts) is the result of this phase;
• what each of the role clusters is working on in this phase.

Within MSF, code, documentation, designs, plans, and other working materials are usually created in an iterative manner. MSF recommends that you start developing a solution by building, testing, and deploying its core functionality. Then more and more features are added to the solution. This strategy is called a versioning strategy. While a single release may be sufficient for smaller projects, it is recommended that you do not miss the opportunity to create multiple versions for a single solution. With the creation of new versions, the functionality of the solution evolves.

An iterative approach to the development process requires the use of flexible documentation. Living documents should change as the project evolves along with changes in the requirements for the final product. The MSF offers a number of standard document templates that are artifacts of each stage of product development and can be used to plan and control the development process.

A solution has no business value until it is implemented. It is for this reason that the MSF process model contains the entire life cycle of creating a solution, including its implementation, right up to the moment when the solution starts to deliver value.