Настоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Стандарт полностью соответствует СТ СЭВ 1627-79.
Правила оформления
Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.
Лист утверждения и титульный лист
Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.
Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.
Изменения и дополнения
Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
Учесть все детали на начальном этапе разработки невозможно. На практике указанный подход применяется весьма часто. В разделе «Стадии и этапы разработки» следует явно указать возможность внесения изменений и дополнений в техническое задание: «Содержимое разделов настоящего технического задания может быть изменено и дополнено по согласованию с Заказчиком».
Состав разделов технического задания
Техническое задание должно содержать следующие разделы:
- введение; основания для разработки; назначение разработки; требования к программе или программному изделию; требования к программной документации; технико-экономические показатели; стадии и этапы разработки; порядок контроля и приемки; в техническое задание допускается включать приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них. Строго по согласованию с Заказчиком. Согласие Заказчика обязательно должно быть отражено в тексте технического задания.
В качестве учебно-тренировочной будем использовать реальную программу с графическим пользовательским интерфейсом, обеспечивающую возможность выполнения нескольких шаблонных функций (например, несложный текстовый редактор).
Введение
В разделе указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
Основное правило работы с текстом – детализация, дробление текста на структурные единицы, подразделы, пункты и подпункты. Оглавление текста будет иметь четкую структуру, способствующую легкому поиску требуемого материала. Текст документа станет структурированным и удобным для чтения. Создаем подразделы:
Наименование программы
Наименование – «Текстовый редактор для работы с файлами формата rtf».
Краткая характеристика области применения
Программа предназначена к применению в профильных подразделениях на объектах Заказчика.
Содержимое отдельных пунктов не всегда очевидно. При затруднениях следует подходить формально. Правку можно будет внести на этапе согласования технического задания с Заказчиком.
Основания для разработки
В разделе должны быть указаны:
Документ (документы), на основании которых ведется разработка; организация, утвердившая этот документ, и дата его утверждения; наименование и (или) условное обозначение темы разработки.
В подразделе следует привести сведения, содержащиеся в Договоре.
Основание для проведения разработки
Основанием для проведения разработки является Договор (письмо и т. д.) № 000 от 01.01.01 года (входящий № такой-то от такого-то). Договор согласован с Директором ГУП «Спецтяжмонтажстройсельхозавтоматика» Ивановым Петром Ивановичем, именуемым в дальнейшем Заказчиком, и утвержден Генеральным директором Блюмкинсом Иваном Ароновичем, именуемым в дальнейшем Исполнителем, такого-то марта 2008 .
Удобно воспользоваться разделом «Общие сведения» ГОСТ 34.602-89, поскольку разработчик имеет полное право дополнять и удалять разделы технического задания на свое усмотрение. В то же время сведения, указанные выше, содержатся в Договоре. Следует ли приводить их в Техническом задании – зависит от конкретного случая.
Наименование и условное обозначение темы разработки
Наименование темы разработки – «Разработка текстового редактора для работы с файлами формата rtf».
Условное обозначение темы разработки (шифр темы) – «РТФ-007».
Назначение разработки
В разделе должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.
Функциональное назначение
Функциональным назначением программы является предоставление пользователю возможности работы с текстовыми документами в формате rtf.
В подразделе должно быть указано «укрупненное» функциональное назначение программы. Детали – перечень функций и т. д. – будут приведены ниже, в соответствующих разделах.
Получить полный текстЭксплуатационное назначение может трактоваться достаточно широко. Где, как, кем, с чем должна эксплуатироваться программа?
Резина одного типоразмера может успешно эксплуатироваться на Жигулях и Волгах, но не на КаМАЗе. И наоборот. Но для каждого конкретного типоразмера резины можно определить ее эксплуатационное назначение.
Применим формальный подход:
Эксплуатационное назначение
Программа должна эксплуатироваться в профильных подразделениях на объектах Заказчика.
Конечными пользователями программы должны являться сотрудники профильных подразделений объектов Заказчика.
Требования к программе или программному изделию
Раздел должен содержать следующие подразделы:
Требования к функциональным характеристикам; требования к надежности; условия эксплуатации; требования к составу и параметрам технических средств; требования к информационной и программной совместимости; требования к маркировке и упаковке; требования к транспортированию и хранению; специальные требования.
Если существуют стандарты, содержащие общие (технические) требования к программе, системе или изделию, к примеру, «ГОСТ. Автоматизированные информационно-измерительные системы . Общие (технические) требования», разработка технического задания существенно упрощается. Большая часть содержимого указанного стандарта просто переписывается в техническое задание.
Требования к функциональным характеристикам
В подразделе должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. п.
Требования к составу выполняемых функций
Программа должна обеспечивать возможность выполнения перечисленных ниже функций:
1. функции создания нового (пустого) файла.
2. функции открытия (загрузки) существующего файла.
4. функции редактирования текущего файла с применением буфера обмена операционной системы.
5. функции сохранения файла с исходным именем.
6. функции сохранения файла с именем, отличным от исходного.
7. функции отправки содержимого текущего файла электронной почтой с помощью внешней клиентской почтовой программы.
8. функции вывода оперативных справок в строковом формате (подсказок).
9. функции интерактивной справочной системы.
10. функции отображения названия программы, версии программы, копирайта и комментариев разработчика.
Клише «обеспечивать возможность выполнения» применимо к современным программным средствам, разработанным с использованием графического пользовательского интерфейса. Указанные программные средства большей частью «простаивают» (idle), ожидая действий оператора.
Требования к организации входных данных
Входные данные программы должны быть организованы в виде отдельных файлов формата rtf, соответствующих спецификации.
Файлы указанного формата должны размещаться (храниться) на локальных или съемных носителях, отформатированных согласно требованиям операционной системы.
Любой файл иного формата, но с расширением rtf, открываться не должен.
Файлы http:///file. rtf или ftp:///file. rtf открываться не должны. Если файловая система отформатирована как FAT32, файлы с локального или съемного носителя, отформатированного, к примеру, в формате ext3, открываться не должны.
Требования к организации выходных данных
См. Требования к организации входных данных.
Требования те же, что и к организации выходных данных. Тот самый случай, когда следует объединить оба пункта технического задания.
Требования к временным характеристикам
Требования к временным характеристикам программы не предъявляются.
Следует уточнить, предъявляет ли Заказчик требования к быстродействию программы, к примеру, за какое время программа должна стартовать, открывать и закрывать файлы заданного объема. Если Заказчик укажет конкретные цифры, следует подстраховаться и заложить в требованиях к составу и параметрам технических средств суперкомпьютер стоимостью от $2500. Правда, такую сумму придется обосновывать. Если временные характеристики для Заказчика не принципиальны, следует обязательно написать об отказе от требований к временным характеристикам (см. формулировку выше).
Требования к надежности
В подразделе должны быть указаны требования к обеспечению надежного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т. п.).
Надежность – вещь тонкая и очень опасная. Но перечень функций и видов их отказов, согласно п. 1.3.2. ГОСТ 24.701-86, обязан составить Заказчик и согласовать с Исполнителем. Скорее всего, дождаться от Заказчика чего-либо вразумительного не удастся. Стоит разъяснить Заказчику, что надежное функционирование программы зависит не столько от Исполнителя, сколько от надежности технических средств и операционной системы, а также предложить Заказчику ряд жестких мер для повышения надежности и устойчивости функционирования программы.
Получить полный текстТребования к обеспечению надежного (устойчивого) функционирования программы
Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:
Организацией бесперебойного питания технических средств; использованием лицензионного программного обеспечения ; регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 01.01.01 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»; регулярным выполнением требований ГОСТ. Защита инфоpмации. Испытания пpогpаммных сpедств на наличие компьютеpных виpусов.
К списку можно добавить еще десяток нормативных документов. В ходе первичного согласования технического задания Заказчик, скорее всего, начнет проявлять склонность к компромиссу.
Возможен более гуманный подход. Под надежностью (правда, системы, по тому же ГОСТ) можно считать безотказное выполнение некой i-той функции в течение конкретного интервала времени. Предложим Заказчику считать критерием надежной работы программы следующий показатель: Заказчик в течение часа 100 раз открывает и закрывает файл. Если в указанном интервале времени программа не даст сбоев, требования по надежности считаются выполненными.
Если Заказчик, наконец, убедился, что надежность зависит не столько от Исполнителя, сколько от надежности технических средств и операционной системы, и махнул рукой – в разделе обязательно следует написать такую фразу:
Требования к обеспечению надежного (устойчивого) функционирования программы не предъявляются.
Время восстановления после отказа
Время восстановления после отказа, вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы, не должно превышать стольких - то минут при условии соблюдения условий эксплуатации технических и программных средств.
Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств.
Перечень аварийных ситуаций также составляет Заказчик и согласовывает с Исполнителем. Фактически, это время на перезагрузку операционной системы, если отказ не фатален, не вызван крахом операционной системы или выходом из строя технических средств.
Отказы из-за некорректных действий оператора
Отказы программы возможны вследствие некорректных действий оператора (пользователя) при взаимодействии с операционной системой. Во избежание возникновения отказов программы по указанной выше причине следует обеспечить работу конечного пользователя без предоставления ему административных привилегий.
Условия эксплуатации
В подразделе должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т. п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.
Климатические условия эксплуатации
Климатические условия эксплутатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации.
Программа будет прекрасно работать от плюс 5 до плюс 35 °C при относительной влажности 90% и атмосферном давлении 462 мм. рт. ст., поскольку такие условия приблизительно соответствуют условиям эксплуатации современных компьютеров непромышленного исполнения. Но, как только в техническом задании окажется конкретика и задание будет утверждено, Заказчик получает отличный шанс заставить Исполнителя провести климатические испытания в полном объеме за счет Исполнителя.
Требования к видам обслуживания
См. Требования к обеспечению надежного (устойчивого) функционирования программы.
Программа не требует проведения каких-либо видов обслуживания.
Виды обслуживания следует позаимствовать из подраздела «Требования к обеспечению надежного (устойчивого) функционирования».
Если Заказчик в ходе согласования технического задания сошлется на отсутствие ресурсов или желания проводить все виды обслуживания собственными силами, имеет смысл предложить разработку технического задания на сопровождение программного средства за отдельные деньги отдельным договором. Откажется – следует считать программу необслуживаемой.
Требования к численности и квалификации персонала
Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 2 штатных единиц – системный администратор и конечный пользователь программы – оператор.
Системный администратор должен иметь высшее профильное образование и сертификаты компании-производителя операционной системы. В перечень задач, выполняемых системным администратором, должны входить:
Получить полный текст задача поддержания работоспособности технических средств; задачи установки (инсталляции) и поддержания работоспособности системных программных средств – операционной системы; задача установки (инсталляции) программы.Конечный пользователь программы (оператор) должен обладать практическими навыками работы с графическим пользовательским интерфейсом операционной системы.
Персонал должен быть аттестован на II квалификационную группу по электробезопасности (для работы с конторским оборудованием).
При отсутствии самой ключевой (жирной) фразы в утвержденном техническом задании Заказчик вправе затребовать от Исполнителя разработку руководства по эксплуатации графического пользовательского интерфейса операционной системы, мотивируя тем, что оператор «не справляется» с программой.
Персонал, не имеющий II квалификационной группы по электробезопасности, не имеет права даже близко подходить к ПЭВМ и конторскому оборудованию.
Требования к составу и параметрам технических средств
В подразделе указывают необходимый состав технических средств с указанием их основных технических характеристик.
Следует подбирать технику не хуже той, на которой будет производиться разработка. Логично затребовать, чтобы технику предоставил Заказчик не позднее указанного срока. Речь идет, разумеется, о компьютере.
В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:
Процессор Pentium-1000 с тактовой частотой, ГГц - 10, не менее; материнскую плату с FSB, ГГц - 5, не менее; оперативную память объемом, Тб - 10, не менее; и так далее…
Требования к информационной и программной совместимости
В подразделе должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой.
При необходимости должна обеспечиваться защита информации и программ.
Требования к информационным структурам и методам решения
Информационная структура файла должна включать в себя текст, содержащий разметку, предусмотренную спецификацией формата rtf.
Требования к информационным структурам (файлов) на входе и выходе, а также к методам решения не предъявляются.
Требования к исходным кодам и языкам программирования
Исходные коды программы должны быть реализованы на языке C++. В качестве интегрированной среды разработки программы должна быть использована среда Borland C++ Buider.
Требования к программным средствам, используемым программой
Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы. Допускается использование пакета обновления такого-то.
Требования к защите информации и программ
Требования к защите информации и программ не предъявляются.
Подобных требований следует избегать. Обеспечить некоторый уровень защиты информации и программ возможно, обеспечить безопасность невозможно. Заказчик, скорее всего, это осознает и проявлять настойчивость не станет.
Требования к маркировке и упаковке
Программа поставляется в виде программного изделия - на дистрибутивном (внешнем оптическом) носителе (компакт-диске).
Речь идет о маркировке и упаковке дистрибутивного носителя - программного изделия (см. ГОСТ 19.004-80).
Требование к маркировке
Программное изделие должно иметь маркировку с обозначением товарного знака компании-разработчика, типа (наименования), номера версии, порядкового номера, даты изготовления и номера сертификата соответствия Госстандарта России (если таковой имеется).
Маркировка должна быть нанесена на программное изделие в виде наклейки, выполненной полиграфическим способом с учетом требований ГОСТ 9181-74.
Качество маркировки проверяется самыми изощренными способами – сначала пытаются смыть маркировку водой, затем бензином и прочими органическими растворителями. Пусть полиграфическое предприятие несет ответственность за некачественную маркировку. Задача Исполнителя - прикрыться сертификатом соответствия (затребовать сертификат у полиграфистов).
Требования к упаковке
Упаковка программного изделия должна осуществляться в упаковочную тару предприятия-изготовителя.
Именно предприятия-изготовителя. Исполнитель не может и не должен нести ответственность большую, чем предприятие-изготовитель тары.
Условия упаковывания
Упаковка программного изделия должна проводиться в закрытых вентилируемых помещениях при температуре от плюс 15 до плюс 40 °С и относительной влажности не более 80 % при отсутствии агрессивных примесей в окружающей среде.
Заказчик получит программное изделие надлежащего внешнего вида. В случае возврата программного изделия в ненадлежащем виде (наличие царапин, трещин и прочих дефектов) Исполнитель сможет предъявить претензии в части нарушения Заказчиком условий упаковывания и не принять программное изделие.
Порядок упаковки
Подготовленные к упаковке программные изделия укладывают в тару, представляющую собой коробки из картона гофрированного (ГОСТ 7376-89 или ГОСТ 79согласно чертежам предприятия-изготовителя тары.
Получить полный текстПрограммное изделие упаковывается с применением чехлов из водонепроницаемой пленки с обязательным наличием химически неагрессивных влагопоглотителей (силикагеля).
Для заполнения свободного пространства в упаковочную тару укладываются прокладки из гофрированного картона или пенопласта.
Эксплуатационная документация должна быть уложены в потребительскую тару вместе с программным изделием.
На верхний слой прокладочного материала укладывается товаросопроводительная документация - упаковочный лист и ведомость упаковки.
Потребительская тара должна быть оклеена лентой клеевой 6-70 по ГОСТ.
Упакованные в потребительскую тару программные изделия должны быть уложены на поддон, стянуты лентой для предотвращения потери формы груза и упакованы в полиэтиленовую пленку М 0,2 для защиты от попадания влаги.
В коробку поддона должна быть вложена товаросопроводительная документация, в том числе упаковочный лист согласно ГОСТ.
Габариты грузового места должны быть не более 1250 x 820 x 1180 мм.
Масса НЕТТО - не более 200 кг.
Масса БРУТТО - не более 220 кг.
В подразделе приведен порядок упаковки из ранее разработанного документа на какие-то технические средства. Выглядит несколько необычно в контексте программного изделия. Говоря простым русским языком - полнейший стёб.
Требования к транспортированию и хранению
В подразделе должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.
В подразделе приведены условия транспортирования и хранения из ранее разработанного документа на какие-то технические средства. Это касается и требований к порядку упаковки. Выглядит несколько необычно в контексте программного изделия.
Заказчик не вправе нарушать условий транспортирования и хранения. Исполнитель сможет отказать Заказчику в возврате программного изделия, утверждая, что ненадлежащий внешний вид программного изделия является следствием несоблюдения условий транспортирования и хранения.
Условия транспортирования и хранения
Допускается транспортирование программного изделия в транспортной таре всеми видами транспорта (в том числе в отапливаемых герметизированных отсеках самолетов без ограничения расстояний). При перевозке в железнодорожных вагонах вид отправки - мелкий малотоннажный.
При транспортировании и хранении программного изделия должна быть предусмотрена защита от попадания пыли и атмосферных осадков. Не допускается кантование программного изделия. Климатические условия транспортирование приведены ниже:
- температура окружающего воздуха, °С - от плюс 5 до плюс 50; атмосферное давление, кПа - такое-то; относительная влажность воздуха при 25 °С - такая-то.
Специальные требования
Программа должна обеспечивать взаимодействие с пользователем (оператором) посредством графического пользовательского интерфейса, разработанного согласно рекомендациям компании-производителя операционной системы.
Разработчики настоящего стандарта смотрели в будущее. Не существовало в те годы программ с графическим пользовательским интерфейсом.
Требования к программной документации
В разделе должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней.
Состав программной документации предусмотрен ГОСТ 19.101-77.
Предварительный состав программной документации
Состав программной документации должен влючать в себя:
Техническое задание; программу и методики испытаний; руководство системного программиста; руководство оператора; ведомость эксплуатационных документов.
Программа и методики испытаний потребуются, чтобы показать Заказчику, что разработанная Исполнителем программа соответствует требованиям согласованного и утвержденного технического задания. После проведения совместных (приемо-сдаточных) испытаний Заказчик и Исполнитель подпишут Акт приемки (сдачи) работы. И, тем самым, работа будет закрыта, условия Договора выполнены.
Согласно п. 2.6. ГОСТ 19.101-77 «Допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов».
Программная документация, входящая в предварительный перечень, должна быть оформлена согласно требований ГОСТ 19.106-78.
Технико-экономические показатели
Ориентировочная экономическая эффективность не рассчитываются.
Предполагаемое число использования программы в год – 365 сеансов работы на одном рабочем месте.
В разделе должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
Получить полный текстПоложим, Заказчик оснащает программой десяток рабочих мест. Исполнитель потребовал за разработку $1000. Заказчик мог бы установить на рабочие места программный продукт третьей фирмы, стоимостью $500 за дистрибутив и по $100 за лицензию на каждое рабочее место.
Экономические преимущества разработки
Экономические преимущества разработки в сравнении с лучшими отечественными и зарубежными аналогами составит:
число рабочих мест
разработка
экономические преимущества
Стадии и этапы разработки
В разделе устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей.
Стадии разработки и этапы регламентированы ГОСТ 19.102-77. ГОСТ 19.102-77 не препятствует исключению отдельных стадий работ, а также объединению отдельных этапов работ.
Стадии разработки
Разработка должна быть проведена в три стадии:
Разработка технического задания; рабочее проектирование; внедрение.
Этапы разработки
На стадии разработки технического задания должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания.
На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:
Разработка программы; разработка программной документации; испытания программы.
На стадии внедрения должен быть выполнен этап разработки - подготовка и передача программы.
На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:
Постановка задачи; определение и уточнение требований к техническим средствам; определение требований к программе; определение стадий, этапов и сроков разработки программы и документации на неё; выбор языков программирования; согласование и утверждение технического задания.
На этапе разработки программы должна быть выполнена работа по программированию (кодированию) и отладке программы.
На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями ГОСТ 19.101-77 с требованием п. Предварительный состав программной документации настоящего технического задания.
На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:
Разработка, согласование и утверждение программы (в ГОСТ, похоже, опечатка – «порядка») и методики испытаний; проведение приемо-сдаточных испытаний; корректировка программы и программной документации по результатам испытаний.
На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах Заказчика.
Порядок контроля и приемки
В разделе должны быть указаны виды испытаний и общие требования к приемке работы.
Виды испытаний
Приемо-сдаточные испытания должны проводиться на объекте Заказчика в сроки…
Приемо-сдаточные испытания программы должны проводиться согласно разработанной (не позднее такого-то срока) Исполнителем и согласованной Заказчиком Программы и методик испытаний.
Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний.
Общие требования к приемке работы
На основании Протокола проведения испытаний Исполнитель совместно с Заказчиком подписывают Акт приемки-сдачи программы в эксплуатацию.
Приложения
В приложениях к техническому заданию, при необходимости, приводят:
- перечень научно-исследовательских и других работ, обосновывающих разработку; схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке; другие источники разработки.
Если есть, почему не привести. И обязательно выложить перечень ГОСТ, на основании которых должна проводиться разработка. Например:
- ГОСТ 19.201-78. Техническое задание, требования к содержанию и оформлению; и так далее...
Эффективным инструментом проектирования и рационализации организационных структур управления является моделирование, позволяющее находить оптимальные варианты их построения, прогнозировать их развитие, проводить оперативную диагностику состояния действующей структуры и устанавливать ее соответствие реальным производственно-технологическим условиям, оценивать различные варианты построения организационной структуры, когда прямые эксперименты невозможны или затруднительны, а также экономически невыгодны, а иногда невозможны.
На этапе общесистемного проектирования одной из главнейших задач является задача проектирования структуры. Применительно к человеко-машинным системам наиболее распространённым является случай, когда принципы построения системы, выполняемые функции и компоненты системы оказываются заданными. Тогда задача синтеза оптимальной структуры заключается в определении оптимального отображения множества выполняемых функций АС на множество взаимосвязанных элементов.
Программа, с помощью которой реализован данный курсовой проект, предназначена для решения задач следующих видов. Пусть в АС должно решаться i задач (в зависимости от назначения АС это могут быть задачи планирования, учёта, подготовки документов и т.д.). В состав АС входятj элементов (узлов): это могут быть подразделения предприятия, узлы вычислительной сети и т.д. Требуется распределить задачи АС по её элементам в соответствии с выбранными критериями и ограничениями.
При распределении задач АС по её элементам обычно используются следующие критерии оптимизации (целевые функции):
Минимизация общих затрат на решение всех задач;
Минимизация общего времени решения всех задач;
Минимизация максимального времени решения задач (минимизация времени, к которому будет решена последняя задача);
Максимизация общей прибыли от решения всех задач.
При выборе оптимального варианта распределения задач АС по её элементам обычно учитываются следующие ограничения:
На затраты ресурсов (денежных или каких-либо других), связанные с решением всех задач;
На общее время решения всех задач АС;
На загрузку отдельных элементов АС.
Могут использоваться и другие ограничения (например, на затраты ресурсов в отдельных элементах АС, на время решения конкретных задач и т.д.).
1.3 Описание логической структуры программы
Программа состоит из процедур и функций, которые считывают исходные данные, просчитывают возможные варианты распределения задач между узлами в соответствии с ограничением и находят оптимальный вариант. Алгоритм программы показан в виде блок-схемы в приложении 1.
Программа работает следующим образом. После загрузки и запуска программы с помощью файла Project 1. exe , на экране появляется окно «Первая частная задача синтеза оптимальной структуры», которое содержит три однострочных редактора текста для изменения количества узлов и задач, для ввода количества решаемых задач и количества узлов, таблицы для ввода значений затрат времени и денег при решении задач в соответствующих узлах, текстовые кнопки для редактирования условия задачи и поиска решения, основное меню.
Рассмотрим содержимое основного меню, которое состоит из трех пунктов:
В пункт меню Файл включены 4 команды:
Новый -- выбор данного пункта очищает основное окно программы для ввода нового условия.
Открыть – выбор данного пункта позволяет открыть файл отчёта с ранее найденными решениями;
Выход - выбор данного пункта осуществляет выход из программы.
В пункт меню Команды включены 4 команды:
Изменить размерность – изменяет размерностьмасива в соответствии с количеством задач и узлов, введеных пользователем;
Матрица решения - открывает форму с общим решением;
Оптимальное решение – выполняет поиск оптимального решения поставленной задачи, выводя результаты в нижнюю часть основной формы (только в случае полного введения всех значений по заданному условию);
Критерий эффективности - выполняет поиск критерия эффективности, выводя его в основном окне программы.
В пункт меню HELP включены две команды:
Сождержаниеа – открывает окно с руководством по использованию программы и методе решения задачи;
О программе – открывает окно с общей информацией о программе и её разработчиках.
Кнопки управления, расположенные в главном окне, выполняют те же действия, что и соответствующие команды основного меню.
В окне «Первая частная задача синтеза оптимальной структуры» на вкладке «Постановка задачи» пользователь должен ввести следующие исходные данные:
количество задач, которые необходимо распределить между узлами;
количество узлов, между которыми будут распределяться задачи;
значения элементов матрицы затрат времени (затрат денег);
значения элементов матрицы затрат денег (затрат времени);
После ввода всех исходных данных и нажатия кнопки Матрица решений или соответствующего пункта меню, на экране появится второе окно, которое содержит одну кнопку управления:Ok , при нажатии на которую данное окно ответа будет закрыто.
При нажатии кнопки Оптимальное решение в нижней части формы выводиться оптимальное решение.
При нажатии кнопки Критерий эффективности в форме выводиться значение критерия эффективности.
При нажатии кнопки Выход , осуществляется выход из программы.
В завершении проектирования необходимо проследить за работой пользователя при управлении RAID-системой.
Установка RAID . При подключенииRAID-системы к компьютеру и после настройки необходимых драйверов, пользователю необходимо настроить работуRAIDна нужный режим (RAID0,RAID1,RAID3 и др.). После этого готовое для работы дисковое пространство необходимо разбить на нужные тома (разделы). В завершении настройки необходимо протестировать работу всей системы.
Управление/Диагностика RAID . Если пользователю захотелось посмотреть на состояние работы системы либо изменить какие-либо параметры, ПО должно информативно показать состояние работы системы и предоставить удобный интерфейс для изменения настроек системы. При этом как часто бывает, администратор работает с компьютером, на котором установленRAID, удаленно (например, из дома), поэтому ПО должно обеспечивать авторизированный (защищенный) доступ для управления системой по сети.
Обработка ошибок. Система обязана незамедлительно сообщить администратору о возникших ошибках в работеRAID. Так как сам по себеRAID-контроллер не может подать сигнала о неисправности, ПО должно обеспечивать бесперебойный мониторингRAIDна предмет ошибок.
Документация ПО. Система должна быть полностью понятна пользователю. Но несмотря на это, при возникших трудностях пользователь должен быстро найти необходимую документацию как о работе ПО, так и о устройствеRAIDи режимах его работы.
Конструкторская часть
Требования к системе
Исходя из поставленной задачи и проведенных предварительных НИР были сформулированы требования к разрабатываемой системе.
Состав выполняемых функций
Создаваемый программный продукт должен обеспечить выполнение следующих функциональных действий:
Начальная установка только что приобретенной RAID-системы;
Ежедневный мониторинг состояния RAID-системы;
Изменение конфигурации существующей системы (менеджер дисков, управление дисковым пространством, настройки RAID-контроллера);
Возможность удаленно с другого компьютера производить управление системой;
Нотификация администратора о неисправностях и сбоях в работе RAID-системы.
Требования к надежности
Так как система должна работать удаленно, должна быть реализована система авторизации и защита от несанкционированного использования системы. Для предотвращения перехвата пароля, передаваемого по сети, все пароли будут храниться в зашифрованном виде.
Условия эксплуатации и требования к составу и параметрам технических средств
При удаленном администрировании RIAD-системой нужно запускать два программных модуля – один на компьютере сRAIDсистемой, другой на компьютере администратора.
Основным требованием для использования системы является необходимость постоянной работы программного модуля запускаемого на компьютере с RAID-системой. Если этот модуль будет остановлен, то без него нельзя будет произвести соединение кRAID-системе и будет невозможным следить за работойRAID(отсылать нотификацию о неисправностях и вести файлы истории работыRAID).
Для связи обоих программных модулей между собой используется протокол TCP/IP. Поэтому для возможности удаленно работать сRAID-системой, необходима настроенная сеть для обоих компьютеров. При администрированииRAID-системы с локального компьютера, подключение к сети не нужно.
В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т.п.
1. Редактор должен работать в многооконном графическом режиме и поддерживать работу как клавиатуры, так и манипулятора типа «мышь».
2. Пользователь, по своему желанию, должен иметь возможность установки масштабного поля для каждого окна.
3. Минимизатор должен обеспечивать нахождение минимального пути с проходом только один раз через каждое ребро каждого многоугольного контура детали в области размещения.
4. Найденный путь должен демонстрироваться на экране в различных режимах.
5. Информация о размещении контуров и сформированном маршруте может быть сохранена в локальной базе данных минимизатора.
6. Должен быть обеспечен графический просмотр базы данных с возможностью удаления из нее или копирования в активное окно указанного размещения с имеющимся маршрутом.
7. Информация о размещении и сформированном маршруте может быть выведена в форме файла геометрической информации следующей структуры: …
8. Перечисление вершин контуров деталей в соответствующем дескрипторе выходного файла должно соответствовать сформированному маршруту резки.
9. Программа должна использовать в качестве входной информации файл геометрической информации, первой деталью которого будет прямоугольник области размещения.
10. Программа должна обеспечивать просмотр выходного файла.
Конец работы -
Эта тема принадлежит разделу:
Технология разработки программного обеспечения
На сайте сайт читайте: "Технология разработки программного обеспечения"...
Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ:
Что будем делать с полученным материалом:
Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:
| Твитнуть |
Все темы данного раздела:
Требования к информационной и программной совместимости
В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам
Соглашение о требованиях
Составление соглашения о требованиях - цель второй части первой лабораторной работы. Также соглашение о требованиях является вторым разделом курсовой работы.
Ниже дается оп
Краткое описание изделия
Описываются кратко и в общих понятиях основные функциональные свойства изделия. Если программное изделие является расширением уже существующего, характеризуются только его новые сво
Результирующие компоненты изделия
В данном разделе приводится таблица, подобная или эквивалентная таблице 2.1. В данном случае использована заранее подготовленная печатная форма, что уменьшает время подготовки инфор
Отклоненные заявки
Если целью является переработка или расширение изделия либо замена изделия с известными ошибками, следует планировать исправление ошибок, обнаруженных на данный момент времени. Поэтому в этом пункт
Исключенные пункты плана
Если имеются какие-либо плановые указания, требующие особых свойств и возможностей программных средств, которые не могут быть обеспечены, если изделие разрабатывается в соответствии с другими требо
Включенные пункты плана
Если необходимость создания изделия обоснована таким документом, как план выпуска изделия, план выпуска серии или описание задачи, то цитируется либо определенное место из каждого документа, либо п
Перечень требований пользователя
Указываются заказчики изделия и поясняется, почему оно им необходимо. В этом разделе указывается также предполагаемый срок использования изделия. Обычно это будет срок службы оборуд
Рассмотренные альтернативы
Кратко описываются альтернативы данной разработки, которые были рассмотрены и отклонены, а также причины отклонения. Если программы должны быть закуплены, поясняется, почему они не
Окупаемость капиталовложений
Определяется прибыль, которую даст создание изделия, в понятиях, соответствующих целевому назначению организации.
Пример. Фирма ABC Services ожидает, что объем сбыта в фина
Системное программное обеспечение
Системное программное обеспечение - это все остальное программное обеспечение, включающее операционные системы, компиляторы, утилиты, пакеты прикладных программ и др. Это программно
Общие характеристики функций
Необходимо рассматривать все изделие как один функциональный модуль, чтобы число подразделов было небольшим. Если невозможно адекватно описать изделие без разбиения его на отдельные функциональные
Внешние ограничения
Перечисляются все ограничения, сфера действия которых шире, чем сфера действия СТ; сюда входят, например, промышленные ограничения или ограничения, касающиеся серии изделий. Может быть разрешено вв
Ограничения на совместимость
Всегда должно рассматриваться несколько аспектов совместимости: исходный язык, машинный язык, форматы данных и сообщений, форматы отчетов, форматы листингов и форматы языка управления заданиями (уп
Программные ограничения
Указывается, если это необходимо, операционная система, с которой должно работать предлагаемое программное изделие, а также другие программные средства, с которыми оно должно стыковаться в процессе
Аппаратные ограничения
Приводится таблица устройств, используемых при работе программного изделия. Для каждого устройства указывается минимальное, номинальное и максимальное требуемое число. Номинальным является оптималь
Результаты работы
Описываются все выходные данные программного изделия или функционального модуля с точки зрения их содержания и назначения - отчеты, файлы, записи, поля данных, сообщения, таблицы, флажки. Должны бы
Процессы обработки
Описываются операции, выполняемые программным изделием, которое при этом рассматривается в целом или по функциональным модулям как черный ящик (или совокупность черных ящиков). Как минимум, устанав
Надежность
Под надежностью программных средств понимается способность к восстановлению нормальной работы при ошибках и сбоях в работе оборудования. Первостепенную важность имеет защита данных пользователя. Сл
Рестарт
Указываются возможности, обеспечивающие сохранение и использование данных при возобновлении работы после аварийного прерывания, например при рестарте из контрольной точки.
Пример 1. Програ
Соответствие требованиям заказчика
Указываются свойства, которые позволяют программному изделию или его выходным данным удовлетворять конкретным требованиям. Перечисляются, если это возможно, модули, которые могут не удовлетворять т
Рабочие характеристики
Приводится основная переменная или основной принцип, по которому должна измеряться эффективность работы программы; указывается соответствующее значение или диапазон значений для этой переменной. Гл
Удобство эксплуатации
Описываются свойства, которые делают взаимодействие «человек - машина» удобным для человека. Примерами являются свободный формат входных данных, диалоговый режим, синтаксическая совместимость, возм
Удобство сопровождения
Описываются меры, гарантирующие идентифицируемость модулей, если этот вопрос не решен с помощью стандарта.
Пример 1. Каждый исходный и объектный модуль будет снабжаться шифром программного
Рестарт интерфейса пользователя
Пример. Состояние системы для всех активных пользователей (в том числе отключенных, но еще обслуживаемых) периодически запоминается на диске (с интервалом, оговариваемым в рамках определения времен
Характеристики интерфейса пользователя
Пример. При допущении, что на вычислительной машине выполняется только ASK и что параметр восстановления характеризуется одной контрольной точкой в 1 минуту, каждая команда должна выполняться или п
Область применимости интерфейса пользователя
Пример. В типичном сеансе с ASK пользователь, не имеющий опыта программирования, подключается к системе с помощью терминала и вступает в диалог, в котором он определяет:
- интересующие его
Алгоритм интерфейса пользователя
Пример. ASK выполняет каждую команду в режиме интерпретации и немедленно; таким образом, накопление команд не разрешается (за исключением команд запоминания, которые будут рассмотрены ниже).
Аппаратные ограничения
Пример. Помимо устройств, нужных для VSOS ILSAM (см. п. 2.4.1, б и в), процессору корректировок потребуются устройства, перечисленные в таблице 2.3.
Таблица 2.3 - Устройств
Внутренние ограничения
Важно определить не только то, каким будет изделие, но также и каким оно не будет. Ограничение - это свойство (или возможность), которое пользователю логично ожидать, но которое по
Справочные документы
Отдельно указывается каждый плановый или технический документ, на который имеется ссылка в СТ. Каждый такой документ должен реально существовать (а не подразумеваться в будущем) и д
Ресурсы, обеспечивающие ввод в действие
Определяются ресурсы, требуемые для установки системы, наряду с ресурсами, описанными в разделе 2.5.3 (здесь имеются в виду машинное время, трудозатраты и необходимая квалификация п
Носители информации
Определяется тип запоминающих устройств для всех распространяемых компонентов программного изделия (например, магнитная лента, характеризуемая количеством дорожек и плотностью запис
Требуемые взаимосвязи
Определяются требования, выдвигаемые данным программным изделием к другим проектам или функциям. Дается краткая характеристика каждого требования и указывается этап, на котором может быть установле
Обеспечиваемые взаимосвязи
По структуре этот раздел аналогичен предыдущему, но содержит требования, налагаемые другими изделиями на данное изделие. Каждому требованию в разделе 2.6.1.2 должно соответствовать требование в раз
Техническая ревизионная комиссия
В каждом СТ следует рекомендовать создание технической ревизионной комиссии (ТРК) с указанием места работы каждого члена комиссии и его фамилии, если это возможно, а также назначени
Уровни испытаний
Испытания программ могут быть организованы в три этапа, проводиться в трех режимах и насчитывать десять категорий (см. раздел 5 «Тестирование»). Эта информация представляется в виде таблицы. Для ка
Эталоны для сравнения
Определяются эталонные системы, относительно которых должно выполняться сравнение. Указываются характеристики данной системы в относительных единицах. Если эталона для сравнения нет
Извещение об изменении календарных сроков
Пример.
Наименование проекта: Разработка изделия ASK
Шифр проекта: C013. Шифр изделия: L301A.
Наименование изделия: ASK
Написание спецификаций
Написание спецификаций - цель первой части второй лабораторной работы. Также спецификации являются третьим разделом курсовой работы.
На этапе определения спецификаций осуще
Общие принципы тестирования
Этап тестирования обычно в финансовых затратах составляет половину расходов на создание системы. Плохо спланированное тестирование приводит к существенному увеличению сроков разрабо
Организация испытаний программных изделий
Под испытаниями понимают не отладку, призванную определить, почему в программе возникает та или иная ошибка и устранить ее причины, а процесс установления самого факта наличия дефек
Виды испытаний программного изделия. Стадии испытаний
В общем случае, испытания проводятся в несколько стадий, разделенных по времени.
К первой стадии относятся испытания класса A, которые проводятся в конце фазы программирова
Режимы испытаний программ
Испытания различаются в зависимости от того, кто их проводит. Основная идея - независимость функции испытаний от функции разработки.
Режим I испытаний подразумевает полный
Категории испытания программного изделия
Стадии испытания указывают на время проведения проверок, а режимы определяют тех, кто проводит. Категории испытаний устанавливают характер и назначение тестов. Продуманное деление и
Технология тестирования, классы эквивалентности
Одним из способов изучения поставленного вопроса является исследование стратегии тестирования, называемой стратегией черного ящика, тестированием с управлением по данным или тестиро
Построение тестов
Процесс построения тестов включает в себя:
1) назначение каждому классу эквивалентности уникального номера;
2) проектирование новых тестов, каждый из которых покры
Общие положения
1.1. Структуру и оформление документа устанавливают в соответствии с ГОСТ 19.105-78.
1.2. Руководство системного программиста должно содержать следующие разделы:
–
Структура программы
Программа «Автоматизированное рабочее место читателя» состоит из следующих компонентов:
1) zcon - приложение, реализующее функции Z39.50-клиента;
2) zgate - CGI-
Установка программы
В настоящем документе для именования файлов используется синтаксис, определенный ISO/IEC 9945-1. В тех операционных системах, которые не поддерживают указанный способ именования файлов в приложения
Проверка программы
Проверка программы осуществляется методом ее выполнения. В связи с тем, что конкретные условия применения программы (адреса Z39.50-серверов, названия баз данных, поддерживаемые точк
Дополнительные возможности
Дополнительной возможностью программы является возможность динамического управления формой представления записей при просмотре их в полном формате («Детальная информация») при помощ
Сообщения системному программисту
В таблице 5.1 представлены сообщения, которые могут получить системный программист в ходе выполнения настройки, проверки программы, а также пользователь в ходе выполнения программы.
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
СЕРДОБСКИЙ ФИЛИАЛ ФЕДЕРАЛЬНОГО ГОСУДАРСТВЕННОГО БЮДЖЕТНОГО ОБРАЗОВАТЕЛЬНОГО УЧРЕЖДЕНИЯ ВЫСШЕГО ОБРАЗОВАНИЯ
«ПЕНЗЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
«Разработка приложения для решения гиперболических уравнений методом сетки в среде Microsoft Visual Studio 2013»
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
К курсовой работе по дисциплине «Технологии разработки программного обеспечения»
Выполнила: студентка гр.13ПКС1
Драницын Е.А.
Принял: преподаватель
Ю.С.Киселёва
Реферат
Пояснительная записка: 22 листа, 7 рисунков, 4 источника, 2 приложения.
Объектом исследования является решение гиперболических уравнений.
Цель работы – разработать программу, которая будет осуществлять решение гиперболических уравнений методом сетки.
В результате проделанной работы разработана программа, позволяющая вычислять решение гиперболических уравнений.
При написании программы использовалась среда программирования Microsoft Visual Studio 2013.
Введение . 5
1 Анализ предметной области . 6
2 Техническое задание . 7
2.1 Основание для разработки . 7
2.2 Назначение разработки . 7
2.3 Требования к программе . 7
2.3.1 Требования к функциональным характеристикам .. 7
2.3.2 Требования к составу и параметрам технических средств . 7
2.3.3 Требования к информационной и программной совместимости . 7
2.4 Требования к программной документации . 7
2.5 Стадии и этапы разработки . 8
2.6 Порядок контроля и приёмки . 8
3 Описание программы .. 9
3.1 Общие сведения . 9
3.2 Функциональное назначение . 9
3.3 Описание логической структуры .. 9
3.4 Используемые технические средства . 10
4.1 Объект испытаний . 11
4.2 Цель испытаний . 11
4.3 Требования к программе . 11
4.4 Требования к программной документации. 11
4.5Средства и порядок испытаний . 12
4.6 Методы испытаний . 12
5 Описание применения . 13
Заключение . 14
Список использованных источников . 15
ТЕКСТ ПРОГРАММЫ ... 16
РЕЗУЛЬТАТЫ ИСПЫТАНИЙ .. 21
Введение
Гиперболическое уравнение – класс дифференциальных уравнений в частных производных. Характеризуются тем, что задача Коши с начальными данными, заданными на не характеристической поверхности, однозначно разрешима. Наиболее известным примером является волновое уравнение. Любое уравнение первого порядка в частных производных также является гиперболическим.
Microsoft Visual Studio – это новая разработка компании Microsoft, позволяющая создавать приложения, работающие на платформе.net. Особенность этой платформы заключается в широком наборе сервисов, которые доступны в различных языках программирования. При этом сервисы реализуются в виде промежуточного кода, который не зависит от базовой архитектуры. Едва ли не главной целью создания такой платформы было оснащение разработчиков специальными сервисно-ориентированными приложениями, которые могли бы работать на любой платформе, начиная от персонального компьютера и заканчивая мобильным устройством.
Microsoft Visual Studio объединяет в себе огромное количество функций, позволяющих осуществлять разработки для Windows всех версий, в том числе и 8, Интернета, SharePoint, различных мобильных устройств и облачных технологий. В Visual Studio реализуется новая среда разработчика, благодаря которой создавать приложения стало проще. Microsoft Visual Studio - это обновленная и упрощенная программная среда, для которой характерна высокая производительность, причем она не зависит от особенностей оборудования. И эта студия наверно неплохо подойдет для разработки приложения.
Анализ предметной области
Предметной областью для данной разработки является решение гиперболических уравнений, а именно – решение методом сеток.
Применяемые на практике методы решения Гиперболических уравнений делятся на две группы – волновые уравнения и различные уравнения, получаемые из уравнений Максвелла. Волновые уравнения – это уравнение описывающие колебания струн, мембран и так далее. Различные уравнения, получаемые из уравнений Максвелла, описывающие электромагнитное поле. Это может быть постановка относительно одного из векторов , считая не нулевой только одну из компонент вектора (то есть когда уравнение становится скалярным).
Описание решения гиперболического уравнения методом сеток: задача состоит в отыскании функции u(x,t) удовлетворяющей данному уравнению (d^2*u/d*t^2)=c^2*(d^2*u/d*x^2) при x1< x < x2, t1 < t <= t2, начальным условиям u(x,0) = f(x), d u(x,0)/ d t = g(x) , x1<= x <= x2 и нулевыми краевыми условиями u(0,t) = u(1,t)=0. Так как замена переменных t ->ct приводит уравнение (1) к виду (d^2*u/d*t^2)=(d^2*u/d*x^2), то в дальнейшем будем считать с = 1. Для построения разностной схемы решения задачи строим в области D={(x,t)| x1<=x<=x2, t1<=t<=t2}, сетку xi = ih, i=0,1... n , a = h * n, tj = j*t t t , j = 0,1 ... , m, t m = T и аппроксимируем уравнение (1) в каждом внутреннем узле сетки.
Техническое задание
Основание для разработки
Программа разрабатывается на основании задания на курсовую работу, выданного преподавателем Киселёвой Ю.С. и утвержденного заведующей учебной частью Золотовой Т.А.
Назначение разработки
Разрабатываемая программа предназначена для решения гиперболических уравнений методом сетки.
Требования к программе
Требования к функциональным характеристикам
Готовая программа должна обеспечить решение гиперболических уравнений методом сетки.
Необходимо организовать удобный пользовательский интерфейс, включающий справку по использованию и применяемому методу.