Диаграмма развертывания, размещения (deployment diagram)

 

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

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

Во-вторых, интеграция программной системы с Интернетом определяет необходимость решения дополнительных вопросов при проектировании системы, таких как обеспечение безопасности, криптозащищенности и устойчивости доступа к информации для корпоративных клиентов. Эти аспекты в немалой степени зависят от реализации проекта в форме физически существующих узлов системы, таких как серверы, рабочие станции, брандмауэры, каналы связи и хранилища данных.

Наконец, технологии доступа и манипулирования данными в рамках общей схемы «клиент-сервер» также требуют размещения больших баз данных в различных сегментах корпоративной сети, их резервного копирования, архивирования, кэширования для обеспечения необходимой производительности системы в целом. Эти аспекты также требуют визуального представления с целью спецификации программных и технологических особенностей реализации распределенных архитектур.

Как было отмечено первой из диаграмм физического представления является диаграмма компонентов. Второй формой физического представления программной системы является диаграмма развертывания (синоним – диаграмма размещения). Она применяется для представления общей конфигурации и топологии распределенной программной системы и содержит распределение компонентов по отдельным узлам системы. Кроме того, диаграмма развертывания показывает наличие физических соединений – маршрутов передачи информации между аппаратными устройствами, задействованными в реализации системы.

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

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

Итак, перечислим цели, преследуемые при разработке диаграммы развертывания:

· Определить распределение компонентов системы по ее физическим узлам.

· Показать физические связи между всеми узлами реализации системы на этапе ее исполнения.

· Выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности.

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

Узел

Узел (node) представляет собой некоторый физически существующий элемент системы, обладающий некоторым вычислительным ресурсом. В качестве вычислительного ресурса узла может рассматриваться наличие по меньшей мере некоторого объема электронной или магнитооптической памяти и/или процессора. В последней версии языка UML понятие узла расширено и может включать в себя не только вычислительные устройства (процессоры), но и другие механические или электронные устройства, такие как датчики, принтеры, модемы, цифровые камеры, сканеры и манипуляторы.

Возможность включения людей (персонала) в понятие узла позволяет создавать средствами языка UML модели самых различных систем, включая бизнес-процессы и технические комплексы. Действительно, реализация бизнес-логики предприятия требует рассматривать в качестве узлов системы организационные подразделения, состоящие из персонала. Автоматизация управления техническими комплексами также требует рассмотрения в качестве самостоятельного элемента человека-оператора, способного принимать решения в нештатных ситуациях и нести ответственность за возможные последствия этих решений.

Графически на диаграмме развертывания узел изображается в форме трехмерного куба (строго говоря, псевдотрехмерного прямоугольного параллелепипеда). Узел имеет собственное имя, которое указывается внутри этого графического символа. Сами узлы могут представляться как в качестве типов (рис. 11.1, а), так и в качестве экземпляров (рис. 11.1, б).

Рис. 11.1. Графическое изображение узла на диаграмме развертывания

 

В первом случае имя узла записывается без подчеркивания и начинается с заглавной буквы. Во втором имя узла-экземпляра записывается в виде <имя узла: имя типа узла>. Имя типа узла указывает на некоторую разновидность узлов, присутствующих в модели системы.

Например, аппаратная часть системы может состоять из нескольких персональных компьютеров, каждый из которых соответствует отдельному узлу-экземпляру в модели. Однако все эти узлы-экземпляры относятся к одному типу узлов, а именно узлу с именем типа «Персональный компьютер». Так, на представленном выше рисунке (рис. 11.1, а) узел с именем «Сервер» относится к общему типу и никак не конкретизируется. Второй же узел (рис. 11.1, б) является анонимным узлом-экземпляром конкретной модели принтера.

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

Рис. 11.2. Графическое изображение узла-экземпляра с дополнительной информацией в форме помеченного значения

 

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

Второй способ разрешает показывать на диаграмме развертывания узлы с вложенными изображениями компонентов (рис. 11.3, б). Важно помнить, что в качестве таких вложенных компонентов могут выступать только исполняемые компоненты.

Рис. 11.3. Варианты графического изображения узлов-экземпляров с размещаемыми на них компонентами

 

В качестве дополнения к имени узла могут использоваться различные стереотипы, которые явно специфицируют назначение этого узла. Хотя в языке UML стереотипы для узлов не определены, в литературе встречаются следующие их варианты: «процессор», «датчик», «модем», «сеть», «консоль» и др., которые самостоятельно могут быть определены разработчиком. Более того, на диаграммах развертывания допускаются специальные обозначения для различных физических устройств, графическое изображение которых проясняет назначение или выполняемые устройством функции.

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

 

 

Соединения

Кроме собственно изображений узлов на диаграмме развертывания указываются отношения между ними. В качестве отношений выступают физические соединения между узлами и зависимости между узлами и компонентами, изображения которых тоже могут присутствовать на диаграммах развертывания.

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

Рис. 11.4. Фрагмент диаграммы развертывания с соединениями

 

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

Рис. 11.5. Диаграмма развертывания с отношением зависимости между узлом и развернутыми на нем компонентами

 

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

Рис. 11.6. Диаграмма развертывания для системы удаленного обслуживания клиентов банка

 

На этой диаграмме развертывания указана зависимость компонента реализации диалога «dialog.exe» на удаленном терминале от интерфейса IAuthorise, реализованного компонентом «main.exe», который, в свою очередь, развернут на анонимном узле-экземпляре «Сервер банка». Последний зависит от компонента базы данных «Клиенты банка», который развернут на этом же узле.Примечание указывает на необходимость использования защищенной линии связи для обмена данными в данной системе. Другой вариант записи этой информации заключается в дополнении диаграммы узлом со стереотипом «закрытая сеть».

Разработка так называемых встроенных систем предполагает не только создание программного кода, но и согласование между собой всех аппаратных средств и механических устройств. В качестве примера рассмотрим фрагмент модели управления удаленным механическим средством типа транспортной платформы. Такая платформа предназначена для перемещения в агрессивных средах, где присутствие человека невозможно в силу целого ряда физических причин.Транспортная платформа оснащается собственным микропроцессором, цифровой видеокамерой, датчиками температуры и местоположения, а также управляющими приводами для изменения направления и скорости перемещения платформы. Управляющая и телеметрическая информация от платформы по радиолинии передается в центр управления, оснащенный управляющим компьютером, манипуляторами управления и большим информационным табло.

Рис. 11.7. Диаграмма развертывания для модели системы управления транспортной платформой

 

Как видно из рисунка, при разработке этой диаграммы развертывания использованы дополнительный стереотип «приемопередатчик», который отсутствует в описании языка UML, и специальные изображения для отдельных аппаратных и механических устройств.

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

 

 

Рекомендации по построению диаграммы развертывания

Разработка диаграммы развертывания начинается с идентификации всех аппаратных, механических и других типов устройств, которые необходимы для выполнения системой всех своих функций. В первую очередь специфицируются вычислительные узлы системы, обладающие памятью и/или процессором. При этом используются имеющиеся в языке UML стереотипы, а в случае отсутствия последних, разработчики могут определить новые стереотипы. Отдельные требования к составу аппаратных средств могут быть заданы в форме ограничений, свойств и помеченных значений.

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

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

· Моделирование программных систем, реализующих технологию доступа к данным «клиент-сервер». Для подобных систем характерно четкое разделение полномочий и, соответственно, компонентов между клиентскими рабочими станциями и сервером базы данных. Возможность реализации «тонких» клиентов на простых терминалах или организация доступа к хранилищам данных приводит к необходимости уточнения не только топологии системы, но и ее компонентного состава.

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

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

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

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

Если необходимо включить в модель ресурсы Интернета, то на диаграмме развертывания Интернет обозначается в форме «облачка» с соответствующим именем. Строго говоря, подобное обозначение не специфицировано в языке UML, однако оно часто используется при разработке моделей распределенных систем.

В заключение следует отметить одно немаловажное обстоятельство, характерное для разработки всех канонических диаграмм. Хотя в языке UML определена графическая нотация для всех элементов канонических диаграмм, способы графического изображения отдельных инструментальных средств имеют свои специфические особенности. Применение того или иного инструментального CASE-средства накладывает определенные ограничения на визуализацию моделей программных систем. Речь идет о том, что некоторые элементы языка UML могут вообще отсутствовать в CASE-средствах. Выход из подобной ситуации может быть связан либо с выбором другого инструментария, поддерживающего последние версии языка UML, либо упрощении модели на основе ее типизации.

 

 

Примеры

 

 

 

 

Технический проект

 

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

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

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

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

Прежде всего, следует отметить, что под «Техническим проектом» может пониматься как один сводный документ (чаще для небольших и средних программных систем), так и целый набор (комплект) документации (для крупных систем).

С точки зрения ПО технический проект – это документ или набор документов, являющийся основным результатом процесса проектирования. Процесс проектирования в свою очередь присутствует в том или ином виде абсолютно во всех серьезных методологиях создания ПО, поскольку отражает фундаментальный житейский принцип «прежде чем сделать что-то, необходимо хорошо подумать как это сделать лучше» или короче «сем раз отмерь, один раз отрежь». Технический проект необходим для того, чтобы зафиксировать результаты этого обдумывания даже в случае, если созданием программы занимается всего лишь один человек, не говоря уже о командной разработке.

Технический проект используется разработчиками при программировании спроектированного программного продукта. В его «принципиальной части» он может использоваться при обсуждении и согласовании ключевых проектных решения с Заказчиком. Также технический проект может быть очень полезен другим техническим и не очень техническим специалистам в решении самых разнообразных задач.

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

Исходя из основного требования, в технических проектах обычно решение описывается «сверху вниз» - от самого высокого уровня абстракции до деталей реализации отдельных элементов. Соответственно, в работе над различными частями технического проекта могут принимать участие разные специалисты: системный аналитик, архитектор, ведущий разработчик и т.п.

Несмотря на важность данного документа, у него отсутствует чёткая стандартизированная структура, только общая рекомендация. Это связано в основном с многообразием сфер его применения. Существует стандарт ГОСТ 2.120-2013 Технический проект, описывающий основные аспекты, которые должны быть отражены. В основном он нацелен на промышленность, но затрагивает общие аспекты и поэтому может быть применён и к разработке ПО.

Рассмотрим основные положения этого стандарта

4.1 ТП является проектной стадией разработки конструкторской документации (КД) по ГОСТ 2.103, и его следует разрабатывать в соответствии с ТЗ с целью выявления окончательных технических решений, дающих полное представление об устройстве разрабатываемого изделия, и исходных данных для разработки рабочей КД, когда это целесообразно сделать до разработки рабочей КД. При необходимости ТП может предусматривать разработку вариантов отдельных составных частей (СЧ) изделия. В этих случаях выбор оптимального варианта осуществляется на основании результатов испытаний материальных макетов или анализа электронных макетов.

4.3 При разработке ТП следует выполнять работы, необходимые для обеспечения предъявляемых к изделию требований и позволяющие получить полное представление о конструкции разрабатываемого изделия, оценить его соответствие требованиям ТЗ, технологичности конструкции, степень сложности изготовления, способы упаковки, возможности транспортирования и монтажа на месте эксплуатации, удобство эксплуатации, целесообразность и возможность ремонта и т.п.Перечень необходимых работ определяет разработчик в зависимости от характера и назначения изделия и согласовывает с заказчиком (представительством заказчика), если изделие разрабатывают по заказам Министерства обороны.

4.4 Макеты предназначены для проверки (в необходимых случаях - на объекте заказчика или потребителя) конструктивных и схемных решений разрабатываемого изделия и/или его СЧ, а также для подтверждения окончательно принятых решений. Необходимость изготовления материальных макетов или анализа электронных макетов устанавливает организация-разработчик (если требуется, то совместно с заказчиком).

4.5 Испытания материальных макетов следует проводить в соответствии с программой и методикой испытаний, разработанной по ГОСТ 2.106, анализ электронных макетов - по программе и методике, установленной стандартом организации.

4.6 В ТП могут включаться проектные КД с литерами «Т» в соответствии с ГОСТ 2.102, предусмотренные ТЗ и/или протоколом рассмотрения технического предложения или эскизного проекта. При выполнении КД в электронной форме проекты электронной структуры изделия и электронной модели изделия (сборочной единицы, комплекса, комплекта), следует выполнять по ГОСТ 2.052 и ГОСТ 2.053 соответственно со степенью детализации, характерной для стадии разработки ТП.

4.9 Обозначение проектных КД, включенных в ТП, следует выполнять по ГОСТ 2.201

К выполнению конструкторских документов предъявляются следующие требования.

5.1 Чертеж общего вида изделия или электронной модели изделия следует выполнять по ГОСТ 2.119.

5.2 В ведомость ТП следует записывать все проектные КД, включенные в ТП, в порядке, установленном ГОСТ 2.106.В ТП допускается включать проектные КД в различных формах представления (в бумажной или электронной форме), при этом в графе «Примечание» рекомендуется указывать формупредставления КД.

5.3 Пояснительную записку ТП следует выполнять по ГОСТ 2.106 с учетом следующих основных требований к содержанию разделов:

5.3.1 В разделе «Введение» следует указывать наименование, номер и дату утверждения ТЗ. Если разработка ТП предусмотрена не ТЗ, а протоколом рассмотрения технического предложения или эскизного проекта, то следует делать запись по типу: «Разработка технического проекта предусмотрена эскизным проектом...» и указывают номер и дату протокола рассмотрения эскизного проекта;

5.3.2 В разделе «Назначение и область применения разрабатываемого изделия» следует указывать:

- краткую характеристику области и условий применения изделия;

- общую характеристику объекта, для применения в котором предназначено изделие;

- основные данные, которые должны обеспечивать стабильность показателей качества изделия в условиях эксплуатации;

5.3.3 В разделе «Техническая характеристика» следует приводить:

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

- сведения о соответствии или отклонениях от требований, установленных ТЗ и предыдущими стадиями разработки, если они проводились, с обоснованием отклонений;

5.3.4 В разделе «Описание и обоснование выбранной конструкции» следует приводить:

- описание и обоснование выбранной конструкции, схем, упаковки (если упаковка предусмотрена) и других технических решений, принятых и проверенных на стадии проектирования. При необходимости следует приводить иллюстрации;

- данные сравнения основных характеристик изделия с характеристиками аналогов;

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

- оценку окончательных технических решений на соответствие требованиям по обеспечению патентной чистоты и конкурентоспособности;

- сведения об использованных изобретениях (номера авторских свидетельств или номера заявок на изобретения с указанием даты приоритета);

- результаты испытаний (если они изготовлялись) материальных макетов, электронных макетов и данные оценки соответствия макетов заданным требованиям, в том числе эргономики, технической эстетики. При необходимости следует приводить фотографии материальных макетов;

- сведения о соответствии применяемых в изделии заимствованных (ранее разработанных) СЧ, покупных изделий и материалов разрабатываемому изделию по техническим характеристикам, режимам работы, гарантийным срокам, условиям эксплуатации;

- обоснование необходимости применения дефицитных изделий и материалов;

- сведения о хранении и транспортировании;

- сведения о соответствии изделия требованиям техники безопасности и производственной санитарии;

- сведения о безопасности изделия и воздействии его на окружающую среду;

- сведения по утилизации изделия;

5.3.5 В разделе "Расчеты, подтверждающие работоспособность и надежность конструкции" следует приводить:

- расчеты, подтверждающие работоспособность изделия (кинематические, электрические, тепловые, прочностные, расчеты гидравлических и пневматических систем и др.);

- расчеты, подтверждающие надежность изделия (расчеты показателей долговечности, ремонтопригодности, сохраняемости и др.).

Для каждого вида расчетов следует указывать средства программного и информационного обеспечения автоматизированных систем (в случае их применения для выполнения расчетов). При большом объеме расчетов они могут быть оформлены в виде отдельных КД при этом в данном разделе следует приводить только результаты расчетов;

5.3.6 В разделе «Описание организации работ с применением разрабатываемого изделия» следует приводить сведения об организации работ, с изделием на месте эксплуатации, в том числе:

- описание специфических приемов и способов работы с изделием в режимах и условиях, предусмотренных ТЗ;

- описание порядка и способов хранения, транспортирования и монтажа изделия и ввода его в действие на месте эксплуатации;

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

- сведения о квалификации и количестве обслуживающего персонала;

5.3.7 В разделе «Ожидаемые технико-экономические показатели» следует приводить:

- экономические показатели, необходимые расчеты;

- ориентировочный расчет цены опытного и серийного изделия и затрат на организацию производства и эксплуатацию;

5.3.8 В разделе «Уровень стандартизации и унификации» следует приводить:

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

- обоснование возможности разработки межгосударственных, национальных и стандартов организации на объекты стандартизации, связанные с разработкой данного изделия, его СЧ и новых материалов.

5.4 В приложении к пояснительной записке следует приводить:

- копию ТЗ, а также, при необходимости, данные (технические требования, правила приемки, методы контроля и другие сведения), подлежащие включению в технические условия, если последние на данной стадии не разрабатывались;

- материалы художественно-конструкторской проработки, не являющиеся КД;

- перечень работ, которые следует провести на стадии разработки рабочей КД;

- уточнение или разработку сетевого графика по дальнейшей разработке и внедрению в промышленное производство разрабатываемого изделия;

- перечень использованной литературы и т. п.;

- перечень документов, используемых при разработке ТП и получаемых разработчиком изделия от других организаций (авторские свидетельства, экспертное заключение о патентной чистоте, справки потребителя о необходимом объеме производства разрабатываемых изделий и т.п.);

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

 

Проектирование интерфейса