Главная Обратная связь

Дисциплины:

Архитектура (936)
Биология (6393)
География (744)
История (25)
Компьютеры (1497)
Кулинария (2184)
Культура (3938)
Литература (5778)
Математика (5918)
Медицина (9278)
Механика (2776)
Образование (13883)
Политика (26404)
Правоведение (321)
Психология (56518)
Религия (1833)
Социология (23400)
Спорт (2350)
Строительство (17942)
Технология (5741)
Транспорт (14634)
Физика (1043)
Философия (440)
Финансы (17336)
Химия (4931)
Экология (6055)
Экономика (9200)
Электроника (7621)






ГОСТ на этапы канонического проектирования



Глава III. Каноническое проектирование и документирование проекта

ГОСТ на этапы канонического проектирования

Каноническое проектирование (см. рис. I-1) это классическое последовательное проектирование, в основе которого лежит каскадная модель (см. Главу IV) жизненного цикла ИС. Оно является образцом проектирования 70-х годов прошлого века, когда проектирование ПО стало жёстко регламентироваться. Все его аспекты детально стандартизированы.

Процесс проектирования ПО в соответствии с применяемым в нашей стране ГОСТ 19.102-77 содержит стадии разработки (см.Таблица III‑1)

Таблица III‑1 Стадии разработки по ГОСТ 19.102-77

Стадии разработки Этапы работ Содержание работ
1. Техническое задание Обоснование необходимости разработки программы Постановка задачи Сбор исходных материалов Выбор и обоснование критериев эффективности и качества разрабатываемой программы. Обоснование необходимости проведения научно-исследовательских работ.
Научно-исследовательские работы Определение структуры входных и выходных данных. Предварительный выбор методов решения задач. Обоснование целесообразности применения ранее разработанных программ. Определение требований к техническим средствам. Обоснование принципиальной возможности решения поставленной задачи
Разработка и утверждение технического задания Определение требований к программе. Разработка технико-экономического обоснования разработки программы. Определение стадий, этапов и сроков разработки программы и документации на неё. Выбор языков программирования. Определение необходимости проведения научно-исследовательских работ на последующих стадиях. Согласование и утверждение технического задания.
2. Эскизный проект Разработка эскизного проекта Предварительная разработка структуры входных и выходных данных. Уточнение методов решения задачи. Разработка общего описания алгоритма решения задачи Разработка технико-экономического обоснования.
Утверждение эскизного проекта Разработка пояснительной записки. Согласование и утверждение эскизного проекта.
3. Технический проект Разработка технического проекта Уточнение структуры входных и выходных данных. Разработка алгоритма решения задачи. Определение формы представления входных и выходных данных. Определение семантики и синтаксиса языка. Разработка структуры программы. Окончательное определение конфигурации технических средств.
Утверждение технического проекта Разработка плана мероприятий по разработке и внедрению программ. Разработка пояснительной записки. Согласование и утверждение технического проекта.
4. Рабочий проект Разработка программы Программирование и отладка программы.
Разработка программной документации Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77.
Испытания программы Разработка, согласование и утверждение порядка и методики испытаний. Проведение предварительных государственных, межведомственных, приёмо-сдаточных и других видов испытаний. Корректировка программы и программной документации по результатам испытаний.
5. Внедрение Подготовка и передача программы. Подготовка и передача программы и программной документации для сопровождения и (или) изготовления. Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. Передача программы в фонд алгоритмов и программ.

Если сравнить название стадий разработки по ГОСТу (Таблица III‑1) и их названия как этапов жизненного цикла ПО, принятые в современном программировании (рис. I-1), то они не совпадают. Однако весьма просто установить соответствие их по сути работ, которые подразумевает каждый этап (см. Таблица III‑2).



Таблица III‑2 Соответствие стадий разработки и этапов ЖЦ ПО

Название стадии по ГОСТ 19.102-77 Название соответствующего этапа жизненного цикла
Техническое задание Анализ, прогнозирование и планирование
Эскизный проект Разработка архитектуры проекта Проектирование
Технический проект Детальное проектирование
Рабочий проект Кодирование Верификация и аттестация
Внедрение Внедрение

Напомним, что под каноническим проектированием понимается проектирование оригинальное, предполагающее разработку программного обеспечения (ПО) «с нуля» (см. Введение). Каждая стадия разработки ПО документируется. На Рис. III‑1 указана основная документация, которая разрабатывается в процессе выполнения каждого этапа.



Этап анализа и планирования
Техническое задание
Этап проектирования
Технический проект
Этап кодирования
Рабочий проект
Этап внедрения
Акт о внедрении

Рис. III‑1 Этапы разработки ПО и поэтапная документация


Предварительные сведения о каждом этапе жизненного цикла ПО уже рассматривались в главе I. Рассмотрим подробнее первые 2 этапа (анализа и проектирования) и документацию их сопровождающую.

Этап системного анализа

Это начальный этап разработки любого ПО (см. рис. I-2), он состоит из выполнения ряда работ, каждая из которых заканчивается разработкой документа, которые затем обобщаются в итоговом документе – Техническом задании (ТЗ):

a) предпроектные исследования (см. раздел 1.01.1) цель которых исследовать проблему, потребности заказчика, имеющийся рынок программных продуктов. В результате делается вывод о необходимости проведения разработки ПО, или напротив, о нецелесообразности разработки. Эти выводы излагаются в «отчете об осуществимости».

b) сбор и анализ требований (см. раздел 1.01.2) проводится, если на предыдущей стадии был сделан вывод в пользу новой разработки. Это сложный и ответственный этап Он был рассмотрен в пп. 1.01.2. Требования не только собираются с учетом потребностей всех категорий пользователей, но и:

· систематизируются,

· анализируются на полноту и непротиворечивость,

· упорядочиваются в соответствии с приоритетностью (приоритет присваивается каждому требованию),

· идентифицируются,

· регистрируются и

· аттестуются.

Итогом этой работы является спецификация требований, которая с одной стороны составит основу ТЗ (итогового документа системного анализа), а с другой является базой, на которой строятся прогнозы об основных параметрах проекта: размере, трудоемкости, стоимости и длительности.

c) прогнозирование работ – спецификация требований анализируется экспертами, которые, основываясь на собственном опыте и на метрических данных от аналогичных проектах делают прогнозы о величине проекта, о его сложности, о необходимых работах для его проведения. И составляется ТЭО – технико-экономическое обоснование

d) планирование - на основе проведенных предварительных оценок проводится планирование работ и финансовых затрат, весь объем работ разбивается на этапы, для каждого из которых определяются стоимость, трудоемкость и длительность, а также в каком виде должны быть предоставлены результаты его выполнения. В итоге формируется календарный график работ.

В этом списке пункты а) и b) уже рассмотрены подробно в главе 1, поэтому остановимся на прогнозировании и планировании работ. Начнем же со стандарта на составление ТЗ.

Техническое задание

Техническое задание- это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.

Стандарт 19.201-78 устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения. Основные его положения сведены в Таблица III‑3.

Таблица III‑3 Разделы ТЗ на разработку ПО по ГОСТ 19.201-78

Наименование раздела Содержание
-введение;   · наименование, · краткая характеристика области примененияпрограммы или программного изделия и объекта, в котором используют программу или программное изделие.
основания для разработки; · документ(документы), на основании которых ведется разработка; · организация,утвердившая этот документ, и дата его утверждения; · наименование и (или) условное обозначение темы разработки.
- назначение разработки; указано функциональное и эксплуатационное назначение программы или программного изделия.
- требования к программе или программному изделию; · требования к функциональным характеристикам; (требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам ) · требования к надежности; требования к обеспечению надежного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п. · условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала · требования к составу и параметрам технических средств; · требования к информационной и программной совместимости; · требования к маркировке и упаковке; · требования к транспортированию и хранению; · специальные требования.
- требования к программной документации; предварительный состав программной документации и, при необходимости, специальные требования к ней
- технико-экономические показатели; · ориентировочная экономическая эффективность, · предполагаемая годовая потребность, · экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
- стадии и этапы разработки;   · необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), · а также, как правило, сроки разработки и определяют исполнителей
порядок контроля и приемки указаны виды испытаний и общие требования к приемке работы.
в ТЗ допускается включать приложения.  

Техническое задание – это основной документ, определяющий соглашение между разработчиком и заказчиком на разработку ПО. Это единственный документ (кроме акта о приемке проекта), который подписывается как руководством заказчика, так и руководством разработчика. Именно он служит основанием для предъявления претензий в суде. И поэтому следует ответственно относиться к его составлению.

ТЗ читает множество разных людей (см. Ошибка! Источник ссылки не найден.), начиная от высшего руководства компании - заказчика системы и заканчивая рядовым разработчиком системы.

Если проанализировать содержательную часть ТЗ, то можно видеть, что ТЗ базируется на:

ü спецификации требований к ИС

ü технико - экономическом обосновании (ТЭО)

ü плане выполнения работ

Собственно, план работ часто рассматривают как составную часть ТЭО, но рассмотрим их последовательно. Надо сразу оговорить, что и план работ, и ТЭО, входящие в состав ТЗ, весьма приблизительны. Они будут дорабатываться и уточняться в течении всего процесса проектирования.

Для разработки ТЗ надо проделать в полной мере все работы по сбору, анализу и специфицированию требований к разрабатываемой ИС. Методы этих работ были подробно описаны в Главе I. Поэтому рассмотрим подробнее что подразумевается под ТЭО и планированием работ.

 

Рис. III‑2 Востребованность ТЗ

Планирование разработки

Планирование – это составная часть начального этапа работы над проектом. Итогом планирования является график работ и ТЭО. Планирование на стадии создания ТЗ носит весьма приблизительный характер и уточняется на всех дальнейших стадиях разработки. Планирование проекта осложняется одновременным участием многих исполнителей, необходимостью парал­лельного выполнения работ, зависимостью начала многих работ от результатов других. Может возникнуть вопрос зачем детально продумывать все аспекты проекта, если прогнозы, построенные на этапе ТЗ, заведомо неточны (в н екоторых случаях реальные затраты и длительность разработки проекта отличаются от предварительной оценки в 4 раза)? Такой вопрос неправомерен, поскольку без предварительных оценок невозможно заключить договор на разработку с заказчиком, и следовательно, осуществить проект.

Последовательность работ по планированию представлена на рРис.III‑3.

1. Определение целей создания ИС и требований к ней
2. Составление ППР
3. Оценка затрат и длительности всех работ
ТЭО
График работ
4. Определение зависимостей действий

Рис.III‑3 Последовательность работ по планированию на этапе ТЗ


III.02.2. a Пооперационный перечень работ

ППР (пооперационный перечень работ) – это основа планирования. Он необходим и для разработки графика работ и для прогноза размеров стоимости и трудозатрат, т.е. для ТЭО. Обычно он имеет вид многоуровневого списка. Но возможно его составление в виде дерева или с помощью простых электронных таблиц.

Пример ППР для проекта по созданию С - компилятора:

1.0 Программное обеспечение для С – компилятора (определение инструментальной среды для разработки, в которой будет создаваться С - компилятор);

1.1 Создание С – компилятора

1.1.1 Построение пользовательского интерфейса

1.1.2 Построение файловой системы

1.1.3 Построение лексического анализатора

1.1.4 Создание интерфейса кода

1.2 Построение тестовой оболочки для компилятора

1.2.1 Прочее

1.3 Написание документации

1.4 Создание инсталляционной программы

1.5 Управление разработкой ПО (т. е. всем выше перечисленным)

Т.е. ППР – отражает иерархию работ, но НЕ их параметры и НЕ зависимость друг от друга. Получив ППР, надо провести оценку работ, а именно, выяснить размер, длительность, стоимость, необходимые для их выполнения ресурсы. Оценка производится обычно «снизу – вверх», т.е. все перечисленные параметры выявляются для нижнего уровня иерархии и суммируются при переходе на более высокие уровни. Особенностью проекта по созданию ИС в том, что основные ресурсы это разработчики (программисты). Конечно, есть потребность и в других ресурсах, например, в АО и ПО, которые используются в проекте. Проведение оценок основных количественных параметров проекта будет кратко рассмотрено в разделе Ошибка! Источник ссылки не найден..

Параллельно с проведением оценок можно исследовать зависимость действий,

III.02.2. b Типы зависимостей

Перечень это иерархический список работ, или действий, которые необходимо проделать в рамках проекта. Если эти действия выполнять строго последовательно, то длительность проекта будет максимально большой. Если выполнять их параллельно, то она будет минимальна. Параллельное выполнение идеально подходит для тех работ, которые никак не зависят друг от друга. Но оно возможно далеко не для всех работ. Потому что между работами (или действиями) существуют зависимости. Прежде, чем строить график работ надо определить типы зависимостей между ними.

Зависимости можно классифицировать на управляемые ресурсами и на управляемые действиями. Под ресурсами в случае разработки ПО в основном понимается персонал (команда разработчиков, например).

Часто определенное действие не может быть начато потому, что работник, который должен его выполнять, занят работой над другим действием. Аналогично, часто действие не может быть начато, пока не закончены какие-то другие действия, которые подготавливают условия для начала данного действия. Типы зависимостей проиллюстрированы на Рис. III4- Ошибка! Источник ссылки не найден.:

Действие А  
Действие Б  
ФС
Действие Б не может выполняться до тех пор, пока не будет завершено действие А

 

Рис. III‑4 Взаимосвязь Финиш- Старт


Рис. III‑5 Взаимосвязь Старт - Старт
Действие А  
Действие Б  
СС
Действие Б запускается при запуске действия А

 

Рис. III‑6 Взаимосвязь Финиш - Финищ
Действие А  
Действие Б  
ФФ
Действие Б Не может быть завершено до тех пор, пока не будет завершено действие А

 

Действие А  
Действие Б  
СФ
Действие Б Не может быть завершено до тех пор, пока не будет запущено действие А  
Рис. III‑7 Взаимосвязь Старт - Финиш

 

Реальные зависимости конечно не так просты. У них могут быть и дополнительные характеристики, например, все перечисленные типы зависимостей могут быть запаздывающими и опе­режающими. На отставание обычно указывает число положительное число, а на опережение — отрицательное. При­мер на Рис. III‑8. демонстрирует действие В, которое выполняется через 10 дней по­сле завершения действия А, а действие Б может начать выпол­няться немедленно:

Рис. III‑8 Запаздывающая взаимосвязь
Действие А  
Действие Б  
ФС
Действие В  
+10

III.02.2. c Рабочий график

Рабочий график является одним из элементов планирования. С его помощью можно избежать неопределенности и продуктивно распределить рабочее время. Обычно рабочий график в процессе работы над про­ектом часто обновляется.

Он строится на базе ППР, диаграмм зависимостей работ и с учётом наличия ресурсов. Наиболее распространены рабочие графики в виде диаграмм Ганта и сетевых диаграмм.

Диаграмма Ганта

Чаще всего для представления графика работ используется диаграмма Ганта, ко­торую еще иногда называют гистограммой. Она была изобретена Генри Гантом во время Первой мировой войны и первоначально использовалась для составления графиков отправки солдат и техники из тыла на побережье США, от­куда они должны были переправляться в Европу.

Фактически этот вид диаграмм хорошо известен даже тем, кто никогда не сталки­вался с разработкой каких-либо проектов.

На простой диаграмме Ганта, представленной на Рис. III‑9, слева перечислены производственные действия (они должны быть отсор­тированы по дате начала или по какому-то др. параметру), а справа — полоски, длина которых соответ­ствует длительности выполнения каждого этапа.

Название задачи Ресурсы
I II III IV I II III IV
Фаза 1 –подготовка 1.1… 1.2… 1.3…                  
Фаза 2 – развитие 2.1… 2.2… 2.3…                  
                 
Фаза N … N.M Завершить проект                  

Рис. III‑9 Диаграмма Ганта

Сетевые диаграммы

Очень распространены методы сетевого планирования и управления. Они основаны на сетевых моделях, допуска­ющих исполь­зование современной вычислительной техники, позволяющих быстро определить последствия различных вари­антов управляющих воздействий и находить наилучшие из них. Существует несколько различных методов построения сетевых диаграмм:

GERT — метод графической оценки и обзора;

PERT — метод программной оценки и обзора;

СРМ — метод критического пути;

PDM — метод предшествования;

ADM — метод стрелочных диаграмм.

Рассмотрим метод СРМ. Он был изобретен в 1950-х годах. Под методом CPM подразумевается общий процесс анализа с использованием сетевых диаграмм. Он наиболее простой, так как в нем предполагается, что фиксирована как продолжительность действий, так и логика определения приоритетов.

В общем виде сетевая диаграмма представляет собой набор узлов и стрелок. В ней содержится следующая информация (см. Рис. III‑10):

ü название действия или идентификатор узла (при этом часто используется код ППР);

ü время наискорейшего начала производственного этапа, которое определяется на основании времени завершения предыдущего действия или какого-либо другого ограничения (например, даты, фиксированной в проекте);

ü время быстрейшего завершения действия;

ü продолжительность этапа (количество временных периодов, необходимых для выполнения работы);

ü максимально возможный срок, когда действие может быть начато, не затронув стадию следующего действия;

ü максимально возможный срок, когда действие может быть завершено, не затронув стадию следующего действия.

(10,20)
(0,10)
А
Время наискорейшего начала и окончания Идентификатор Продолжительность Время наипозднейшего начала и окончания  
Рис. III‑10 Представление узла на сетевой диаграмме

На сетевых диаграммах хорошо прослеживает­ся старшинство узлов. В этом и заключается их основное преимущество. Можно легко проследить порядок следования действий слева направо и увидеть взаимосвязь между различными последовательностями узлов. Подобные диаграммы широко используют­ся при разработке проектных планов "с нуля", когда отсутствует даже шаблон струк­туры ППР.

Недостаток этих диаграмм аналогичен недостатку диаграмм Ганта и других графических представлений: в больших проектах с огромным количеством действий они становятся очень громоздкими и неудобочитаемыми. Тем не менее, сетевые диа­граммы очень удобны на начальном этапе планирования, а также при разработке ППР.

Рис. III‑11 Сетевая диаграмма
(0,10)
А
(10,20)
(20,50)
C
(20,50)
(50,60)
D
(50,60)
(60,80)
F
(60,80)
(80,80)
Fin
(80,80)
(20,50)
(30,60)
(0,20)
B
(0,20)
(0,0)
St
(0,0)
E

 

Прогнозирование

III.02.3. a Количественные характеристики

ТЗ включает в том числе ряд количественных показателей, которые, для проекта, разработка которого еще только предстоит, нельзя измерить, а можно только прогнозировать. Основой для прогноза является опыт экспертов и/или метрические данные об аналогичных проектах, которые уже разработаны.

Основными количественными показателями проекта являются:

1. размер кода (измеряется количестве строк кода LOC – Lines Of Codes);

2. трудозатраты (измеряется в чел/час, чел/месяц, чел/год…);

3. стоимость, т.е. размер необходимого финансирования (в руб., $, э…);

4. длительность работы над проектом (в днях, месяцах, годах..).

Прогнозирование показателей, перечисленных под №№ 2-4 базируется на предполагаемом размере проектируемой ИС. В свою очередь размер ИС оценивается экспертами на основании как опыта собственных разработок, так и метрических данных о уже разработанных ИС. Эти оценки предваряются составлением пооперационного перечня работ (ППР). Эта последовательность прогнозирования основных параметров проекта показана на

Рис. III‑12 Последовательность оценки количественных характеристик проекта
1.Определение целей создания ИС и требований к ней
2. Составление ППР
3. Оценка затрат и длительности всех работ
ТЭО
График работ
4. Определение зависимостей действий

 

 

Итак, размер ПО есть та отправная точка, от которой производятся остальные прогнозы базовых количественных характеристик проекта. Основой прогноза размера являются метрические данные. Метрические данные – это разнообразные сведения о ранее разработанных системах, как минимум, об их размерах, стоимости, трудоемкости, времени разработки.

Желательно сохранять сведения о допущенных при разработке ошибках, а именно на каком этапе ошибка допущена, на каком выявлена, причина её возникновения, стоимость её устранения, время, требуемое на устранение и другие сведения.

Как эксперты, так и разработчики используют метрические сведения и чем большим объёмом таковых они располагают, тем выше будет точность их оценки.

При планировании строительства бруклинского моста точность оценки по стоимости и времени разработки была ±1%. При прогнозировании затрат и времени разработки ПО начальное планирование не может быть точнее более чем в четыре раза. Причина этого в том, что мосты человечество строит не одну тысячу лет, а программирует от силы лет 50, и значит, накопленные метрические данные по строительству мостов несопоставимы с данными о программных продуктах.

Тем не менее оценки производить необходимо, так как без предварительных оценок не будет производиться финансирование работ.

Для повышения точности экспертных оценок можно использовать три оценки, то есть эксперт дает оценку с его точки зрения:

- максимальную

- минимальную

- реальную

Например прогнозируемая оценка:

Так как исходный код может быть в разных языках программирования, то для учета сравнительной сложности работ введена единица SLOC, то есть количество строк в базовом Assembler(e) (см. Таблица III‑4).

При подсчёте LOC используются правила:

  1. строка кода содержит только один оператор;
  2. учитываются все выполняемые операторы;
  3. определение данных учитывается один раз;
  4. не учитывается отладочный (временный) код.

Таблица III‑4 Соответствие LOC и SLOC для разных языков программирования

Язык SLOC (Basic Assembler) Средний показатель SLOC на 1 функциональную точку.
Basic Assembler
С \C++ 1,5\6 320\53
Basic
FORTRAN 105-106
PROLOG
JAVA
Pascal\DELPHI 3,5\11 91\29
Языки 4 поколения
Языки б/д SQL 13-16
EXCEL (языки эл. таблиц)

Зная примерный размер проекта, можно сделать приблизительные оценки его базовых количественных характеристик. В задачу данного пособия не входит подробное рассмотрение моделей для их вычисления. Все они носят эмпирический характер, т.е. получены на базе анализа опыта уже состоявшихся разработок. Для примера рассмотрим оценку трудозатрат:

Трудозатраты = а(размер)в

где a, b – эмпирические константы. Собственно формула не содержит других переменных, кроме «размера кода», что может показаться странным, ведь каждому, имеющему опыт программирования хотя бы в рамках школьного курса информатики, ясно, что создание разных по сложности программ требует разных усилий. Но дело в том, что влияние сложности проекта учтено в значениях констант, т.е. a и b зависят от сложности проекта. Рассмотрим как сложность проекта влияет на вычисляемые значения на примере:

Пример.Для простого проекта размер которого 200 kLOC, а=2.4, b=1.05, и значит:

Трудозатраты =2.4*(200)1.05=2.4*260.66= 626 чел.-мес

Но если проект очень сложный, то для него а=3.6, b=1.2, и значит при том же размере в 200 kLOC имеем:

Трудозатраты = 3.6*(200)1.2= 2077 человеко-месяцев

Т.е. трудозатраты при одном и том же размере проекта возросли в 3,3 раза.

III.02.3. b Технико-экономическое обоснование (ТЭО)

ТЭО есть анализ, расчет, оценка экономической целесообразности осуществления предлагаемого проекта. ТЭО основано на сопоставительной оценке затрат и результатов, установлении эффективности использования, срока окупаемости вложений.

ТЭО содержит расчет стоимости разработки ПО с момента получения первого варианта ТЗ и заканчивая оформлением документации и сдачей проекта.

В ТЭО должна быть обоснована экономическая эффективность разработки.

Кроме этого ТЭО может включать:

ü характеристику исходных данных о предметной области;

ü обоснование цели создания ЭИС;

ü обоснование автоматизируемых подразделений, комплекса автоматизируемых задач, выбора комплекса технических средств, программного и информационного обеспечения;

ü разработка перечня организационно-технических мероприя­тий по проектированию системы;

ü выводы о техническом уровне проекта и возможности даль­нейших разработок.

На этапе разработки ТЗ проводятся предварительные расчеты по ТЭО, которое является одним из раздело ТЗ. Расчеты эти потом уточняются на стадиях эскизного, технического и рабочего проектирования.


Эта страница нарушает авторские права

allrefrs.ru - 2019 год. Все права принадлежат их авторам!