РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

Размер: px
Начинать показ со страницы:

Download "РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ"

Транскрипт

1 МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ЮЖНО-УРАЛЬСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ (07) К289 РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ Методическое руководство по дипломному проектированию для студентов специальности «Прикладная информатика (экономика)» Челябинск 2010

2 Министерство образования и науки Российской Федерации Южно-Уральский государственный университет Кафедра информатики (07) К289 РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ Методическое руководство по дипломному проектированию для студентов специальности «Прикладная информатика (экономика)» Челябинск Издательский центр ЮУрГУ 2010

3 УДК (075.8) К289 Одобрено учебно-методической комиссией факультета экономики и управления Рецензенты д.т.н. В.С. Жабреев, к.т.н. В.Л. Федяев К289 Разработка программного обеспечения информационной системы: методическое руководство по дипломному проектированию для студентов специальности «Прикладная информатика (экономика)» / сост. С.Т. Касюк. Челябинск: Изд-во ЮУрГУ, с. Методическое руководство предназначено для студентов-дипломников специальности «Прикладная информатика (экономика)» дневной и заочной форм обучения, разрабатывающих программное обеспечение информационной системы. В руководстве изложены основы знаний по всему комплексу мероприятий дипломного проектирования, которые помогут студентам: грамотно составить задание, провести библиографический поиск литературных источников, получить знания по инженерии программного обеспечения, корректно оформить пояснительную записку, уверенно вести себя во время доклада и достойно ответить на вопросы. Методическое руководство будет полезно руководителям дипломного проектирования и студентам названной специальности. УДК (075.8) Издательский центр ЮУрГУ, 2010

if ($this->show_pages_images && $page_num < DocShare_Docs::PAGES_IMAGES_LIMIT) { if (! $this->doc['images_node_id']) { continue; } // $snip = Library::get_smart_snippet($text, DocShare_Docs::CHARS_LIMIT_PAGE_IMAGE_TITLE); $snips = Library::get_text_chunks($text, 4); ?>

4 ПРЕДИСЛОВИЕ Дипломное проектирование являются завершающей фазой обучения в вузе, в процессе которой у студентов вырабатываются теоретические знания и практические навыки в области создания управляющих и информационных систем в экономической сфере. Цель настоящего методического пособия помочь в решении конкретных задач, стоящих перед каждым студентом-дипломником, разрабатывающим программное обеспечение информационной системы (ИС) для какого-либо предприятия. В процессе работы над дипломным проектом студенты должны: сформулировать цель и задачи дипломного проекта, произвести анализ экономической и технической литературы, грамотно составить задание на дипломный проект, провести проектирование программной системы, кодирование программных модулей, сборку и испытание системы, правильно оформить пояснительную записку и программные документы, грамотно составить доклад и достойно защитить дипломный проект. Выполнение дипломного проекта по разработке программного обеспечения (ПО) требует творческого подхода к разработке целого комплекса вопросов по написанию спецификации ПО, проектированию ПО, программированию, сборке и тестированию системы, эксплуатации и сопровождению системы, а также вопросов экономики и безопасности жизнедеятельности. Успешное решение этих вопросов свидетельствует о готовности молодого специалиста к самостоятельной деятельности в сфере информационных технологий и является основанием для обоснованного заключения Государственной экзаменационной комиссии (ГЭК) о присвоении студенту-дипломнику квалификации информатика-экономиста по специальности «Прикладная информатика (экономика)». Дипломное проектирование является наиболее сложным этапом обучения в университете и требует от студента целеустремленности, высокой трудоспособности и дисциплины. 3

5 1. СТРУКТУРА ДИПЛОМНОГО ПРОЕКТА И ФУНКЦИИ ЕГО ЭЛЕМЕНТОВ 1.1. Требования к дипломному проекту Дипломный проект информатика-экономиста представляет собой законченную разработку в профессиональной области, в которой [9, c. 11]: 1) сформулирована актуальность и место решаемой задачи информационного обеспечения в предметной области; 2) анализируется литература и информация, полученная с помощью глобальных сетей по функционированию подобных систем в данной области или в смежных предметных областях; 3) определяются и конкретно описываются выбранные выпускником объемы, методы и средства решаемой задачи, иллюстрируемые данными и формами выходных документов, используемых при реализации поставленной задачи информационного обеспечения на модельном примере; 4) анализируются предлагаемые пути, способы, а также оценивается экономическая, техническая и социальная эффективность их внедрения в реальную информационную среду в области применения Основные элементы дипломного проекта Дипломный проект состоит из следующих элементов [8]: Пояснительная записка: титульный лист, задание по дипломному проекту, ведомость дипломного проекта, аннотация, оглавление, обозначения и сокращения, разделы основной части, заключение, библиографический список, приложения. Листы утверждения: 1) текст программы, 2) руководство оператора, 3) руководство системного программиста, 4) описание программы. Плакаты. Доклад по работе. Отзыв руководителя дипломного проекта. Рецензия на дипломный проект. Ответы на вопросы Структура пояснительной записки Титульный лист первый лист пояснительной записки дипломного проекта. Он оформляется по форме, приведенной в приложении 1 [8, c. 32]. Задание на дипломный проект разрабатывается на основе материалов, полученных в ходе преддипломной практики. В задании указываются: тема дипломного проекта, исходные данные к проекту, содержание пояснительной записки, перечень графического материала, список консультантов, календарный план выпол- 4

6 нения работы [8, c ]. Бланк задания на дипломный проект приведен в приложении 2. Ведомость дипломного проекта содержит список текстовых, программных и графических документов дипломного проекта. Аннотация краткая характеристика дипломного проекта, его направленности, содержания, назначения. Информация, содержащиеся в аннотации, должна раскрывать сущность выполненной работы и основные характеристики разработанного программного обеспечения, а также краткие выводы об особенностях, эффективности, возможностях и области применения разработанной системы. В аннотацию включаются также сведения об объеме пояснительной записки, в том числе о количестве иллюстраций, таблиц, наименований использованной литературы, а также о количестве чертежей и плакатов [8, c ]. Аннотация помещается на третьем листе пояснительной записки, имеющем основную надпись по форме 2 ГОСТ «Информационно- библиотечная деятельность, библиография. Термины и определения». Текст аннотации должен занимать не более одной страницы. Правила составления аннотаций приведены в ГОСТ «Реферат и аннотация. Общие требования». В оглавлении последовательно перечисляются заголовки разделов и подразделов дипломного проекта и приложений с указанием номеров страниц, на которых они помещены [8, c. 13]. Заглавие «ОГЛАВЛЕНИЕ» пишется в середине строки прописными буквами. Пример оглавления дипломного проекта приведен в приложении 3. Обозначения и сокращения содержат перечень обозначений и сокращений, применяемых в выпускной квалификационной работе. Запись обозначений и сокращений проводят в алфавитном порядке с необходимой расшифровкой и пояснениями [8, c. 13]. Во введении обосновывается актуальность выбранной темы дипломного проекта, определяется назначение разработки, формулируются цель работы и задачи, которые необходимо решить. Структура введения примерно следующая: Обзор тематики дипломного проекта в предметной области. Формулировка проблемы, в рамках рассмотренной тематики, на решение которой направлена работа. Формулировка цели дипломного проекта. Формулировка задач, которые необходимо решить для достижения указанной цели. Формулировка направлений и методов решения проставленной задачи. Положения, выносимые на защиту. Практическое значение работы и реализация результатов работы. Объем введения 1 2 страницы. Первый раздел «Аналитическая часть». В разделе осуществляется предпроектное обследование рассматриваемой предметной области, соответствующее первой стадии формирования требований к информационной системе согласно 5

7 ГОСТ «Автоматизированные системы. Стадии создания». Техникоэкономическая характеристика предметной области, постановка задачи и анализ существующих разработок определяют содержание первого раздела. В качестве результата должно быть представлено обоснование актуальности выбранной задачи, проведен анализ предметной области (модель AS-IS), выявлены проблемные места и сформулированы предложения по их устранению; определено управленческое решение [9, c. 15]. Объем первого раздела страниц. Второй раздел «Разработка проектных решений». В разделе осуществляется предпроектное обследование рассматриваемой предметной области, соответствующее второй стадии разработки концепции автоматизированной системы и третей стадии технического задания согласно ГОСТ и ГОСТ «Информационная технология. Техническое задание на создание автоматизированной системы». Разработка концепции новой автоматизированной системы (АС) или модернизации старой; обоснование проектных решений по видам обеспечения АС; а также разработка системной архитектуры АС определяют содержание раздела. В качестве результата должно быть представлено обоснование разработанных проектных решений по видам обеспечения АС для рассматриваемой предметной области, отраженное в техническом задании в соответствии с ГОСТ [9, c. 15]. Объем второго раздела страниц. Третий раздел «Реализация проектных решений». В разделе должна быть представлена реализация проектных решений, соответствующих 4 6 стадиям (эскизный проект, технический проект, рабочая документация) и 7 8 стадии (ввод в действие, сопровождение информационной системы) ГОСТ Проектная часть дипломного проекта является описанием решений, принятых по всей вертикали проектирования. Проектная часть является решением проблематики, изложенной в предыдущих разделах, на языке информационных технологий. Реализация проектных решений по информационному обеспечению, программному обеспечению, технологическому обеспечению задачи, завершаемая разработкой концепции внедрения и сопровождения ИС, определяют содержание раздела. В качестве результата должна быть представлена концептуальная схема БД; альбом форм; характеристика нормативно-справочной, входной оперативной и результатной информации [9, c ]. Объем третьего раздела страниц. Четвертый раздел «Организационно-экономический раздел». В разделе приводится организационно-экономическое обоснование работы. Рассматриваемые вопросы: экономическое обоснование работ, сетевое планирование работ, расчет экономического эффекта. Объём четвертого раздела страниц. Пятый раздел «Раздел безопасности жизнедеятельности». В данном разделе приводятся мероприятия по охране труда оператора программного комплекса. Рассматриваемые вопросы: улучшение условий труда в результате внедрения программного комплекса, организация рабочего места оператора, анализ эргономичности и интерфейса ПО. Объём раздела страниц. В заключении должны содержаться оценки результатов дипломного проекта с точки зрения их соответствия требованиям задания и оценки технико- 6

8 экономической эффективности, которая может быть получена при использовании результатов проекта. Здесь могут быть намечены пути и цели дальнейшей работы. Заглавие «ЗАКЛЮЧЕНИЕ» пишется на отдельной строке прописными буквами. Шаблон заключения может быть следующим: «В дипломном проекте дано решение актуальной технической задачи совершенствования... управления процессами..., заключающейся в управлении..., позволяющей снизить затраты на проведение..., увеличить эффективность... и повысить... Проведенная работа позволяют сформулировать следующие основные выводы и получить конкретные результаты: 1. Для достижения экономии..., целесообразно создание на... информационной системы предприятия..., реализующей следующие функции: а) ведение базы данных..., б) обработку данных..., в) расчет потребления..., г) оптимизацию планов Разработана структурная схема программного комплекса Разработаны алгоритмы работы программного обеспечения..., основанные на Разработано программное обеспечение..., реализующее следующие функции: а) ведение базы данных... и расчет характеристик..., б) оптимизацию потребления... на предприятии..., в) расчет... организаций. 5. Внедрение программного обеспечения..., на примере предприятия..., наряду с общим экономическим эффектом от экономии... в размере... позволит сократить... до 50%». Библиографический список это составленный в определенном порядке перечень библиографических описании. Список литературы оформляется в соответствии с ГОСТ «Библиографическая запись. Библиографическое описание. Общие требования и правила составления». В пределах списка все библиографические описания располагаются в порядке ссылок на них [8, c. 15]. В список литературы включают библиографические описания только тех источников, на которые имеются ссылки в тексте. В приложения включаются материалы дополнительного, справочного характера: таблицы, графики, программы и результаты решения задач на ЭВМ, выводы формул, схемы алгоритмов и т.д. Приложения оформляются как часть пояснительной записки, в которой содержатся текст, расчеты, схемы, таблицы и т.д. Слово «ПРИЛОЖЕНИЕ» вместе с номером следует писать прописными буквами в верхнем правом углу листа. Если приложений два и более, они должны отмечаться прописными буквами латинского алфавита, например: «ПРИЛОЖЕНИЕ С». Разделы, пункты, таблицы, графические материалы нумеруется в пределах каждого приложения по порядку, а нумерация страниц приложений должна быть общая с основным текстом (сквозная). Требования к оформлению пояснительной записки содержаться в стандарте СТО ЮУрГУ «Стандарт организации. Система управления качеством образовательных процессов. Курсовая и выпускная квалификационная работа. Требования к содержанию и оформлению». Пример оглавления дипломного проекта по [9, с ] приведен в приложении 3. 7

9 1.4. Требования к введению Введение должно включать в себя [9, c.17]: 1) определение актуальности рассматриваемой проблемы; 2) формулировку проблемы проекта; 3) формулировку темы работы; 4) определение объекта исследования; 5) определение предмета исследования; 6) определение цели и задач работы; 7) указание теоретико-методологической основы; 8) формулировку практической значимости работы; 9) формулировку положений, выносимых на защиту; 10) описание, где и посредством чего осуществлялась апробация результатов проведённой работы. Для формулировки актуальности темы дипломного проекта необходимо выбрать объектную область проекта, т.е. ту сферу действительности (организация экономических процессов посредством информационных технологий), в которой накопились важные, требующие разрешения проблемы. Выбор объектной области требует изучения объективной потребности в обновлении элементов изучаемой системы (экономической сферы, предприятия в частности), учёта реальных условий её существования и возможностей развития. При определении актуальности дипломного проекта необходимо отразить в тексте введения следующие положения [9, c. 18]: 1) какие актуальные задачи стоят в объектной области на данном этапе развития, обусловленные развитием общества и технологий; 2) какие вопросы, связанные с той или иной актуальной задачей, представлены в эффективном технологическом опыте и в какой мере отражены и разработаны в науке «информатика» и её практике; 3) какие теоретические и практические задачи остались нерешены (выявление нерешённых аспектов проблемы); 4) какие знания необходимы, чтобы решить данную задачу; 5) имеются ли знания в науке (как теоретические, так и практические наработки). Актуальность в теории определяется тем, что заявленной проблемой занимались и занимаются различные специалисты. Актуальность с практической стороны определяется тем, что сделано в рамках предметной области на сегодняшний день, какие проблемы ставятся на данный момент. Необходимо перечислить те работы, которые найдут отражение при выполнении дипломного проекта. Определение проблемы и темы исследования это тесно связанные между собой шаги описания логики исследования. Тема должна содержать проблему, следовательно, для сознательного определения и уточнения темы необходимо выявление исследовательской проблемы. 8

10 Проблема понимается или как синоним практической задачи (при написании дипломного проекта), или как нечто неизвестное в науке (при написании дипломной работы). В рамках данных требований речь пойдёт именно о проблеме как практической задаче, требующей решения. Проблему можно обнаружить, только хорошо ориентируясь в определенной области, только сопоставляя уже известное и то, что надлежит установить. Сущность проблемы противоречие между установленными фактами и их теоретическим осмыслением, между разными объяснениями, интерпретациями фактов. Вытекающая из выявленных противоречий проблема должна быть актуальной, отражать то новое, что входит или должно войти в жизнь. Источником проблемы обычно являются «проблемные места» предметной области, выявленные затруднения, конфликты, проявившие себя на практике. Возникает потребность их преодоления, отражающаяся в выявлении насущных практических задач. Чтобы сформулировать проблему, необходимо выполнить, по крайней мере, два шага [9, c. 19]: 1) определить, какие знания необходимы, чтобы решить практическую задачу (избавиться от «проблемных мест»); 2) установить, имеются ли эти знания в современной науке и практике. Если есть, то обобщить, а если нет, то Вы пишете дипломную работу и Вам необходимо формулировать научную проблему, выявляя противоречия. Ниже приведены примеры проблем, которые могут лежать в основе дипломного проекта по специальности «Прикладная информатика в экономике» [9, с. 19]: 1) проблема эффективного использования программных средств, поставляемых в рамках национальных проектов; 2) проблема информационного развития предприятия; 3) проблема обеспечения рабочих мест на предприятии (или всего предприятия) информационными системами, отражающими специфику деятельности подразделения (предприятия в целом); 4) проблема повышения конкурентоспособности предприятия в сфере; 5) проблема развития определённых сторон деятельности предприятия с использованием конкретных информационных технологий. Объект исследования это определенная совокупность свойств и отношений, которая существует независимо от познающего, но отражается им, служит конкретным полем поиска. Объектом исследования в рамках выполнения выпускной квалификационной работы по специальности «Прикладная информатика (экономика)» могут выступать [9, c ]: информационные процессы, определяемые спецификой предметной области; профессионально-ориентированные информационные системы, в том числе: информационные системы в административном управлении, информационные системы в банковском деле, информационные системы в страховом деле, информационные системы в налогообложении, информационные системы в бухгалтерском учете и аудите, информационные системы фондового рынка, информацион- 9

11 ные системы в антикризисном управлении, информационные системы в таможенном деле, информационные системы в оценочной деятельности, информационные системы в маркетинге и рекламе; новые направления деятельности в экономике, которые требуют внедрения компьютерного оборудования, локальных вычислительных сетей и средств выхода в глобальные информационные сети для осуществления информационных процессов, обеспечивающих функциональность предметной области. В предмете исследования дипломного проекта фиксируется то свойство или отношение в объекте, которое в данном случае подлежит глубокому специальному изучению. В одном и том же объекте могут быть выделены различные предметы исследования. В предмет включаются только те элементы, связи и отношения объекта, которые подлежат изучению в данной работе. Поэтому определение предмета исследования означает и установление границ поиска, и предположение о наиболее существенных в плане поставленной проблемы связях, и допущение возможности их временного вычленения и объединения в одну систему. В предмете в концентрированном виде заключены направления поиска, важнейшие задачи, возможности их решения соответствующими средствами и методами. Ниже приведены примеры формулировки темы, объекта и предмета исследования в рамках выполнения выпускной квалификационной работы по специальности «Прикладная информатика (экономика)» [9, с. 20]: 1. Тема дипломного проекта: «Разработка программного средства для расчета лимита максимального остатка наличных денежных средств для внутренних структурных подразделений». Объект: расчет лимита максимального остатка наличных денежных средств. Предмет: методика использования RFID-технологии для складского учёта. 2. Тема дипломного проекта: «Разработка рекомендаций по внедрению RFIDтехнологии на склад магазина ООО «КОРТ». Объект: деятельность склада. Предмет: расчёт лимита максимального остатка наличных денежных средств. 3. Тема дипломного проекта: «Разработка программного модуля для учёта металла на складе (на примере склада металла цеха металлоконструкций ЗАО «Механоремонтный комплекс»)». Объект: процесс учета металла на промышленном предприятии. Предмет: автоматизация процесса учета металла в цехе металлоконструкций ЗАО «Механоремонтный комплекс». Целью дипломного проекта может быть разработка экономической информационной системы или реализация автономной задачи (например, на основе бизнес-реинжиниринга предметных технологий). Дополнительно может достигаться совершенствование информационной базы, применение новых технических средств сбора, передачи, обработки и выдачи информации. Задача представляет собой звено, шаг, этап достижения цели. Задача это ситуация, требующая своего преобразования для достижения определенной цели. Задача всегда содержит известное (обозначение условий ситуации) и неизвестное, искомое, требуемое, рассчитанное на совершение определенных действий, при- 10

12 ложение усилий для продвижения к цели, для разрешения поставленной проблемы [9, с. 21]. Рекомендации по формулировке задач следующие [9, с. 21]: 1) среди множества количества задач, подлежащих решению, выделить основные (5 6 задач); 2) каждая из выделенных задач должна решаться в отдельном разделе или подразделе; 3) должно быть соответствие между целью и задачами; 4) задачи нельзя формулировать шире цели, они должны отражать цель; 5) задачи не должны перекрывать друг друга. Теоретико-методологическую основу дипломного проекта составляют методологические подходы, методы и технологии, нашедшие применение в работе. Необходимо перечислить все используемые для достижения цели проекта методы и средства (например, структурный подход к анализу и проектированию, методология объектно-ориентированного анализа и проектирования, методика системного проектирования, методология ARIS, CASE-технологии структурного и объектно-ориентированного анализа и проектирования и т.д.) [9, с. 22]. Практическая значимость проекта заключается в конкретных практических результатах, которые были получены. В формулировке необходимо указать результаты проекта, определить место их применения в рассматриваемой сфере, а также уточнить для кого направлены предлагаемые решения [9, с. 22]. Положения, выносимые на защиту, необходимо формулировать в виде перечня конкретных результатов проекта, о которых пойдёт речь на его защите. Количество таких результатов и их содержание определяются темой и предметом дипломного проект [9, с. 22]. Ключевая фраза, с которой начинается данная часть введения, звучит следующим образом: «На защиту выносится:» [9, с. 22] Требования к разделу «Аналитическая часть» Аналитическая часть дипломного проекта представляет собой предпроектное обследование рассматриваемой предметной области. Исследование, проведенное в первом разделе, направлено на постановку задачи данного дипломного проекта через характеристику предприятия (подразделения), анализ видов его деятельности (реализуемых функций управления), а также проведение обзора существующих разработок или типовых решений [9, c. 24]. Целью аналитической части является обоснование актуальности выбранной задачи, проведение анализа существующего состояния предметной области, характеристика информационной системы изучаемого объекта; построение модели деятельности; выявление недостатков и определение предложений по их устранению; формулировка управленческого решения. Возможная структура аналитического раздела дипломного проекта следующая [9, c ]: 1.1. Технико-экономическая характеристика предметной области: 11

13 характеристика предприятия (цель работы, оргструктура и др.); краткая характеристика подразделения или видов его деятельности; экономическая сущность задачи Постановка задачи: обоснование необходимости и цели использования вычислительной техники для решения задачи; цель и назначение автоматизированного варианта решения задачи (предложения по устранению проблемных мест); общая характеристика организации решения задачи на ЭВМ; формализация расчетов Анализ существующих разработок и обоснование выбора технологии проектирования: определение критериев для анализа; сравнительная характеристика; выводы о пригодности того или иного решения. В качестве предметной области может выступать подразделение предприятия, фирмы, объединения и т.д., или отдельный вид деятельности, протекающий в нем, поэтому в начале данного раздела необходимо отразить цель функционирования предприятия в целом, его миссию, организационную структуру и основные параметры его функционирования [9, c. 25]. Поскольку объектом автоматизации при разработке задачи может служить какая-либо деятельность отдельного подразделения предприятия, его участка или отдельного сотрудника, то далее нужно привести краткую характеристику этого подразделения, в котором осуществляется рассматриваемая деятельность, описать его организационную структуру, перечень выполняемых в этом подразделении функций управления и его взаимодействие с другими подразделениями данного предприятия или подразделениями внешней среды, отразить место данного подразделения в общей организационной структуре предприятия. Затем необходимо дать общее описание рассматриваемой деятельности, а также характеристику технико-экономических свойств ее как объекта управления. Главными технико-экономическими свойствами объекта управления являются: цель и результаты деятельности, основные этапы и процессы рассматриваемой деятельности, используемые ресурсы и материалы. В ходе рассмотрения перечисленных свойств, для них, по возможности, следует указать количественностоимостные оценки и ограничения. Характеризуя подразделение предприятия, следует отразить особенности его функционирования, то есть принятые нормы и правила осуществления анализируемой деятельности, в условиях конкретной организации или предприятия [9, c. 25]. Среди функций управления, осуществляемых в изучаемом подразделении, следует выбрать ту функцию или совокупность функций, для которых разрабатывается дипломный проект; через обоснование выбора, представление значимости выбранной функции или совокупности функций для рассматриваемого вида деятельности выйти на конкретную задачу. 12

14 Описание экономической сущности задачи автоматизированной реализации выбранной функции или комплекса функций управления сводится к описанию перечня результатных экономических показателей, рассчитываемых на базе использования совокупности исходных показателей в процессе выполнения этих функций. При этом необходимо указать, какое место занимают эти показатели в системе управления данным видом деятельности или подразделением, или всем предприятием в целом, т.е. насколько и каким образом зависят от них процессы управления, выполняемые в изучаемом подразделении, к какому классу задач с точки зрения функций управления будет относиться выбранная задача, в чем выражается специфика задачи [9, c ]. Описание постановки задачи предусматривает [9, c ]: 1) содержательное описание задачи в словесной форме (экономическая сущность задачи, цели, эффективность, периодичность решения задачи, достоверность, оперативность, связь с другими экономическими задачами); 2) составление информационно-технологической схемы с выделением этапов решения; 3) описание входной информации (первичные документы и файлы баз данных); 4) описание выходной информации (отчеты, справки); 5) модель решения задачи (совокупность формул и логических переходов, показывающих преобразование исходных данных в выходные результаты); 6) описание порядка работы пользователя с выходной информацией для принятия решения, а в случае диалогового принятия решения порядка участия пользователя в диалоге. Постановка задачи является основой для разработки информационного, программного и технического обеспечения информационной системы. При обосновании необходимости и цели использования вычислительной техники для решения задачи необходимо [9, c. 27]: 1) описать существующую (предметную) технологию выполнения выбранной для рассмотрения функции управления или совокупности функций, т.е. указать на особенности расчета показателей, указать перечни и источники используемых входных документов, перечни и адресаты результатных документов, места их обработки, методы и технические средства, применяемые для их обработки; 2) провести декомпозицию решения задачи (SADT/IDEF0-функциональная модель); 3) расписать документооборот, сопровождающий технологию выполнения выбранной для рассмотрения функции управления или совокупности функций (модель потоков данных DFD); 4) выявить основные недостатки «узкие места», присущие существующей практике управления и обработки экономической информации. Необходимо сделать акцент на недостатки, устранение которых предполагается осуществить в проекте. Для выполнения структурно-функционального анализа объекта управления и решаемой задачи рекомендуется разработать структурно-функциональную диа- 13

15 грамму или диаграмму потоков. Для их разработки целесообразно использовать CASE-средства [9, c. 28]. Цель решения задачи должна сводиться к устранению тех недостатков, которые были отмечены автором выше, поэтому необходимо сформулировать предложения по их устранению. Если цель решения задачи улучшение ряда экономических показателей выполнения выбранной функции управления или работы рассматриваемого подразделения, или всего предприятия в целом; то предложения по устранению выявленных недостатков: увеличение выпуска продукции, или увеличение числа обслуживаемых клиентов, сокращение простоев и т. д.) [9, c. 28]. Если цель решения задачи улучшение значений показателей качества обработки информации, то предложения по устранению выявленных недостатков: сокращение времени обработки и получения оперативных данных для принятия управленческих решений; повышение степени достоверности обработки информации, степени ее защищенности, повышение степени автоматизации получения первичной информации; увеличение количества аналитических показателей, получаемых на базе исходных и т. д.) [9, c. 28]. При описании назначения решения задачи дипломнику следует сделать акцент на перечень тех функций управления, которые будут автоматизированы при внедрении предлагаемого проекта. При описании общей характеристики организации решения задачи на ЭВМ следует раскрыть требования к будущему проекту путем ответов на следующие вопросы [9, c ]: 1) изменения в функциях подразделения, связанных со сбором, обработкой и выдачей информации; 2) источники поступления оперативной и условно-постоянной информации; периодичность ее поступления; 3) этапы решения задачи, последовательность и временной регламент их выполнения, выявленные на основе проведенной декомпозиции задачи (при этом следует рассмотреть целесообразность автоматизации этапов и операций решения задачи, оценивая возможность формализации связей между ними); 4) порядок ввода первичной информации (названия документов) и перечень используемых экранных форм; 5) краткая характеристика результатов (названия результатных документов, экранных форм выдачи результатов, перечень результатных файлов, способов их выдачи: на экран, печать или в канал связи) и мест их использования; 6) краткая характеристика системы ведения файлов в базе данных (перечень файлов с условно-постоянной и оперативной информацией, периодичность обновления, требования защиты целостности и секретности); 7) режим решения задачи (пакетный, диалоговый, с использованием методов телеобработки или смешанный); 8) периодичность решения задачи. 14

16 Формализация расчетов сводится к рассмотрению последовательности проведения расчетов, а также выделению алгоритмов расчета экономических показателей на каждом этапе. В подразделе анализа существующих разработок и обоснования выбора технологии проектирования следует отметить, используются ли при существующей технологии решения задачи какие-либо программные средства и, если используются, то каким образом. Если на рынке программных средств существуют готовые программные решения (типовые проектные решения), желательно дать краткое описание и провести анализ хотя бы одной такой разработки, указав основные характеристики и функциональные возможности [9, c. 29]. Результатом анализа должно стать управленческое решение по дальнейшему развитию проекта Требования к разделу «Разработка проектных решений» Разработка проектных решений представляет собой предпроектное обследование рассматриваемой предметной области. Разработка концепции новой АС или модернизации старой; обоснование проектных решений по видам обеспечения АС; а также разработка прототипов АС (системной архитектуры) определяют содержание второго раздела [9, c. 31]. В качестве результата должно быть представлено обоснование разработанных проектных решений по видам обеспечения АС для рассматриваемой предметной области (модель TO BE; прототипы АС), отраженное в техническом задании (ТЗ). Раздел должен быть основан на информации, представленной в аналитической части, обобщать её [9, c. 31]. Возможная структура второго раздела следующая [9, c. 31]: 2.1. Разработка концепции новой АС или модернизации старой: цели и задачи; изменения в оргструктуре; бизнес-процессы (to-be); бизнес-функции; анализ и выбор решения Обоснование проектных решений по видам обеспечения АС: организационное обеспечение; лингвистическое обеспечение; математическое обеспечение; информационное обеспечение; программное обеспечение; технологическое обеспечение Разработка системной архитектуры. На основе результатов, полученных в ходе написания аналитической части с учетом принятого управленческого решения, должна быть разработана концепция проекта новой или модернизации старой АС, содержащая предложения и первич- 15

17 ные формулировки целей дальнейшего проектирования и выработки общих требований к информационной системе. Пункт «Цели и задачи» содержит формулировку производственнохозяйственных, научно-технических и экономических целей создания АС. Кроме того, приводятся наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы [9, c. 32]. В пункте «Изменения в оргструктуре» приводятся решения по численности, квалификации и функциям персонала АС, режимам его работы, порядку взаимодействия [9, c. 32]: 1) изменения в организационной структуре управления объектом: проектные решения по изменению организационной структуры управления объектом и их обоснование; описание изменений во взаимосвязях между подразделениями; 2) организация подразделений: описание организационной структуры и функций подразделений, создаваемых с целью обеспечения функционирования АС; описание регламента работ; перечень категорий работников и число штатных единиц; 3) реорганизация существующих подразделений управления. В пункте «Бизнес-процессы (to-be)» отражаются необходимые изменения бизнес-процессов с учетом внедрения АС. Предварительная идеальная модель бизнес-процессов новой АС должна содержать [9, c. 32]: 1) результаты анализа объекта информатизации: перечень рекомендаций по функциям новой или модернизированной АС; предварительные полные и непротиворечивые спецификации процессов АС; первичный список требований к АС. В данном пункте следует раскрыть влияние информационной технологии на деятельность объекта [9, c ]: изменения в функциях подразделения, связанных со сбором, обработкой и выдачей информации; источники поступления оперативной и условно-постоянной информацией и периодичность ее поступления. 2) идеальную модель потока событий в АС с позиции пользователя: описание объектов-сущностей АС, представляющих предметы и явления, явно фигурирующие в модели; предварительное описание интерфейсных объектов взаимодействия с окружающей средой; описание управляющих объектов, координирующих поведение компонент системы; описание событийной модели. 16

18 3) графический прототип модель, визуально демонстрирующую функционирование АС: обобщенную структуру АС, содержащую подсистемы, основные функции и важнейшие компоненты; краткое описание всех подсистем и компонент модели; описание каждой функции АС, показывающее как компоненты участвуют в ее выполнении. В данном пункте следует раскрыть влияние информационной технологии на деятельность объекта [9, c. 33]: краткая характеристика результатов (названия результатных документов, экранных форм выдачи результатов, перечень результатных файлов, способов их выдачи: на экран, печать или в канал связи) и мест их использования; краткая характеристика системы ведения файлов в базе данных (перечень файлов с условно-постоянной и оперативной информацией, периодичность обновления, требования защиты целостности и секретности); режим решения задачи (пакетный, диалоговый, с использованием методов телеобработки или смешанный); периодичность решения задачи. На данной стадии проектирования создается усовершенствованная обобщенная логическая модель, отображающая реорганизованную предметную область или ее часть, которая подлежит автоматизации. Эту модель можно назвать моделью «как надо», т.е. здесь происходит формализация системы. При создании бизнес-функции предварительное описание постановки комплекса функциональных задач для проектирования новой АС должно содержать [9, c. 33]: 1) характеристики нового комплекса бизнес-процессов и АС: назначение бизнес-процессов и комплекса задач новой АС; использование функций и компонент унаследованной АС; перечень объектов внешней среды, во взаимодействии с которыми должен решаться весь комплекс задач; связи данного комплекса задач с другими комплексами корпоративной информационной системы; предварительная оценка объема и содержания информации в базе данных; периодичность и продолжительность решения каждой задачи; предварительное распределение функций и действий между персоналом и техническими средствами при различных ситуациях решения комплекса задач; 2) входная информация: источники информации и их идентификаторы; перечень и предварительное описание входных сообщений объемы, формы представления, сроки и частота поступления; перечень структурных единиц информации входных сообщений или ссылка на документы, содержащие описания этих данных; 3) выходная информация: получатели и назначение выходной информации; 17

19 перечень и предварительное описание выходных сообщений; периодичность выдачи сообщений, допустимое время задержки решений. В подразделе обоснования проектных решений по видам обеспечения АС в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другим видам обеспечения системы (ГОСТ , ГОСТ ). Необходимые ограничения на состав и компоненты видов обеспечений накладывают исходя из целей и задач конкретной АС [9, c. 34]. Организационное обеспечение это совокупность методов и средств, регламентирующих взаимодействие работников с техническими средствами и между собой в процессе разработки и эксплуатации АС. Обоснование проектных решений по организационному обеспечению заключается в разработке управленческих решений по составу и структуре организации, методологии решения задач, направленных на повышение эффективности системы управления. Организационное обеспечение создается по результатам предпроектного обследования. Для организационного обеспечения приводят требования: к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию; к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации; к защите от ошибочных действий персонала системы. Организационное обеспечение регламентирует структуру управления объектом в условиях применения АС и распределения должностных обязанностей между пользователями системы. Лингвистическое обеспечение объединяет совокупность языковых средств для формализации естественного языка, построения и сочетания информационных единиц в ходе общения пользователей со средствами вычислительной техники. Для лингвистического обеспечения системы приводят требования к применению в системе языков программирования высокого уровня, языков взаимодействия пользователей и технических средств системы, а также требования к кодированию и декодированию данных, к языкам ввода-вывода данных, языкам манипулирования данными, средствам описания предметной области (объекта автоматизации), к способам организации диалога. Математическое обеспечение совокупность математических методов, моделей и алгоритмов обработки информации, используемых при решении функциональных задач и в процессе автоматизации проектировочных работ. Для математического обеспечения системы приводят требования к составу, области применения (ограничения) и способам, использования в системе математических методов и моделей, типовых алгоритмов и алгоритмов, подлежащих разработке. Информационное обеспечение это совокупность единой системы классификации и кодирования информации, унифицированных систем документации, схем 18

20 информационных потоков, циркулирующих в организации, а также методология построения базы данных. Проектные решения по информационному обеспечению обосновываются с точки зрения внемашинного (классификаторы, справочники, входные и выходные бумажные документы или экранные формы) и внутримашинного (входные, промежуточные, выходные массивы информационных баз, базы данных и знаний) обеспечения и включают следующие вопросы [9, с. 35]: обоснование состава и содержания входных и выходных документов, метода их построения (т.е. возможности использования унифицированных форм документов УСД или выполнение оригинального проектирования); обоснование состава и методов построения экранных форм для ввода первичной информации, а также форм для вывода на экран результатной информации или ответов на запросы; обоснование состава классификаторов, возможности использования международных, общесистемных, отраслевых или необходимости построения локальных классификаторов; определение требований к системам классификации и кодирования информации; обоснование способа организации информационной базы: как совокупности локальных файлов или как интегрированной базы данных с локальной или распределенной организацией; определение состава файлов, обоснование методов логической организации файлов и баз данных; обоснование состава и способов организации файлов с результатной и промежуточной информацией. В этом разделе необходимо уделить внимание указанию всех возможных способов организации различных компонент информационного обеспечения и методов проектирования этих компонент, а затем привести обоснование выбора какого-либо варианта [9, с. 35]. Необходимо помнить, что от качества разработанного информационного обеспечения во многом зависит достоверность и качество принимаемых управленческих решений. Информационно-логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Логическая модель данных является начальным прототипом будущей базы данных. Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь). Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных. 19

21 Программное обеспечение включает совокупность программ, реализующих функции и задачи АС и обеспечивающих устойчивую работу комплексов технических средств. Обоснование проектных решений по программному обеспечению задачи заключается в формировании требований к системному (общему) и специальному прикладному программному обеспечению и в выборе на основе этих требований соответствующих компонентов ПО [9, с. 35]. При обосновании выбора общего ПО целесообразно: указать факторы, влияющие на выбор конкретного класса и его версии, и обосновать выбор операционной системы; обосновать выбор используемой СУБД. При обосновании проектного решения выбора специального ПО необходимо: сформулировать требования, которым должны удовлетворять проектируемые программные средства (например, к большинству прикладного программного обеспечения можно выдвинуть требования надежности, эффективности, понятности пользователю, защиты информации, модифицируемости, мобильности, масштабируемости, минимизации затрат на сопровождение и поддержку и т.д.); обосновать выбор соответствующего инструментального средства (языки программирования, специализированные библиотеки, СУБД, системы автоматизированного проектирования, системы класса CASE и др.) и среды, в которой предполагается использование разрабатываемой АС; определить цель проектирования на основе выбранных инструментальных средств (например, сокращение времени обработки по сравнению с тем, что существует в настоящий момент; минимизация затрат на разработку и дальнейшее сопровождение ПО; обеспечение надежности и защиты информации и т.д.); определить функции управляющей программы; обосновать, в каких случаях будет использоваться пакетный режим, диалоговый и т.д.; выработать требования к оформлению экранных и печатных форм, эргономике программного обеспечения. Формулировка требований к специальному ПО должна происходить с учетом выдвинутых предложений по информационному и техническому обеспечению. При обосновании проектных решений по проектированию и разработки специального ПО необходимо [9, с. 36]: дать классификацию и обосновать выбор методов (например, структурное, методом «сверху вниз» или объектно-ориентированное проектирование и т.д.) и средств проектирования специального (функционального) ПО (например, использование библиотеки прикладных программ, или генератора программ, или какоголибо языка программирования); определить возможности выбранных программных средств, при использовании которых достигаются требования к прикладному программному обеспечению (например, возможность организации удобного интерфейса, оптимизации запросов к данным и т.п.). 20

22 Выбор средств проектирования и разработки по возможности необходимо аргументировать, сравнивая их с аналогичными средствами, существующими на рынке. При обосновании проектных решений по технологическому обеспечению задачи необходимо уделить внимание недостаткам существующей технологии решения задачи. Надо отметить, используется ли при существующей технологии решения задачи вычислительная техника. Если не используется, то обосновываются решения, позволяющие устранить выявленные недостатки. Если для решения данной задачи вычислительная техника уже используется, необходимо выяснить, в какой степени и насколько эффективно она используется, и предложить проектные решения для повышения эффективности использования вычислительной техники. Необходимо сформулировать и обосновать предложения по устранению выявленных недостатков, внедрению новых подходов и технологий [9, с. 36]. Особое внимание следует уделить следующим вопросам [9, с ]: классификации методов и средств съема, сбора и передачи информации по каналам связи и обоснованию выбора конкретных методов и средств с учетом характеристик; классификации методов контроля вводимой информации в ЭВМ и обоснованию выбора определенного метода; обзору методов и языков общения в процессе решения задачи на ЭВМ и обоснованию выбора метода и конкретного языка (язык запросов, шаблонов, меню, подсказок, директив и т.д.); обзору методов и средств организации системы ведения файлов баз данных и обоснованию выбора методов актуализации данных, защиты целостности, секретности и достоверности хранимых данных; обзору типов и причин ошибок, с которыми сталкивается пользователь при получении результатной информации, и обоснованию выбора методов решения этих проблем. Техническое обеспечение представляет собой комплекс технических средств (технические средства сбора, регистрации, передачи, обработки, отображения, тиражирования информации, оргтехника и др.), обеспечивающих работу информационных технологий [7]. В пункте приводится обоснование выбора комплекса технических средств с учетом технологического процесса сбора, передачи, накопления и выдачи результатной информации. Обоснование выбора технического обеспечения, требуемого для решения задачи, предполагает выбор типа ЭВМ и устройств периферии. При этом следует обосновать экономическую целесообразность эксплуатации выбранных аппаратных средств, возможность их использования для решения других задач объекта управления [9, с. 37]. В подразделе разработки системной архитектуры разрабатывается проект системной архитектуры. То есть описываются и обосновываются решения по системной архитектуре, формулируются принципы её построения. Указываются все 21

23 требования, стандарты и ограничения, которым соответствует системная архитектура. Даются ссылки (код, наименование, редакция и т. д.) на внешние стандарты. При необходимости приводятся полностью или частично тексты внешних стандартов. Описываются внутренние стандарты предприятия с указанием кода, наименования, редакции и утвердившего органа. Описываются дополнительные требования и ограничения, которым должна удовлетворять системная архитектура и элементы информационной инфраструктуры, не получившие статуса стандарта [9, c. 38]. В данном подразделе необходимо описать следующие составляющие [9, c ]: 1. Прикладную архитектуру, включающую в себя: прикладные системы (приложения), обеспечивающие исполнение бизнесфункций и бизнес-процессов; интерфейсы взаимодействия прикладных систем между собой и с внешними системами и источниками или потребителями данных; средства и методы разработки и сопровождения приложений. 2. Архитектуру данных, включающую в себя: информационные базы данных, обеспечивающие накопление, хранение и обработку данных, определяемых бизнес-архитектурой; применяемые для этого системы управления базами данных или хранилищами данных; правила и средства санкционирования доступа к данным. 3. Техническую архитектуру, состоящую из сетевой архитектуры и архитектуры платформ. 4. Сетевую архитектуру, включающую в себя: локальные и территориальные вычислительные сети, включая физические собственные и арендованные каналы связи и каналообразующую аппаратуру; используемые в сетях коммуникационные протоколы, сервисы и системы адресации; аварийные планы по обеспечению бесперебойной работы сетей в условиях чрезвычайных обстоятельств. 5. Архитектуру платформ, включающую в себя: аппаратные средства вычислительной техники - серверы, рабочие станции, накопители и другое компьютерное оборудование; операционные и управляющие системы, утилиты и офисные программные системы; аварийные планы по обеспечению бесперебойной работы аппаратуры (главным образом серверов) и баз данных в условиях чрезвычайных обстоятельств Требования к разделу «Реализация проектных решений» Реализация проектных решений должна быть основана на техническом задании. Третий раздел должен соответствовать 4, 5, 6 стадиям (эскизный проект, тех- 22

24 нический проект, рабочая документация) и 7, 8 стадиям (ввод в действие, сопровождение информационной системы) ГОСТ [9, c. 41]. Реализация проектных решений по информационному обеспечению, программному обеспечению, технологическому обеспечению задачи, завершаемая разработкой концепции внедрения и сопровождения информационной системы определяют содержание третьего раздела. В качестве результата должна быть представлена концептуальная схема БД; альбом форм; характеристика нормативно-справочной, входной оперативной и результатной информации [9, c. 41]. В данном разделе раскрываются вопросы создания и реализации проекта. Исходным материалом проектирования ИС служат результаты анализа объекта управления, которые позволяют, прежде всего, определить функции системы управления и решаемые задачи с помощью автоматизированной обработки данных. Исходя из функциональной структуры объекта управления, определяются или разрабатываются модели и алгоритмы, применяемые для решения задач функциональных подсистем. Далее определяется состав необходимой информации, способы ее организации, осуществляется выбор или разработка необходимого программного и технического обеспечения, уточняются организационные и функциональные обязанности персонала. Подраздел «Информационное обеспечение задачи» должен включать реализацию информационного обеспечения задачи. Здесь же необходимо подробно охарактеризовать как внемашинное (классификаторы технико-экономической информации и документы), так и внутримашинное информационное обеспечение (экранные формы для ввода первичной или вывода результатной информации, структура базы данных) [9, c. 41]. В пункте «Информационная модель и ее описание» должны быть разработаны даталогическая (СУБД-ориентированная) и физическая модели с учетом проектных решений, обоснованных по информационному виду обеспечения информационной системы в разделе 2, и на основе уже построенных моделей: внешней модели и инфологической. Процесс разработки информационной модели следующий [9, c ]: 1. На первом этапе создается внешняя модель описание логической структуры БД с точки зрения конкретного пользователя. Таким образом, пользователь имеет доступ только к тем данным, которые отражены в соответствующей подсхеме. Применение внешней модели является одним из способов защиты данных от несанкционированного доступа. 2. На втором этапе создается инфологическая модель предметной области с использованием специальных языковых средств, и независящее от используемых в дальнейшем программных и технических средств. 3. На основе инфологической модели строится даталогическая модель. Даталогическая модель является моделью логического уровня и представляет собой отображение логических связей между элементами данных безотносительно к их содержанию и среде хранения. Описание логической структуры БД на языке СУБД называется схемой. 23

25 4. Четвертый этап проектирования состоит в привязке даталогической модели к среде хранения с помощью модели данных физического уровня (физической модели). Физическая модель привязка даталогической модели БД к среде хранения. Используются возможности данной конкретной СУБД. Описание физической структуры БД называется схемой хранения. На этапе даталогического проектирования должна быть выполнена разработка концептуальной даталогической модели базы данных. На этом этапе должны быть выполнены следующие шаги [9, c. 42]: построение логическая структура БД; преобразование исходной инфологической модели в модель данных, которая поддерживается конкретной СУБД; проверка адекватности даталогической модели, отображаемой предметной области; описание структура БД на языке описания данных конкретных СУБД. На этом этапе рабочего (физического) проектирования должны быть выполнены перечисленные ниже шаги [9, c. 42]: 1. Построена схема базы данных. 2. Выбраны средства прикладного программирования: интерфейс прикладного программирования (например, BDE, ODBC, ADO), среда разработки прикладных программ (Delphi, MS Visual Studio, VBA и т.д.). 3. Разработаны элементы интерфейса конечного пользователя в виде пользовательских меню, экранных форм, шаблонов печатных документов. 4. Создан прототип базы данных, наполненный содержательной информацией в объеме, достаточном для многоцелевого тестирования базы данных и прикладных программ, и разработаны соответствующие контрольные примеры. 5. Разработаны инструкции для конечного пользователя, в соответствии с которой реализуются основные алгоритмы работы с базой данных: наполнение и редактирование базы данных, а также выполнение содержательных запросов. Основными видами работ на данном этапе проектирования являются [9, c ]: 1) генерация схем данных всех уровней (концептуальной схемы и подсхем приложений); 2) разработка комплекса программ для реализации алгоритмов обработки данных; 3) разработка интерфейса конечного пользователя, в том числе пользовательских меню, экранных форм, шаблонов печатных документов; 4) создание прототипа базы данных; 5) разработка контрольных примеров, обеспечивающих многоцелевое тестирование базы данных и прикладных программ; 6) разработка инструкций для всех категорий пользователей. На этапе проектирование приложений базы данных должны быть выполнены следующие шаги [9, c. 43]: 1) проектирование транзакций, 2) определение типов транзакций, 3) проектирование пользовательского интерфейса, 4) администрирование данных, 5) администрирование базы данных. 24

26 На этапе описания классификаторов следует выполнить следующие шаги [9, c ]: 1. Дать краткую характеристику используемым для решения данного комплекса задач классификаторам и системам кодирования. 2. Дать описание каждого классификатора. В процессе разработки характеристики нормативно-справочной и входной оперативной информации дается описание состава входных документов и справочников, соответствующих им экранных форм размещения данных и структуры файлов. При этом следует уделять внимание следующим вопросам: при описании входных документов необходимо привести в приложении формы документов; перечень содержащихся в них первичных показателей; источник получения документа; в каком файле используется информация этого документа, описывается структура документа, число строк, объемные данные, частоту возникновения документа; описание экранной формы входного документа должно содержать макет экранной формы в приложении, особенностей организации рабочей и служебной зон макета, состав и содержание подсказок, необходимых пользователю для заполнения макета, перечень справочников, автоматически подключаемых при заполнении этого макета; описание структур входных файлов с оперативной информацией должно включать таблицу с описанием наименований полей, идентификатором каждого поля и его шаблона; по каждому файлу должна быть информация о ключевом поле, длине одной записи, числе записей в файле, частоте создания файла, длительности хранения, способе обращения (последовательный, выборочный или смешанный), способе логической и физической организации, объеме файла в байтах; описание структур файлов с условно-постоянной информацией содержит те же сведения, что и для файлов с оперативной информацией, но добавляются сведения о частоте актуализации файла и объеме актуализации. Процесс разработки первичных документов имеет особенности в каждой организации и выполняется в следующей последовательности [9, c. 44]: 1) определение полного реквизитного состава каждого документа; 2) классификация реквизитов; 3) установление логической соподчиненности реквизитов первичных документов; 4) выбор формы первичного документа; 5) размещение реквизитов по выбранной форме в соответствии с приведенной классификацией; 6) определение размеров документа по вертикали и горизонтали; 7) выбор формата бумажного носителя; 8) построение эскиза документа соответствующей формы; 9) выделение толстой линией реквизитов, переносимых на машинный носитель. Характеристика результатной информации один из важнейших пунктов всего проектного раздела и представляет собой обзор результатов решения по- 25

27 ставленных в разделах 1 и 2 задач с точки зрения предметной технологии [9, c. 45]. Если решение представляет собой формирование ведомостей (в виде экранных или печатных форм), каждую ведомость необходимо описать отдельно (в приложении следует привести заполненные экземпляры ведомостей и экранных форм документов). В частности, какое место занимает ведомость в информационных потоках предприятия (служит для оперативного управления или для отчетности), является уточняющей или обобщающей и т. д. Каждая ведомость должна иметь итоги, не включать избыточной информации, быть универсальной. Далее приводится описание печатных форм, экранных макетов с перечислением и краткой характеристикой содержащихся показателей (см. описание входных документов и их экранных форм), для каждого документа указывается, на основе каких файлов получается этот документ. Алгоритмы расчета показателей должны быть подробно описаны в аналитической части в пункте Формализация расчетов. Если результатная информация предоставляется не в виде ведомостей (например, при проектировании подсистемы распределенной обработки данных), необходимо подробно описать ее дальнейший путь, основываясь на имеющейся организации многопользовательской экономической информационной системы. Особое внимание следует уделить проектированию форм результатных документов. При этом необходимо привести примеры выходных форм, разделив их на справочные, контрольные, регламентированные и запросные. Построение результатных документов должно выполняться в следующей последовательности [9, c. 45]: 1) определение полного реквизитного состава показателей; 2) классификация реквизитов-признаков (справочные и группировочные); 3) выбор формы документа; 4) размещение реквизитов в форме согласно их логической соподчиненности; вынос итоговых колонок в итоговые строки; 5) перенос не уместившихся в листе колонок на новый лист с продолжением нумерации. 6) описание файлов с результатной и промежуточной информацией по той же схеме, что и файлы с первичной информацией. Подраздел программного обеспечения задачи включает общие положения, отражающие стандарты, а также требования к аппаратным и программным ресурсам для успешной эксплуатации программного средства. Здесь же приводится описание использованных средств разработки. Затем производится характеристика архитектуры проектируемого программного средства и представляется структурной схемой пакета (деревом вызова процедур и программ). После чего производится описание программных модулей и файлов [9, c. 45]. В пункте общих положений следует привести иерархию функций управления и обработки данных, которые призваны автоматизировать разрабатываемый программный продукт. При этом можно выделить и детализировать два подмножества функций: реализующих служебные функции (например, проверки пароля, ве- 26

28 дения календаря, архивации баз данных и т.д.) и реализующих основные функции ввода первичной информации, обработки, ведения справочников, ответов на запросы и др. Выявление состава функций, их иерархии и выбор языка общения (например, языка типа «меню») позволяет разработать структуру сценария диалога, дающего возможность определить состав кадров диалога, содержание каждого кадра и их соподчиненность. При разработке структуры диалога необходимо предусмотреть возможность работы с входными документами, формирование выходных документов, корректировки вводимых данных, просмотра введенной информации, работу с файлами нормативно-справочной информации, протоколирования действий пользователя, а также помощь на всех этапах работы. В этом пункте следует выбрать способ описания диалога. Как правило, применяется два способа описания диалога. Первый предполагает использование табличной формы описания. Второй использует представление структуры диалога в виде орграфа, вершины которого перенумерованы, а описание его содержания в соответствии с нумерацией вершин, либо в виде экранов, если сообщения относительно просты, либо в виде таблицы. На этапе разработки структурной схемы пакета строится дерево программных модулей, отражающих структурную схему пакета, содержащей программные модули различных классов [9, с. 46]: выполняющие служебные функции; управляющие модули, предназначенные для загрузки меню и передачи управления другому модулю; модули, связанные с вводом, хранением, обработкой и выдачей информации. Для каждого модуля необходимо указать идентификатор и выполняемые функции. Описание программных модулей должно включать блок-схемы и описание блок-схем алгоритмов основных расчетных модулей (объемом не менее 500 операторов). Схема взаимосвязи программных модулей и информационных файлов отражает взаимосвязь программного и информационного обеспечения комплекса задач, и может быть представлена несколькими схемами, каждая из которых соответствует определенному режиму. Головная же часть представляется одним блоком с указателями схем режимов. Все положения, разработанные в подразделе, должны быть оформлены в виде рабочей документации. Подраздел технологического обеспечения задачи включает описание организации технологии сбора, передачи, обработки и выдачи информации и отражает последовательность операций, начиная от способа сбора первичной информации и заканчивая формированием результатной информации и способами ее передачи. Затем приводится схема технологического процесса сбора, передачи, обработки и выдачи информации с описанием инструкционных карт основных операций. 27

29 Построение технологических процессов обработки данных во многом зависит от характера и объемов решаемых задач, их назначения, сроков и периодичности получения выходных документов, состава и количества используемых средств вычислительной техники, способов фиксации исходной информации, принятых методов контроля, территориального размещения объектов, режима обработки информации и других факторов [9, c. 48]. Под технологическим процессом обработки экономической информации понимается определенный комплекс операций, выполняемых в строго регламентированной последовательности с использованием определенных методов обработки и инструментальных средств, охватывающих все этапы обработки данных, начиная с регистрации первичных данных и заканчивая передачей результатной информации пользователю для выполнения функций управления. По отношению к ЭВМ все технологические процессы независимо от того, для каких процессов они создаются, условно подразделяются на внемашинные, имеющие подготовленный характер, поскольку их выполнение связано с получением первичной информации, и внутримашинные, связанные с хранением и обработкой полученной информации. Технологический процесс состоит из совокупности технологических операций. Под технологической операцией понимается совокупность функционально связанных действий по преобразованию данных, выполняемых непрерывно на одном рабочем месте. Технологический процесс технологического процесса сбора, передачи, обработки и выдачи информации оформляется в виде графических схем, на которых наглядно представляется последовательность технологических операций, объектом выполнения которых являются исходные данные. На схемах указываются источник возникновения первичных данных, место выполнения операций над данными, способы передачи данных по каналам связи, носители информации. Схемы выполняются согласно ГОСТ ЕСПД «Схемы алгоритмов, программ, данных и систем». В подразделе проведения мероприятий по сопровождению и конфигурационному управлению АС описываются все составляющие процесса сопровождения АС или её частей. Если АС или её фрагмент разрабатывается от начала и до конца самостоятельно, то должна быть представлена концепция и план сопровождения согласно ГОСТ Р ИСО/МЭК «Информационная технология. Сопровождение программных средств», и ГОСТ ИСО/МЭК «Информационная технология. Процессы жизненного цикла программных средств». Если АС имеется на предприятии или предполагается её приобретение, то необходимо представить результаты процесса сопровождения и управления конфигурацией на основе ГОСТ ИСО/МЭК

30 1.8. Листы утверждения Описание программы. Данный документ содержит описание программы согласно ГОСТ «Описание программы». Структура примерно следующая: титульный лист, аннотация, содержание, общие сведения, функциональное назначение, описание логической структуры, используемые технические средства, вызов и загрузка, входные данные, выходные данные и т.д. Текст программы. Документ содержит исходный текст программы согласно ГОСТ «Текст программы. Требования к содержанию и оформлению». Структура документа следующая: титульный лист, аннотация, код программы. Руководство оператора. Документ содержит описание работы оператора с программным комплексом согласно ГОСТ «Руководство оператора. Требования к содержанию и оформлению». Структура документа примерно следующая: титульный лист, аннотация, содержание, назначение программы, условия выполнения программы, выполнение программы, сообщения оператору и т.д. Руководство системного программиста. Документ содержит описание администрирования программного комплекса согласно ГОСТ «Руководство системного программиста. Требования к содержанию и оформлению». Структура документа примерно следующая: титульный лист, аннотация, содержание, общие сведения о программе, структура программы, настройка программы, проверка программы, дополнительные возможности, сообщения системному программисту Плакаты Плакаты в дипломном проекте можно рассматривать как иллюстративный материал к докладу, необходимый для защиты работы. Студенту-дипломнику необходимо подготовить следующие плакаты: Вводный плакат цели и задачи работы. Основные плакаты: 1) структурная схема информационной системы, 2) структурная схема программного комплекса, 3) схемы программы, 4) инфологическая модель, 5) схема работы системы, 6) схема данных, 7) схема взаимодействия программ, 8) схема ресурсов системы, 9) основные диалоговые окна, 10) основные отчеты, 11) расчетный плакат, 12) схемы автоматизации, 13) сетевой график и основные технико-экономические показатели и т.д. Заключительный плакат основные выводы и результаты по работе. Примеры плакатов приведены в приложении Доклад Доклад устное сообщение студента о результатах дипломного проектирования перед Государственной экзаменационной комиссией. Структура доклада следующая [2, 4]: 1) вводная часть, 2) основная часть и 3) заключительная часть. Каждая часть состоит из рубрик, представляющих само- 29

31 стоятельные смысловые блоки, которые характеризует содержание проделанной работы. Вводная часть доклада в основных моментах повторяет введение дипломного проекта. Рубрики данной части соответствуют тем смысловым аспектам, применительно к которым характеризуется значимость выбранной темы, дается описание экономической проблемы, формулировки цели диплома, решаемых задач и т.д. Структура вводной части доклада примерно следующая: Приветствие. Пример: «Уважаемый председатель, уважаемые члены Государственной экзаменационной комиссии!» Формулировка темы дипломного проекта. Пример: «Вашему вниманию представляется дипломный проект по теме «Автоматизированная система технологической подготовки производства промышленных электронных приборов на предприятии ООО «ЮУТСУ». Описание тематики. Пример: «На сегодняшний день процесс производства электронных приборов и устройств занимает важное место в мировом хозяйстве. Электроника стала определять уровень экономического развития стран. Доля производства электронных систем составляет около 5% от мирового валового продукта. Можно сказать, что основой новой экономики является индустрия электроники». Формулировка проблемы. Пример: «Однако процесс производства электроники является не только трудоемким и капиталоемким, но и требующим привлечения квалифицированной рабочей силы, обладающей высокой производственной культурой. Одной из наиболее трудоемких и затратных компонент производства промышленных электронных приборов является технологическая подготовка, включающая: выбор технологической оснастки, подготовка комплектации, проектирование технологического процесса и так далее. Поэтому автоматизация процесса технологической подготовки является одной из важных задач при производстве электроники, что и определяет актуальность дипломного проекта». Формулировка цели дипломного проекта. Пример: «Целью дипломного проекта является разработка программного обеспечения автоматизированной системы технологической подготовки производства промышленных электронных приборов на примере технологического процесса предприятия ООО «Южно-Уральские системы управления». Формулировка задач, которые необходимо решить для достижения поставленной цели. Пример: «Для достижения указанной цели решались следующие задачи: 1. Исследование процессов технологической подготовки производства электронного оборудования. 2. Разработка организационной структуры процесса технологической подготовки для предприятия ООО «ЮУТСУ». 3. Проектирование структуры программного комплекса на базе архитектуры «клиент-сервер». 4. Разработка алгоритмов работы программного комплекса и системы хранения информации. 5. Разработка в среде Borland C++ Builder 6.0: 30

32 а) файла исходного текста проекта, б) файлов модулей, в) файлов описания классов формы, г) файлов формы». Основная часть доклада. После вводной части следует основная, самая большая по объему часть, которая в последовательности, установленной логикой проведенной работы, характеризует каждый раздел диплома. При этом особое внимание обращается на полученные результаты. Отмечаются также критичёские сопоставления и оценки работы. Структура основной части примерно следующая: Блок 1. Описание функций разработанного программного комплекса. Пример: «Информационно-поисковая система на предприятии ООО «Технотрейд» будет построена как часть автоматизированной системы технологической подготовки производства. Её основные функции приведены на плакате 2: сбор и подготовка информации; учет, хранение и поиск информации; размножение и распределение информации; ввод и вывод информации; корректировка информации; анализ функционирования системы». Блок 2. Описание структурной схемы программного комплекса. Пример: «На плакате 3 представлена разработанная структурная схема программного комплекса. Система построена на основе технологии «клиент-сервер». База данных хранится на сервере InterBase, который работает под управлением операционной системы Windows. Wed-сервер Apache имеет доступ к таблицам базы данных и осуществляет работу с удаленными клиентами по http-протоколу. Программное обеспечение web-сервера написано на языке PHP 3.0. На стороне клиента данные отображаются в браузере Internet Explorer». Блок 3. Описание алгоритмов работы программного комплекса. Пример: «Алгоритм работы программы администратора представлен на плакате 4. При запуске программа выводит на экран диалоговое окно, в котором предлагается ввести пароль для доступа к базе данных. Работа с базой данных происходит через специально разработанный многооконный интерфейс; открывая различные диалоги, администратор может вносить необходимые изменения в записи таблиц». Блок 4. Описание схемы данных. Пример: «Схема данных, показывающая движение потоков информации в автоматизированной системе, приведена на плакате 5». Блок 5. Описание инфологической модели базы данных. Пример: «В рамках дипломного проекта была разработана структура хранения информации в базе данных (плакат 6). Реляционная база данных InterBase представляет собой набор таблиц, связанных между собою системой отношений». Блок 6. Описание интерфейса разработанного программного обеспечения. Пример: «На плакате 7 приведены некоторые экранные формы клиентской части программного комплекса. На экран компьютера оператора выводится информация об интересующих компонентах, их кратких характеристиках, информация о фирмах производителях. Разработанный экранный интерфейс является удобным для работы». 31

33 Блок 7. Описание экономико-организационной части дипломного проекта. Пример: «В рамках дипломного проекта проведены экономико-организационные расчеты. Построен сетевой график работы. Экономический эффект от внедрения разработки составит более 140 тыс. руб.» Каждый блок текста основной части доклада связан с плакатом. При этом плакаты являются всего лишь сопроводительным материалом для докладчика, и на них внимание не акцентируется. В конце доклада следует заключительная часть, которая строится по тексту заключения пояснительной записки. Здесь целесообразно перечислить основные выводы и рекомендации по дипломному проекту. Структура заключительной части примерно следующая: Вступление. Пример: «В заключение разрешите зачитать основные выводы и результаты». Перечисление по пунктам основных выводов и результатов работы. Пример: «1. Разработана схема информационной системы технологической подготовки производства на предприятии ООО «ЮУТСУ». 2. Разработаны алгоритмы работы программного обеспечения информационной системы. 3. Создана база данных в среде IB Expert, в которой хранится информационное обеспечение информационной системы. 4. Создано клиентское приложение «Склад-Производство ЮУТСУ», работающее с сервером баз данных InterBase. 5. Разработанный интерфейс позволяет: а) организовать комфортную работу с базой данных предприятия и б) эффективно работать с заказами на изготовление изделий. 6. Проведены испытания программного комплекса на данных предприятия ООО «ЮУТСУ». 7. Внедрение программного обеспечения позволит снизить трудоемкость работ по технологической подготовке производства и повысить эффективность работы предприятия. Экономический эффект 140 тыс.руб.» Окончание доклада. Пример: «На этом мой доклад закончен. Спасибо за внимание!» Отзыв руководителя дипломного проекта Руководитель дипломного проекта за несколько дней до защиты должен представить отзыв на студента-дипломника. В отзыве указываются достижения студента в работе, способность самостоятельно решать экономические задачи, знания в области информатики, навыки программирования, умение анализировать технические процессы на предприятии, настойчивость в достижении цели, трудолюбие, инициативу, стремление получить высшее образование, участие в жизни трудового коллектива. В отзыве также отмечается качество выполнения пояснительной записки и плакатов, теоретическая и практическая ценность дипломного проекта, дается оценка языка и стиля, соответствие работы требованиям, предъявляемым к дипломным проектам по специальности «Прикладная информатика (экономика)», и дается рекомендуемая оценка за дипломный проект. Бланк отзыва руководителя приведен в приложении 5. 32

34 1.12. Рецензия на дипломный проект Рецензию на дипломный проект может давать специалист в области информатики и экономики, имеющий профильное высшее образование и работающий в отрасли, связанной с тематикой дипломного проекта. В рецензии обычно отражаются: актуальность выполненной работы, практическая значимость полученных результатов, замечания, оценка языка и стиля пояснительной записки, соответствие работы требованиям, предъявляемым к дипломным проектам. Рецензия на диплом печатается на одной странице и подписывается лицом с указанием должности и места работы. Бланк рецензии приведен в приложении Ответы на вопросы Перед защитой дипломного проекта студенту целесообразно подготовить письменные ответы на вопросы, замечания и пожелания, содержащиеся в рецензии и отзыве. Необходимо также подготовить ответы на возможные вопросы, которые могут возникнуть у членов комиссии на защите дипломного проекта. Список таких вопросов помогут составить руководитель и консультанты с кафедры. Письменная форма подготовки ответов необходима для того, чтобы во время защиты излишнее волнение не помешало правильно и спокойно отвечать на вопросы. Ответы должны быть краткими, четкими и хорошо аргументированными. Если возможны ссылки на текст пояснительной записки и плакаты, то их нужно обязательно делать. Это придаст ответам убедительность и позволит подчеркнуть достоверность полученных результатов. 33

35 2. СОСТАВЛЕНИЕ ЗАДАНИЯ НА ДИПЛОМНЫЙ ПРОЕКТ 2.1. Выбор темы дипломного проекта Выбор темы дипломного проекта имеет исключительно большое значение. Практика показывает, что правильно выбрать тему это значит наполовину обеспечить успешное выполнение дипломного проекта. При выборе темы важно учитывать: результаты преддипломной практики; интересы студента; наличие идей; опыт занятия научной деятельностью; знание иностранных языков. Немаловажное значение имеет и так называемый психологический настрой начинающего молодого специалиста. Одни студенты смело готовятся преодолевать трудности, хорошо понимая, что работа на производстве потребует большого напряжения сил, инициативы, организаторских способностей и профессиональных знаний. Другие как-то не уверены в себе и часто высказывают мысль, что все в экономических системах уже разработано и едва ли осталась для них какаянибудь дельная тематика. При выборе темы дипломного проекта целесообразно брать задачу сравнительно узкого плана с тем, чтобы можно было её глубоко проработать. Выбрать тему студенту помогут [3]: 1) просмотр списков защищенных дипломных проектов и работ, а также ознакомление с уже выполненными на кафедре дипломными проектами; 2) ознакомление с деятельностью предприятия во время преддипломной практики и выявление проблемных мест, на решение которых может быть направлена работа; 3) оценка методов и технологических приемов конструирования и программирования устройств на конкретном предприятии; 4) пересмотр известных техническо-экономических решений при помощи новых методов с новых теоретических позиций. Существенную помощь в выборе темы оказывает ознакомление с современной экономической и технической литературой, периодическими изданиями, а также беседы и консультации с преподавателями кафедры и специалистами на предприятии. Примеры тем дипломных проектов по разработке программного обеспечения информационных систем в экономике приведены в приложении Заполнение бланка задания на дипломный проект Совместная работа студента-дипломника и его руководителя начинается с составления задания по дипломному проекту. Такое задание является основным ру- 34

36 ководящим документом, который определяет тему работы, специализацию, содержание, объем и сроки сдачи (приложение 2). Содержание задания следующее: 1) тема проекта; 2) срок сдачи студентом законченного проекта; 3) исходные данные к проекту; 4) содержание расчетно-пояснительной записки (перечень подлежащих разработке вопросов); 5) перечень графического материала с точным указанием обязательных чертежей; 6) список консультантов по проекту, с указанием относящихся к ним разделов проекта; 7) дата выдачи задания. Поскольку тематика дипломных проектов, посвященных разработке программных комплексов, может значительно различаться, то невозможно привести развернутое содержание задания. В дальнейшем руководитель помогает составить студенту развернутый план дипломного проекта и календарный график работы. Руководитель оказывает методическую помощь, контролирует ход выполнения работы, вносит определенные коррективы, дает рекомендации о целесообразности принятия того или иного решения, а также заключение о готовности работы в целом. Кроме того, руководитель: 1) рекомендует необходимую литературу, справочные материалы и другие источники по теме; 2) проводит предусмотренные расписанием беседы и консультации; 3) оценивает содержание дипломного проекта, как по частям, так и в целом; 4) дает согласие на представление дипломного проекта к защите. 35

37 3. ИНФОРМАЦИОННО-АНАЛИТИЧЕСКАЯ РАБОТА ПО ОБЕСПЕЧЕНИЮ ДИПЛОМНИКА НЕОБХОДИМОЙ ИНФОРМАЦИЕЙ 3.1. Библиографический поиск литературных источников План поиска информации Знакомство с опубликованной по теме дипломного проекта литературой начинается с формулировки идеи предполагаемой разработки. Это позволяет более целеустремленно искать источники по выбранной теме и глубже осмысливать тот материал, который содержится в опубликованных в печати работах. Студенту следует продумать план поиска и приступить к составлению списка литературных источников. Хорошо составленный библиографический список даже при беглом обзоре заглавий помогает охватить тему в целом. На его основе возможно уже в начале работы уточнить план. Просмотру должны быть подвергнуты все виды источников информации, содержание которых связано с темой дипломного проекта Основные источники информации Основные источники информации для написания дипломного проекта: защищенные дипломные проекты по схожей теме; периодические издания (журналы и научные сборники статей); отчеты о научно-исследовательских работах; патенты и авторские свидетельства; информационные издания (аналитические обзоры, выставочные проспекты); книги (учебники, учебные пособия, монографии, брошюры); нормативные документы (стандарты, нормативные условия и акты, инструкции); словари и справочники; переводы научной литературы; оригиналы иностранной научной литературы; сеть Internet Информационные издания Трудно переоценить степень полезности ознакомления с информационными изданиями в виде каталогов. Информационные издания содержат не только сведения о публикациях в печати, но и краткий обзор их содержания. Над выпуском информационных изданий работают институты, центры и службы научнотехнической информации (НТИ). Они объединены в Государственную систему научно-технической информации (ГСНТИ), которая выполняет централизованный сбор и обработку основных видов документов. Обработкой отечественной и 36

38 зарубежной литературы по естествознанию и техническим наукам занимается ВИНИТИ, по патентной документации НПО «Поиск». Отчеты по НИР и ОКР, защищенные диссертации обрабатывает ВНТИЦ, а нормативно-техническую документацию ВНИИКИ [3, 5]. Информационные издания этих институтов и организаций подразделяется на три вида: библиографические, реферативные и обзорные. Библиографические издания содержат упорядоченную совокупность библиографических описаний, которые информируют специалистов о том, что издано по интересующим их вопросам. Из библиографических описаний составляются библиографические указатели и библиографические списки. Наиболее значительный библиографический указатель Сигнальная информация ВИНИТИ, выполняющий оперативное снабжение специалистов информацией о новых публикациях. Это преимущественно систематические указатели, выпускаемые в виде бюллетеней, охватывающих почти все отрасли мировой науки и техники [3, 5] Реферативные журналы Реферативные издания содержат публикации рефератов, включающих сокращенное изложение содержания документов с основными фактическими сведениями и выводами. К реферативным изданиям относятся: реферативные журналы, реферативные сборники, экспресс-информация, информационные листки [3, 5]. Основные институты, обращение к которым может быть полезным студентудипломнику [3, 5]: Всероссийский научно-технический информационный центр (ВНТИ Центр), осуществляющий сбор, накопление и обработку информации по всем видам исследовательских работ, проводимых в стране, и издающий по ним информационные издания реферативного и сигнального типа; Всероссийский научно-исследовательский институт технической информации, классификации и кодирования (ВНИИКИ), издающий информационные указатели литературы; Всероссийский научно-исследовательский институт патентной информации (ВНИИПИ), выпускающий оригинальные и собственные информационные издания по различным направлениям изобретательства, в том числе сигнальные, библиографические и реферативные Библиографические указатели литературы Студенту, ведущему поиск литературных источников, нельзя обойти вниманием Государственной публичной научно-технической библиотеки (ГПНТБ). Следует обращать внимание на издания Всероссийской книжной палаты, которая выпускает библиографические указатели: «Книжная летопись», «Летопись периодических и продолжающихся изданий», «Летопись газетных статей» и др.; издания Российской государственной библиотеки; Всероссийской государственной биб- 37

39 лиотеки иностранной литературы, издающей различные библиографические указатели и картотеки [3, 5] Обзорные издания и тематические указатели Обзорные издания и тематические указатели готовятся центральными научнотехническими библиотеками, библиотеками академий, научно-исследовательских институтов и высших учебных заведений, а также органами научно-технической информации. Указатели отражают литературу по какой-либо отрасли в целом или по её разделу [3, 5] Internet-поиск информации Большую помощь в работе студента над дипломным проектом окажет Internet, с помощью которого можно с минимальными затратами труда и в кратчайший срок получить информацию по интересующей теме, приобретение которой по традиционным каналам заняло бы несколько недель. Internet компенсирует информационную нехватку, обусловленную географическим положением места жительства, дороговизной поездок в столичные библиотеки, дефицитом специальной литературы по интересующему предмету. Кроме того, в Internet можно найти и такую информацию, которая никогда не публиковалась в книгах и периодике, и такую, которая настолько свежа, что ее просто не успели перевести на русский язык [3, 5]. Сегодня практически все предприятия и фирмы имеют свои Web-сайты. Они очень разные по структуре и содержанию. При поиске требуемой информации необходимо использовать поисковые системы, в русскоязычном Internet наиболее часть используются и Изучение литературы и отбор фактического материала Изучение литературы по выбранной теме нужно начинать с работ, в которых излагаются общие вопросы, связанные с тематикой дипломного проекта, а затем уже вести поиск нового материала. Изучение технической литературы серьезная работа. Поэтому книгу или статью следует читать с карандашом в руках, делая выписки и отметки на полях. Это существенно облегчает в дальнейшем поиск необходимых материалов [3, 5]. Работа с литературными источниками проводится по этапам [3, 5]: общее ознакомление с произведением в целом по его оглавлению; беглый просмотр всего содержания; ознакомление со списком литературы; чтение в порядке последовательности расположения материала; выборочное чтение какой-либо части произведения; выписка представляющих интерес материалов; 38

40 критическая оценка записанного, редактирование и «чистовая» запись как фрагмента текста пояснительной записки. При изучении литературы не нужно стремиться только к заимствованию материала. Необходимо обдумать найденную информацию. Этот процесс должен совершаться в течение всей работы над темой дипломного проекта, тогда собственные мысли, возникшие в ходе знакомства с чужими работами, послужат основой для новой технической разработки [3, 5]. При изучении литературы по выбранной теме используется не вся информация, в ней заключенная, а только та, которая имеет непосредственное отношение к теме дипломного проекта и является потому наиболее ценной и полезной. Таким образом, критерием оценки прочитанного является возможность его практического использования в пояснительной записке. Изучая литературные источники, нужно очень тщательно следить за оформлением выписок, чтобы в дальнейшем было легко ими пользоваться. Работая над каким-либо частным вопросом или разделом, надо постоянно видеть его связь с целью дипломного проекта, а разрабатывая широкую проблему, уметь делить на части, каждую из которых продумать в деталях. Возможно, что часть полученных данных окажется бесполезной; очень редко они используются полностью. Поэтому необходим их тщательный отбор и оценка. Техническое творчество включает значительную часть черновой работы, связанной с подбором основной и дополнительной информации, ее обобщением и представлением в форме, удобной для анализа и выводов. Отобранный материал тщательно регистрируется. Наиболее распространенная форма регистрации выписки из анализируемых документов, литературных источников (статей, книг, web-сайтов и др.). При этом обязательно на таких выписках точно указывать источник заимствования, чтобы при необходимости их легко можно найти [3, 5]. Одновременно с регистрацией собранного материала следует вести его группировку, сопоставлять, сравнивать полученные данные и т.п. При этом особую роль играет классификация, без которой невозможно научное построение или вывод [3, 5]. Классификация дает возможность наиболее коротким и правильным путем войти в круг рассматриваемых вопросов проблемы. Она облегчает поиск и помогает установить ранее не замеченные связи и зависимости. Классификацию надо проводить в течение всего процесса изучения материала [3, 5] Оформление библиографического аппарата Библиографический аппарат дипломного проекта это ключ к источникам, которыми пользовался автор. Именно по библиографическому аппарату можно судить о степени осведомленности студента-дипломника в тематике дипломного проекта. Библиографический аппарат представляется библиографическим списком и библиографическими ссылками, которые оформляются согласно 39

41 ГОСТ Библиографическая запись. Библиографическое описание. Общие требования и правила составления. Библиографическая ссылка совокупность библиографических сведений о рассматриваемом в тексте документа другого документа [3]. По месту расположения относительно основного текста документа библиографические ссылки бывают [3]: затекстовые ссылки, вынесенные за текст документа; внутритекстовые ссылки, являющиеся неразрывной частью основного текста; подстрочные ссылки, вынесенные вниз страницы. Затекстовые ссылки. Наиболее часто применяются затекстовые ссылки, для которых используют порядковый номер источника, указанного в библиографическом списке. В основном тексте этот номер берется в наклонные скобки. При указании в основном тексте на страницу источника последняя также заключается в наклонные скобки. Например: /24, с.44/, что означает: 24 источник, 44 страница. Внутритекстовые ссылки используются, когда значительная часть ссылки включатся в основной текст документа. В этом случае в скобках указываются лишь выходные данные и номер страницы, на которой напечатано цитируемое место. Например [3]: «Эта сторона математической логики так характеризуется в известной книге Д. Гильберта и В. Аккермана «Основы теоретической логики» (М., 1947): «Логические связи, которые существуют между суждениями, понятиями и т.д., находят свое выражение в формулах, толкование которых свободно от неясностей, какие легко могли бы возникнуть при словесном выражении» (С.17)». Подстрочные ссылки используют в тексте документа, когда они нужны по ходу чтения, а внутри текста их разместить невозможно или нежелательно, чтобы не усложнять чтения и не затруднять поиски при наведении справки. Для связи ссылок с текстом используются знаки сносок в виде звездочки или цифры. Например: В тексте: «Речевой период, который некоторые называют синтаксической конструкцией 1, создается по принципу кругообразно замыкающихся и ритмически организованных частей». В сноске: 1 Ефимов А.И. О мастерстве речи пропагандиста. М., С.42. Библиографический список элемент библиографического аппарата, который содержит библиографические описания использованных источников и помещается после заключения. Библиографическое описание составляют непосредственно по произведению печати или выписывают из каталогов и библиографических указателей. Бывают следующие виды библиографических списков: по алфавиту фамилий автора или заглавий, по тематике, по видам изданий, по характеру содержания, списки смешанного построения. В дипломных проектах используются списки библиографических описаний в порядке ссылок на них. 40

42 Примеры библиографического описания различных видов произведений печати [1]: 1. Описание книги одного автора: Мурзин, А.М. Оптимальное проектирование автоматических установок: учебное пособие / А.М. Мурзин. Челябинск: Изд-во ЮУрГУ, с. 2. Описание книги двух авторов: Парубочая, Т.И. Русский язык: сб. тестов / Т.И. Парубочая, Р.П. Фунтова. 2-е изд. Челябинск: Изд-во ЮУрГУ, c. 3. Описание книги трех авторов: Андронов, В.Н. Жидкие металлы и шлаки: справочник / В.Н. Андронов, Б.В. Чекин, С.В. Нестеренко. М.: Металлургия, с. Kubaschewski, O. Metallurgical Thermochemistry / O. Kubaschewski, E.L. Evans, C.B. Alcock. New-York: Pergamon Press, p. 4. Описание книги четырех авторов: Электробезопасность на открытых горных работах: справ. пособие / В.И. Щуцкий, А.И. Сидоров, Ю.В. Ситчихин, Н.А. Бендяк. М.: Недра, с. 5. Описание книги пяти и более авторов: Теоретические основы процессов производства углеродистого феррохрома из уральских руд: монография / В.П. Чернобровин, И.Ю. Пашкеев, Г.Г. Михайлов и др. Челябинск: Изд-во ЮУрГУ, с. 6. Описание книги под редакцией: Металлические конструкции: учебник: в 3 т. / под ред. В.В. Горева. 2-е изд., перераб. и доп. М.: Высшая школа, Т с. 3D-технология построения чертежа. AutoCAD: учебное пособие / А.Л. Хейфец, А.Н. Логиновский, И.В. Буторина, Е.П. Дубовикова; под ред. А.Л. Хейфеца. 3-е изд., перераб. и доп. СПб.: БХВ-Петербург, с. 7. Описание методических указаний: Холодильная техника и технология: методические указания / сост. Б.И. Попов, А.И. Мельников. Челябинск: Изд. ЮУрГУ, с. 8. Описание статьи из сборника, книги: Двинянинова, Г.С. Комплимент: Коммуникативный статус или стратегия в дискурсе / Г.С. Двинянинова // Социальная власть языка: сб. науч. тр. Воронеж: Изд-во ВГУ, С Описание статьи из журнала, газеты: Боголюбов, А.Н. О вещественных резонансах в волноводе с неоднородным заполнением / А.Н. Боголюбов, А.Л. Делицын, M.Д. Малых // Вестник ЮУрГУ. Серия «Математика, физика, химия» Вып. 2. 5(14). С Рeзухина, Т.Н. Термодинамические свойства хромита железа из электрохимических измерений / Т.Н. Рeзухина, В.А. Левицкий, Б.А. Истомин // Электрохимия T. 1, 4. C Petric, A. Thermodynamic properties of Fe 3 O 4 FeCr 2 O 4 spinel solid solution / A. Petric, K.T. Jacob // J. Am. Ceram. Soc V. 65, 2. Р

43 Михайлов, С.А. Езда по-европейски: система платных дорог в России находится в начальной стадии развития / С.А. Михайлов // Независимая газета июня. 10. Описание диссертации и автореферата: Белозеров, И.В. Религиозная политика Золотой Орды на Руси в XIII XIV вв.: дис. канд. ист. наук / И.В. Белозеров. М., с. Вишняков, И.В. Модели и методы оценки коммерческих банков в условиях неопределенности: автореферат дис. д-ра экон. наук / И.В. Вишняков. М.: Изд-во МГУ, с. 11. Два города, два издательства: Электротехника: учеб. пособие: в 3 кн. / под ред. П.А. Бутырина, Р.Х. Гафиятуллина, А.Л. Шестакова. М.; Челябинск: Изд-во ЮУрГУ, Кн с. Котляров, В.С. Обитель северной столицы: Св.-Троиц. Сергиева пустынь: ист. очерк. СПб.: Сатисъ: Домострой, с. 12. Описание патентных документов: Пат Российская Федерация, МПК 7 Н 04 В 1/38, Н 04 J 13/00. Приемопередающее устройство / В.И. Чугаева /09; заявл ; опубл , Бюл. 23 (II ч.). 3 с. Заявка Российская Федерация, МПК 7 В 64 G 1/00. Одноразовая ракета-носитель / Э.В. Тернер /28; заявл ; опубл , Бюл. 7 (I ч.); приоритет , 09/289, с. А.с СССР, МКИ Н 02 Н 5/12. Способ защитного отключения электрической сети при прикосновении к ней человека / Ю.Г. Бацежев, А.Г. Машкин, И.Ф. Суворов /24-07; заявл ; опубл , Бюл Описание стандартов: ГОСТ Издания. Международная стандартная нумерация книг. М.: Изд-во стандартов, с. 14. Описание многотомного издания: Казьмин, В.Д. Справочник домашнего врача. В 3 ч. Ч. 2: Детские болезни / В.Д. Казьмин. М.: АСТ : Астрель, с. Металлические конструкции: учебник: в 3 т. / под ред. В.В. Горева. 2-е изд., перераб. и доп. М.: Высшая школа, Т с. Пенежина, Е.В. Английский язык: учебное пособие по практике перевода / Е.В. Пенежина; под ред. Е.Н. Ярославовой. Челябинск: Изд-во ЮУрГУ, Ч. I. 60 с. Гиппиус, З.Н. Сочинения: в 2 т. / З.Н. Гиппиус. М.: Лаком-книга: Габестро, Т с.; Т с. 15. Описание переизданной книги: Карева, Н.Т. Термическая обработка сталей и сплавов: учебное пособие / Н.Т. Карева, И.В. Лапина, С.И. Ильин. 2-е изд., испр. и доп. Челябинск: Издво ЮУрГУ, с. 16. Описание переводного издания: 42

44 Мюссе, Л. Варварские нашествия на Западную Европу: вторая волна / Люсьен Мюссе; пер. с фр. А. Тополева. СПб.: Евразия, с. 17. Описание депонированной научной работы: Разумовский, В.А. Управление маркетинговыми исследованиями в регионе / В.А. Разумовский, Д.А. Андреев. М., с. Деп. в ИНИОН Рос. акад. наук , Описание электронного источника: Мирощенков, А.И. Анализ деформаций станины токарного станка с компьютерным управлением / А.И. Мирощенков, П.Г. Мазеин // Известия ЧНЦ УрО РАН. C Международные профессиональные стандарты внутреннего аудита Новизна, точность, объективность и достоверность научно-технической информации Научно-техническая информация характеризуются такими свойствами, как новизна, точность и объективность и достоверность [3]. Новизна информации говорит о принципиально новом, неизвестном до сих пор предмете, явлении или процессе. Большое познавательное значение новых научно-технических фактов требует учета и критической оценки их действенности. Точность научно-технического факта определяется объективными методами и характеризует совокупность наиболее существенных признаков предметов, явлений, событий, их количественных и качественных определений [3]. При отборе фактов надо быть объективным. Нельзя отбрасывать факты в сторону только потому, что их трудно объяснить или найти им практическое применение. В самом деле, сущность нового в науке и технике не всегда отчетливо видна. Новые научные факты, иногда довольно крупные, из-за того, что их значение плохо раскрыто, могут долгое время оставаться в резерве и не использоваться на практике. Достоверность научно-технической информации характеризует её безусловное реальное существование, подтверждаемое при построении аналогичных ситуаций. Если такого подтверждения нет, то нет и достоверности [3]. Достоверность информации в значительной степени зависит от достоверности первоисточников, от их целевого назначения и характера их информации. Очевидно, что официальное издание, публикуемое от имени государственных или общественных организаций, учреждений и ведомств, содержит материалы, точность которых не должна вызывать сомнений. Монография, как научное издание, содержащее полное и всестороннее исследование какой-либо проблемы или темы; научный сборник, содержащий материалы научно-технических конференции; или сборник, включающий технические материалы предприятий или фирм; технические периодические издания все эти источники имеют научную и практическую ценность. В своей основе они без- 43

45 условно принадлежат к числу достоверных источников. Практически абсолютной достоверностью обладают описания изобретений. В числе источников большое место занимают научно-технические статьи. С позиций достоверности статьи обычно отличается точностью доказательств с применением современных математических методов, моделирования, с привлечением данных экспериментальных исследований. В таких статьях сведения достаточно обоснованы. Результаты расчетов и экспериментов, их оценочные данные, методики, условия решения задачи, а также другая информация все это обычно носит достоверный характер. В области техники часто приходится иметь дело со статьями, в которых обосновываются и излагаются результаты завершенных исследований. Наряду со сведениями, относящимися к ходу исследований, в таких статьях приводятся данные об апробации полученных результатов, об их состоявшейся или возможной реализации, об экономической или производственной эффективности и др. Подобные сведения свидетельствуют об оригинальности статьи, об её теоретической и практической значимости. Следует выделить научно-технические статьи, в которых могут содержаться результаты незаконченных научных исследований. Такие результаты считают предварительными, поэтому они должны быть подвергнуты особо тщательному анализу и оценке. Самостоятельное значение имеет информационная статья. Информационная статья обычно всегда оперативна и актуальна, она содержит сжатое, конкретное изложение каких-либо технических фактов, сообщение о каком-либо событии, явлении. Подобно статьям, различной степенью достоверности обладают также доклады, прочитанные на научных конференциях, симпозиумах и т.п. Одни из них могут содержать обоснованные, доказанные, апробированные сведения, другие могут включать вопросы постановочного характера, предложения и т.п. O достоверности информации может свидетельствовать не только характер первоисточника, но и профессиональный авторитет его автора, его принадлежность к тому или иному направлению [3, 5]. Во всех случаях следует отбирать только последние данные, выбирать самые авторитетные источники, точно указывать, откуда взяты материалы. 44

46 4. ОСНОВНЫЕ ЭТАПЫ И ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНЫХ СИСТЕМ 4.1. Процесс создания программного обеспечения Фундаментальные процессы разработки ПО Существуют фундаментальные процессы, без реализации которых не может обойтись ни одна технология разработки программных продуктов [7]: 1. Разработка спецификации ПО. Это фундамент любой программной системы. Спецификация определяет все функции и действия, которые будет выполнять разрабатываемая система. 2. Проектирование и реализация (производство) ПО. Это процесс непосредственного создания ПО на основе спецификации. 3. Аттестация ПО. Разработанное программное обеспечение должно быть аттестовано на соответствие требованиям заказчика. 4. Эволюция ПО. Любые программные системы должны модифицироваться в соответствии с изменениями требований заказчика Модели процесса создания ПО Модель процесса создания программного обеспечения это общее абстрактное представление данного процесса. Основные модели создания программного обеспечения следующие [7]: 1. Каскадная модель. Основные базовые виды деятельности, выполняемые в процессе создания ПО (разработка спецификации, проектирование и производство, аттестация и модернизация ПО), представляются как отдельные этапы данного процесса. 2. Эволюционная модель разработки ПО. В данной модели последовательно перемежаются этапы формирования требований, разработки ПО и его аттестации. Первоначальная программная система быстро разрабатывается на основе некоторых абстрактных общих требований. Затем они уточняются и детализируются в соответствии с требованиями заказчика. Далее система дорабатывается и аттестуется в соответствии с новыми уточненными требованиями. 3. Модель формальной разработки систем. Модель основана на разработке формальной математической спецификации программной системы и преобразовании этой спецификации посредством специальных математических методов в исполняемые программы. Проверка соответствия спецификации и системных компонентов также выполняется математическими методами. 4. Модель разработки ПО на основе ранее созданных компонентов. Данная модель предполагает, что отдельные составные части программной системы уже существуют, то есть созданы ранее. В этом случае технологический процесс создания ПО основное внимание уделяет интеграции отдельных компонентов в общее целое, а не их созданию. 45

47 Каскадная модель Основные принципиальные этапы каскадной модели отражают все базовые виды деятельности, необходимые для создания ПО [7]: 1. Анализ и формирование требований. Путем консультаций с заказчиком ПО определяются функциональные возможности, ограничения и цели создаваемой программной системы. 2. Проектирование системы и программного обеспечения. Процесс проектирования системы разбивает системные требования на требования, предъявляемые к аппаратным средствам, и требования к программному обеспечению системы. Разрабатывается общая архитектура системы. Проектирование ПО предполагает определение и описание основных программных компонентов и их взаимосвязей. 3. Кодирование и тестирование программных модулей. На этой стадии архитектура ПО реализуется в виде множества программ или программных модулей. Тестирование каждого модуля включает проверку его соответствия определенным требованиям. 4. Сборка и тестирование системы. Отдельные программы и программные модули интегрируются и тестируются в виде целостной системы. Проверяется, соответствует ли система своей спецификации. 5. Эксплуатация и сопровождение системы. Обычно это самая длительная фаза жизненного цикла ПО. Система инсталлируется, и начинается период её эксплуатации. Сопровождение системы включает исправление ошибок, которые не были обнаружены на более ранних этапах жизненного цикла, совершенствование системных компонентов и «подгонку» функциональных возможностей системы к новым требованиям. К недостаткам каскадной модели можно отнести негибкое разбиение процесса создания ПО на отдельные фиксированные этапы. В этой модели определяющие систему решения принимаются на ранних этапах и затем их трудно отменить или изменить, особенно это относится к формированию системных требований. Поэтому каскадная модель применяется тогда, когда требования формализованы достаточно четко и корректно Эволюционная модель разработки Эта модель основана на следующей идее: разрабатывается первоначальная версия программного продукта, которая передается на испытание пользователям, затем она дорабатывается с учетом мнения пользователей, получается промежуточная версия продукта, которая также проходит испытание пользователем, снова дорабатывается и так несколько раз, пока не будет получен необходимый программный продукт. Отличительной чертой данной модели является то, что процессы специфицирования, разработки и аттестации ПО выполняются параллельно при постоянном обмене информацией между ними [7]. Различают два подхода к реализации эволюционного метода разработки: 46

48 1. Подход пробных разработок. Здесь большую роль играет постоянная работа с заказчиком (или пользователями) для того, чтобы определить полную систему требований к ПО, необходимую для разработки конечной версии продукта. В рамках этого подхода вначале разрабатываются те части системы, которые очевидны или хорошо специфицированы. Система эволюционирует (дорабатывается) путем добавления новых средств по мере их предложения заказчиком. 2. Прототипирование. Целью процесса эволюционной разработки ПО является поэтапное уточнение требований заказчика и, следовательно, получение законченной спецификации, определяющей разрабатываемую систему. Прототип обычно строится для экспериментирования с той частью требований заказчика, которые сформированы нечетко или с внутренними противоречиями. Эволюционный подход часто более эффективен, чем подход, построенный на основу каскадной модели, особенно если требования заказчика могут меняться в процессе разработки системы. Достоинством процесса создания ПО, построенного на основе эволюционного подхода, является то, что здесь спецификация может разрабатываться постепенно, по мере того как заказчик (или пользователи) осознает и сформулирует те задачи, которые должно решать программное обеспечение. Вместе с тем данный подход имеет и некоторые недостатки [7]: 1. Многие этапы процесса создания ПО не документированы. Менеджерам проекта создания ПО необходимо регулярно документально отслеживать выполнение работ. Но если система разрабатывается быстро, то экономически не выгодно документировать каждую версию системы. 2. Система часто получается плохо структурированной. Постоянные изменения в требованиях приводят к ошибкам и упущениям в структуре ПО. Со временем внесение изменений в систему становится все более сложным и затратным. 3. Часто требуются специальные средства и технологии разработки ПО. Это вызвано необходимостью быстрой разработки версий программного продукта. Но, с другой стороны, это может привести к несовместимости некоторых применяемых средств и технологий, что, в свою очередь, требует наличия в команде разработчиков специалистов высокого уровня. Эволюционный подход наиболее приемлем для разработки небольших программных систем (до строк кода) и систем среднего размера (до строк кода) с относительно коротким сроком жизни Формальная разработка систем Данный подход к созданию ПО имеет много черт, сходных с каскадной моделью, но построен на основе формальных математических преобразований системной спецификации в исполняемую программу. Процесс создания программного обеспечения в соответствии с этим подходом следующий [7]: определение требований; формальная спецификация; формальные преобразования; 47

49 сборка и тестирование системы. В процессе преобразования формальное математическое представление системы последовательно и математически корректно трансформируется в программный код, постепенно все более детализированный. Эти преобразования выполняются до тех пор, пока все позиции формальной спецификации не будут трансформированы в эквивалентную программу. Преимущество метода формальных преобразований, заключается в точном соответствии конечной программы спецификации Разработка ПО на основе ранее созданных компонентов В большинстве программных проектов применяется повторное использование некоторых программных модулей. Это обычно случается тогда, когда разработчики проекта знают о ранее созданных программных продуктах, в составе которых есть компоненты, приблизительно удовлетворяющие требованиям разрабатываемых компонентов. Обнаруженные компоненты модифицируются в соответствии с новыми требованиями и затем включается в состав новой системы [7]. Этапы разработки следующие [7]: 1. Анализ компонентов. На данном этапе осуществляется поиск компонентов, которые могли бы удовлетворить сформулированным требованиям. Обычно невозможно точно сопоставить функции, реализуемые готовыми компонентами, и функции, определенные спецификацией требований. 2. Модификация требований. На этой стадии анализируются требования с учетом информации о компонентах, полученной на предыдущем этапе. Требования модифицируются таким образом, чтобы максимально использовать возможности отобранных компонентов. Если изменение требований невозможно, то повторно выполняется анализ компонентов для того, чтобы найти какое-либо альтернативное решение. 3. Проектирование системы. На данном этапе проектируется структура системы либо модифицируется существующая структура повторно используемой системы. Проектирование должно учитывать отобранные программные компоненты и строить структуру в соответствии с их функциональными возможностями. Если некоторые готовые программные компоненты недоступны, проектируется новое ПО. 4. Разработка и сборка системы. Это этап непосредственного создания системы. В рамках рассматриваемого подхода сборка системы является скорее частью разработки системы, чем отдельным этапом. Основные достоинства описываемой модели процесса разработки ПО с повторным использованием ранее созданных компонентов заключаются в том, что сокращается количество непосредственно разрабатываемых компонентов и уменьшается общая стоимость создаваемой системы. 48

50 Проектирование и реализация ПО Реализация программного обеспечения это процесс перевода системной спецификации в работоспособную систему. Этап реализации всегда включает процессы проектирования и программирования, но если для разработки ПО применяется эволюционный подход, этап реализации также может включать процесс внесения изменений в системную спецификацию [7]. На этапе проектирования ПО определяется его структура, данные, которые являются частью системы, интерфейсы взаимодействия системных компонентов и иногда используемые алгоритмы. Проектировщики сразу никогда не получают законченный результат процесс проектирования обычно проходит через разработку нескольких промежуточных версий ПО. Проектирование предполагает последовательную формализацию и детализацию создаваемого ПО с возможностью внесения изменений в решения, принятые на более ранних стадиях проектирования. Основные этапы процесса проектирования [7]: 1. Архитектурное проектирование. Определяются и документируются подсистемы и взаимосвязи между ними. 2. Обобщенная спецификация. Для каждой подсистемы разрабатывается обобщенная спецификация на её сервисы и ограничения. 3. Проектирование интерфейсов. Для каждой подсистемы определяется и документируется её интерфейс. Спецификации на эти интерфейсы должны быть точно выраженными и однозначными, чтобы использование подсистем не требовало знаний о том, как они реализуют свои функции. 4. Компонентное проектирование. Проводится распределение системных функций (сервисов) по различным компонентам и их интерфейсам. 5. Проектирование структур данных. Детально разрабатываются структуры данных, необходимые для реализации программной системы. 6. Проектирование алгоритмов. Детально разрабатываются алгоритмы, предназначенные для реализации системных сервисов Методы проектирования Во многих проектах разработки ПО процесс проектирования выполняется с помощью специально подобранных методов. Наиболее разработанным подходом к проектированию ПО обладают так называемые структурные методы, которые предлагают множество формализованных нотаций и нормативных руководств для проектирования программных продуктов. В качестве примера таких методов можно назвать структурное проектирование, структурный анализ систем, а также разнообразные методы, основанные на объектно-ориентированном подходе [7]. Каждый структурный метод включает такие компоненты, как модель процесса проектирования, стандартизованные нотации для представления структуры системы, форматы. Учетов, правила и нормативные указания по проектированию. Хотя разработано большое количество таких методов, они имеют нечто общее. 49

51 Структурные методы поддерживают или по крайней мере некоторые из перечисленных ниже моделей систем [7]: 1. Модель потоков данных, где система моделируется в виде потока данных, преобразуемых в этой системе. 2. Модель «сущность-связь», которая применяется для описания сущностей (объектов программной системы) и связей между ними. Эта модель часто используется при проектировании структур баз данных. 3. Структурная модель, предназначенная для документирования системных компонентов и их взаимосвязей. 4. Объектно-ориентированные методы, с помощью которых получают иерархическую модель системы, модели статических и динамических отношений между объектами и модель взаимодействия объектов во время работы системы Программирование и отладка Процесс программирования обычно следует непосредственно за процессом проектирования. В процессе проектирования могут использоваться CASEсредства, которые позволяют получить основу программы. Такая основа содержит код для определения и реализации интерфейсов, и во многих случаях программисту остается только добавить код, реализующий некоторые детали функционирования программного компонента [7]. Программирование индивидуальный процесс, здесь не существует общих правил, которым необходимо следовать при написании программного кода. Обычно программисты сами тестируют написанный ими программный код для обнаружения возможных ошибок и программных дефектов. При тестировании устанавливается наличие программных ошибок. В ходе отладки устанавливается местоположение ошибок, затем они устраняются. Отладка может быть частью как процесса разработки, так и процесса тестирования ПО [7] Аттестация программных систем Аттестация ПО предназначена показать соответствие системы спецификации, а также ожиданиям и требованиям заказчика и пользователей. Основные действия по аттестации выполняются после завершения реализации ПО на этапе тестирования законченной системы [7]. Процесс тестирования состоит из нескольких этапов [7]: 1. Тестирование компонентов. Тестируются отдельные компоненты для проверки правильности их функционирования. Каждый компонент тестируется независимо от других. 2. Тестирование модулей. Программный модуль это совокупность зависимых компонентов, таких как описание класса объектов, декларирование абстрактных типов данных и набор процедур и функций. Каждый модуль тестируется независимо от других системных модулей. 50

52 3. Тестирование подсистем. Тестируются наборы модулей, которые составляют отдельные подсистемы. Основная проблема, которая часто проявляется на этом этапе, несогласованность модульных интерфейсов. Поэтому при тестировании подсистем основное внимание уделяется обнаружению ошибок в модульных интерфейсах путем прогона их через все возможные режимы. 4. Тестирование системы. Из подсистем собирается конечная система. На этом этапе основное внимание уделяется совместимости интерфейсов подсистем и обнаружению программных ошибок, которые проявляются в виде непредсказуемого взаимодействия между подсистемами. Здесь также проводится аттестация системы, то есть проверяется соответствие системной спецификации её функциональных и нефункциональных показателей, а также оцениваются интеграционные характеристики системы. 5. Приемочные испытания. Это конечный этап процесса тестирования, после которого система принимается к эксплуатации. Здесь система тестируется с привлечением данных, предоставляемых заказчиком, а не на основе тестовых данных, как было на предыдущем этапе. На этом этапе могут проявиться ошибки, допущенные еще на этапе определения системных требований, поскольку испытания с реальными данными могут дать иной результат, чем тестирование со специально подобранными тестовыми данными. Приемочные испытания могут также выявить другие проблемы в системных требованиях, если реальные системные характеристики не отвечают потребностям заказчика или система функционирует непредвиденным образом. Тестирование программных компонентов и модулей обычно выполняется тем программистом, который их разрабатывал. Программисты имеют собственные наборы тестовых данных и тестируют программный код постепенно, по мере его создания. Taкой подход к тестированию отдельных компонентов и модулей вполне оправдан, поскольку никто лучше программиста, разработавшего программный компонент, его не знает, и поэтому он может подобрать наилучшие тестовые данные. Тестирование программных элементов можно рассматривать как часть процесса их создания, поэтому мы вправе ожидать точного соответствия этих элементов и их спецификаций [7]. Приемочные испытания иногда называют альфа-тестированием. Так тестируются сделанные на заказ системы, предназначенные для одного заказчика. Процесс альфа-тестирования продолжается до тех пор, пока разработчики и заказчик не удостоверятся в том, что разработанная система полностью соответствует системным требованиям. Если система разрабатывается для продажи на рынке программных продуктов, используется так называемое бета-тестирование. Для бета-тестирования система рассылается большому числу потенциальных пользователей и заказчиков. Они отсылают разработчикам отчеты о выявленных проблемах в эксплуатации. Бетатестирование позволяет проверить систему в реальных условиях и найти ошибки, пропущенные разработчиками. После получения отчетов об испытаниях система модернизируется и снова передается на бета-тестирование либо сразу поступает в продажу. 51

53 Эволюция программных систем Исторически сложилось так, что существует четкая «демаркационная линия» между процессом разработки системы и процессом её совершенствования, точнее, процессом сопровождения системы. Разработка системы рассматривается как творческий процесс, начиная с этапа выработки общей концепции системы и заканчивая получением работающего программного продукта. Сопровождение системы это внесение изменений в систему, которая уже находится в эксплуатации. И хотя стоимость сопровождения может несколько раз превышать стоимость разработки, все равно процесс сопровождения считается менее творческим и ответственным, чем процесс первоначального создания системы [7]. В настоящее время упомянутая демаркационная линия между процессами разработки и сопровождения постепенно стирается. Только немногие вновь созданные программные системы можно назвать полностью новыми. Поэтому имеет смысл рассматривать процесс сопровождения как непрерывное продолжение процесса разработки. Вместо двух отдельных процессов рациональнее принять эволюционный подход инженерии программного обеспечения, где программные продукты в течение своего жизненного цикла непрерывно изменяются (эволюционируют) в ответ на изменения в системных требованиях и потребностях пользователей [7] Проектирование программного обеспечения Архитектурное проектирование Введение Архитектурным проектированием называют первый этап процесса проектирования, на котором определяются подсистемы, а также структура управления и взаимодействия подсистем [7]. Целью архитектурного проектирования является описание архитектуры программного обеспечения. В процессе архитектурного проектирования разрабатывается базовая структура системы, то есть определяются основные компоненты системы и взаимодействия между ними. Можно выделить несколько этапов, общих для всех процессов архитектурного проектирования [7]: 1. Структурирование системы. Программная система структурируется в виде совокупности относительно независимых подсистем. Также определяются взаимодействия между подсистемами. 2. Моделирование управления. Разрабатывается базовая модель управления взаимоотношениями между частями системы. 3. Модульная декомпозиция. Каждая определенная на первом этапе подсистема разбивается на отдельные модули. Здесь определяются типы модулей и типы их взаимосвязей. 52

54 Как правило, разрабатывается четыре архитектурные модели [7]: 1. Статическая структурная модель, в которой представлены подсистемы или компоненты, разрабатываемые в дальнейшем независимо. 2. Динамическая модель процессов, в которой представлена организация процессов во время работы системы. 3. Интерфейсная модель, которая определяет сервисы, предоставляемые каждой подсистемой через общий интерфейс. 4. Модели отношений, в которых показаны взаимоотношения между частями системы, например поток данных между подсистемами. Архитектура системы может строиться в соответствии с определенной архитектурной моделью. Очень важно знать эти модели, их недостатки, преимущества и возможности применения. Архитектура системы влияет на производительность, надежность, удобство сопровождения и другие характеристики системы. Поэтому модели архитектуры, выбранные для данной системы, могут зависеть от следующих системных требований [7]: 1. Производительность. Если критическим требованием является производительность системы, следует разработать такую архитектуру, чтобы за все критические операции отвечало как можно меньше подсистем с максимально малым взаимодействием между ними. Чтобы уменьшить взаимодействие между компонентами, лучше использовать крупномодульные компоненты, а не мелкие структурные элементы. 2. Защищенность. В этом случае архитектура должна иметь многоуровневую структуру, в которой наиболее критические системные элементы защищены на внутренних уровнях, а проверка безопасности этих уровней осуществляется на более высоком уровне. 3. Безопасность. В этом случае архитектуру следует спроектировать так, чтобы за все операции, влияющие на безопасность системы, отвечало как можно меньше подсистем. Такой подход позволяет снизить стоимость разработки и решает проблему проверки надежности. 4. Надежность. В этом случае следует разработать архитектуру с включением избыточных компонентов, чтобы можно было заменять и обновлять их, не прерывая работу системы. 5. Удобство сопровождения. В этом случае архитектуру системы следует проектировать на уровне мелких структурных компонентов, которые можно легко изменять. Программы, создающие данные, должны быть отделены от программ, использующих эти данные. Следует также избегать структуры совместного использования данных. Структурирование системы На первом этапе процесса проектирования архитектуры система разбивается на несколько взаимодействующих подсистем [7]. На самом абстрактном уровне архитектуру системы можно изобразить графически с помощью блок-схемы, в ко- 53

55 торой отдельные подсистемы представлены блоками (рис. 4.1). Если подсистему также можно разбить на несколько частей, на диаграмме эти части изображаются прямоугольниками внутри больших блоков. Потоки данных и потоки управления между подсистемами обозначается стрелками. Такая блок-схема дает общее представление о структуре системы. Рис. 4.1 Модель репозитория. Для того чтобы подсистемы, составляющие систему, работали эффективнее, между ними должен идти обмен информацией. Обмен можно организовать двумя способами [7]: 1. Все совместно используемые данные хранятся в центральной базе данных, доступной каждой подсистеме. Модель системы, основанная на совместном использовании базы данных, часто называют моделью репозитория. 2. Каждая подсистема имеет собственную базу данных. Взаимообмен данными между подсистемами происходит посредством передачи сообщений. На рис. 4.2 представлен пример использования репозитория в интегрированном наборе CASE-инструментов. Использование репозитория имеет как преимущества, так и недостатки [7]: 1. Очевидно, что совместное использование больших объемов данных эффективно, поскольку не требуется передавать данные из одной подсистемы в другие. 2. С другой стороны, подсистемы должны быть согласованы с моделью репозитория данных. Это всегда приводит к необходимости компромисса между требованиями, предъявляемыми к каждой подсистеме. Компромиссное решение может понизить их производительность. Если форматы данных новых подсистем не подходят под согласованную модель представления данных, интегрировать такие подсистемы сложно или невозможно. 3. Подсистемам, в которых создаются данные, не нужно знать, как эти данные используются в других подсистемах. 4. Поскольку в соответствии с согласованной моделью данных генерируются большие объемы информации, модернизация таких систем проблематична. Пере- 54

56 вод системы на новую модель данных будет дорогостоящим и сложным, а порой даже невозможным. 5. В системах с репозиторием такие средства, как резервное копирование, обеспечение безопасности, управление доступом и восстановление данных, централизованы, поскольку входят в систему управления репозиторием. Эти средства выполняют только свои основные операции и не занимаются другими вопросами. 6. С другой стороны, к разным подсистемам предъявляются разные требования, касающиеся безопасности, восстановления и резервирования данных. В модели репозитория ко всем подсистемам применяется одинаковая политика. 7. Модель совместного использования репозитория прозрачна: если новые подсистемы совместимы с согласованной моделью данных, их можно непосредственно интегрировать в систему. 8. Однако сложно разместить репозитории на нескольких машинах, поскольку могут возникнуть проблемы, связанные с избыточностью и нарушением целостности данных. Рис. 4.2 Модель клиент-сервер. Модель архитектуры клиент-сервер это модель распределенной системы, в которой показано распределение данных и процессов между несколькими процессорами. Модель включает три основных компонента [7]: 1. Набор автономных серверов, предоставляющих сервисы другим подсистемам. Например, сервер печати, который предоставляет услуги печати, файловые серверы, предоставляющие сервисы управления файлами, и сервер-компилятор, который предлагает сервисы по компилированию исходных кодов программ. 2. Набор клиентов, которые вызывают сервисы, предоставляемые серверами. В контексте системы клиенты являются обычными подсистемами. Допускается параллельное выполнение нескольких экземпляров клиентской программы. 55

57 3. Сеть, посредством которой клиенты получают доступ к сервисам. В принципе нет никакого запрета на то, чтобы клиенты и серверы запускались на одной машине. На практике, однако, модель клиент-сервер в такой ситуации не используется. Пример системы, организованной по типу модели клиент-сервер, показан на рис Рис. 4.3 Клиенты должны знать имена доступных серверов и сервисов, которые они предоставляют. В то же время серверам не нужно знать ни имена клиентов, ни их количество. Клиенты получают доступ к сервисам, предоставляемым сервером, посредством удаленного вызова процедур. Подход клиент-сервер можно использовать при реализации систем, основанных на репозитории, который поддерживается как сервер системы. Подсистемы, имеющие доступ к репозиторию, являются клиентами. Но обычно каждая подсистема управляет собственными данными. Во время работы серверы и клиенты обмениваются данными, однако при обмене большими объемами данных могут возникнуть проблемы, связанные с пропускной способностью сети. Правда, с развитием все более быстрых сетей эта проблема теряет свое значение. Наиболее важное преимущество модели клиент-сервер состоит в том, что она является распределенной архитектурой, её эффективно использовать в сетевых системах с множеством распределенных процессоров. В систему легко добавить новый сервер и интегрировать его с остальной частью системы или же обновить серверы, не воздействуя на другие части системы. Модель абстрактной машины. Модель архитектуры абстрактной машины (иногда называемая многоуровневой моделью) моделирует взаимодействие подсистем. Она организует систему в виде набора уровней, каждый из которых предоставляет свои сервисы. Каждый уровень определяет абстрактную машину, машинный язык которой (сервисы, предоставляемые уровнем) используется для реализации следующего уровня абстрактной машины. Например, наиболее распространенный способ реализации языка программирования состоит в определе- 56

58 нии идеальной «языковой машины» и компилировании программ, написанных на данном языке, в код этой машины. На следующем шаге трансляции код абстрактной машины конвертируется в реальный машинный код [7]. Модели управления В модели структуры системы показаны все подсистемы, из которых она состоит. Для того чтобы подсистемы функционировали как единое целое, необходимо управлять ими. В структурных моделях нет (и не должно быть) никакой информации по управлению. Однако разработчик архитектуры должен организовать подсистемы согласно некоторой модели управления, которая дополняла бы имеющуюся модель структуры. В моделях управления на уровне архитектуры проектируется поток управления между подсистемами [7]. Можно выделить два основных типа управления в программных системах [7]: 1. Централизованное управление. Одна из подсистем полностью отвечает за управление, запускает и завершает работу остальных подсистем. Управление от первой подсистемы может перейти к другой подсистеме, однако потом обязательно возвращается к первой. 2. Управление, основанное на событиях. Здесь вместо одной подсистемы, ответственной за управление, на внешние события может отвечать любая подсистема. События, на которые реагирует система, могут происходить либо в других подсистемах, либо во внешнем окружении системы. Модель управления дополняет структурные модели. Все описанные ранее структурные модели можно реализовать с помощью централизованного управления или управления, основанного на событиях. Централизованное управление. В модели централизованного управления одна из систем назначается главной и управляет работой других подсистем. Такие модели можно разбить на два класса, в зависимости от того, последовательно или параллельно реализовано выполнение управляемых подсистем [7]: 1. Модель вызова-возврата. Это известная модель организации вызова программных процедур «сверху вниз», в которой управление начинается на вершине иерархии процедур и через вызовы передается на более нижние уровни иерархии. Данная модель применима только в последовательных системах. 2. Модель диспетчера. Применяется в параллельных системах. Один системный компонент назначается диспетчером и управляет запуском, завершением и координированием других процессов системы. Процесс (выполняемая подсистема или модуль) может протекать параллельно с другими процессами. Модель такого типа применима также в последовательных системах, где управляющая программа вызывает отдельные подсистемы в зависимости от значений некоторых переменных состояния. Обычно такое управление реализуется через оператор case. Системы, управляемые событиями. В моделях централизованного управления, как правило, управление системой определяются значениями некоторых переменных её состояния. В противоположность таким моделям существуют системы, управление которыми основано на внешних событиях. В данном контексте 57

59 под событием подразумевается не только бинарный сигнал типа «да-нет». Здесь сигнал может принимать некоторый диапазон значений. Различие между событием и обычными входными данными заключается в том, что планирование события выходит за рамки управления процессом, обрабатывающим это событие. Для обработки события подсистеме необходим доступ к информации состояния, однако такая информация обычно не определяется потоком управления [7]. Основные модели систем, управляемых событиями [7]: 1. Модели передачи сообщений. В этих моделях событие представляет собой передачу сообщения всем подсистемам (рис. 4.4). Любая подсистема, которая обрабатывает данное событие, отвечает на него. 2. Модели, управляемые прерываниями. Такие модели обычно используются в системах реального времени, где внешние прерывания регистрируются обработчиком прерываний, а обрабатываются другим системным компонентом (рис. 4.5). Рис. 4.4 Рис. 4.5 Модульная декомпозиция. После этапа разработки системной структуры в процессе проектирования следует этап декомпозиции подсистем на модули. Между 58

60 разбивкой системы на подсистемы и подсистем на модули нет принципиальных отличий [7]. Однако компоненты модулей обычно меньше компонентов подсистем, поэтому можно использовать специальные модели декомпозиции. Рассмотрим две модели, используемые на этапе модульной декомпозиции подсистем [7]: 1. Объектно-ориентированная модель. Система состоит из набора взаимодействующих объектов. 2. Модель потоков данных. Система состоит из функциональных модулей, которые получают на входе данные и преобразуют их некоторым образом в выходные данные. Такой подход часто называется конвейерным. В объектно-ориентированной модели модули представляют собой объекты с собственными состояниями и определенными операциями над этими состояниями. В модели потоков данных модули выполняют функциональные преобразования. В обеих моделях модули реализованы либо как последовательные компоненты, либо как процессы. Объектные модели. Объектно-ориентированная архитектурная модель структурирует систему в виде совокупности слабо связанных объектов с четко определенными интерфейсами. Объекты вызывают сервисы, предоставляемые другими объектами. Преимущества объектно-ориентированного подхода хорошо известны. Поскольку объекты слабо связаны между собой, можно изменять реализацию того или иного объекта, не воздействуя на остальные объекты. Структуру системы легко понять, так как объекты часто являются объектами реального мира. Для непосредственной реализации системных компонентов можно использовать объектно-ориентированные языки программирования. Вместе с тем объектно-ориентированный подход имеет и недостатки. При использовании сервисов объекты должны явно ссылаться на имена других объектов и знать их интерфейс. Если при изменении системы требуется изменить интерфейс, необходимо оценить эффект от такого изменения с учетом всех пользователей изменяемого объекта. Многие объекты реального мира сложно представить в виде системных объектов. Модели потоков данных. В управляемой потоками данных модели данные проходят через последовательность преобразований. Каждый шаг обработки данных реализован в виде преобразования. Данные, поступающие на вход системы, проходят через все преобразования и достигают выхода системы. Преобразования могут выполняться последовательно или параллельно. Обработка данных может быть пакетной или поэлементной [7]. Если преобразования представлены в виде отдельных процессов, такую модель иногда называют конвейером или моделью фильтров. Последняя поддерживает конвейеры, которые действуют как хранилища данных, и набор команд, представляющих функциональные преобразования. Здесь используется термин 59

61 «фильтр», поскольку преобразование «фильтрует» данные во время обработки потока данных. Различные варианты модели потоков данных возникли вместе с появлением первых компьютеров, предназначенных для обработки данных. Когда преобразования последовательно обрабатывают пакеты данных, такая архитектурная модель называется пакетной последовательной моделью. Она является основой для многих классов систем обработки данных. Примером могут быть системы (например, системы обработки счетов), которые генерируют большое количество выходных отчетов, полученных с помощью несложных вычислений, но с большим количеством входных записей [7]. Проблемно-зависимые архитектуры Рассмотренные ранее архитектурные модели являются обобщенными. Они широко применяются для многих классов приложений. Наряду с основными моделями, используются архитектурные модели, характерные для конкретной предметной области приложения. Эти модели называются проблемно-зависимыми архитектурами [7]. Можно выделить два типа проблемно-зависимых архитектурных моделей [7]: 1. Модели классов систем. Отображают классы реальных систем, вобрав в себя основные характеристики этих классов. Как правило, архитектурные модели классов встречаются в системах реального времени, например в системах сбора данных, мониторинга и т.д. 2. Базовые модели. Более абстрактны и предоставляют разработчикам информацию об общей структуре какого-либо типа систем. Модели классов систем. Модель компилятора, вероятно, наиболее известный пример архитектурной модели класса систем. В настоящее время разработаны тысячи компиляторов. Считается, что компилятор должен включать перечисленные ниже модули [7]: 1. Лексический анализатор, транслирующий входной язык в некоторый внутренний код. 2. Таблица идентификаторов, выдаваемая лексическим анализатором, в которой содержится информация об используемых в программе именах и типах. 3. Синтаксический анализатор, который проверяет синтаксис компилируемого кода. Он использует заданную грамматику языка и создает синтаксическое дерево. 4. Синтаксическое дерево, которое представляет внутреннюю структуру компилируемой программы. 5. Семантический анализатор, который проверяет семантическую корректность программ на основании информации, полученной из синтаксического дерева и таблицы идентификаторов. Базовые архитектуры. Архитектурные модели классов систем отражают архитектуры уже существующих систем. В противоположность им базовые модели обычно появляются как результат исследований в определенной предметной об- 60

62 ласти приложения. Они представляют собой идеализированную архитектуру, в которой отражены особенности, присущие системам, работающим в данной предметной области Архитектура распределенных систем В настоящее время практически все большие программные системы являются распределенными. Распределенной называется такая система, в которой обработка информации сосредоточена не на одной вычислительной машине, а распределена между несколькими компьютерами [7]. Все современные программные системы можно разделить на три больших класса [7]: 1. Прикладные программные системы, предназначенные для работы только на одном персональном компьютере или рабочей станции. К ним относятся текстовые процессоры, электронные таблицы, графические системы и т.п. 2. Встроенные системы, предназначенные для работы на одном процессоре либо на интегрированной группе процессоров. К ним относятся системы управления бытовыми устройствами, различными приборами и др. 3. Распределенные системы, в которых программное обеспечение выполняется на слабо интегрированной группе параллельно работающих процессоров, связанных через сеть. К ним относятся системы банкоматов, принадлежащих какомулибо банку, издательские системы, системы ПО коллективного пользования и др. Основные характеристики распределенных систем следующие [7]: 1. Совместное использование ресурсов. Распределенные системы допускают совместное использование аппаратных и программных ресурсов, например жестких дисков, принтеров, файлов, компиляторов и т.п., связанных посредством сети. Очевидно, что разделение ресурсов возможно также в многопользовательских системах, однако в этом случае за предоставление ресурсов и их управление должен отвечать центральный компьютер. 2. Открытость. Это возможность расширять систему путем добавления новых ресурсов. Распределенные системы это открытые системы, к которым подключают аппаратное и программное обеспечение от разных производителей. 3. Параллельность. В распределенных системах несколько процессов могут одновременно выполняться на разных компьютерах в сети. Эти процессы могут (но не обязательно) взаимодействовать друг с другом во время их выполнения. 4. Масштабируемость. В принципе все распределенные системы являются масштабируемыми: чтобы система соответствовала новым требованиям, её можно наращивать посредством добавления новых вычислительных ресурсов. Однако на практике, наращивание может ограничиваться сетью, объединяющей отдельные компьютеры системы. Если подключить много новых машин, пропускная способность сети может оказаться недостаточной. 5. Отказоустойчивость. Наличие нескольких компьютеров и возможность дублирования информации означает, что распределенные системы устойчивы к определенным аппаратным и программным ошибкам. Большинство распределен- 61

63 ных систем в случае ошибки, как правило, могут поддерживать хотя бы частичную функциональность. Полный сбой в работе системы происходит только в случае сетевых ошибок. 6. Прозрачность. Это свойство означает, что пользователям предоставлен полностью прозрачный доступ к ресурсам и в то же время от них скрыта информация о распределении ресурсов в системе. Однако во многих случаях конкретные знания об организации системы помогают пользователю лучше использовать ресурсы. Задача разработчиков распределенных систем спроектировать программное или аппаратное обеспечение так, чтобы предоставить все необходимые характеристики распределенной системы. А для этого требуется знать преимущества и недостатки различных архитектур распределенных систем. Здесь выделяется два родственных типа архитектур распределенных систем [7]: 1. Архитектура клиент-сервер. В этой модели систему можно представить как набор сервисов, предоставляемых серверами клиентам. В таких системах серверы и клиенты значительно отличаются друг от друга. 2. Архитектура распределенных объектов. В этом случае между серверами и клиентами нет различий и систему можно представить как набор взаимодействующих объектов, местоположение которых не имеет особого значения. Между поставщиком сервисов и их пользователями не существует различий. Многопроцессорная архитектура Самой простой распределенной системой является многопроцессорная система. Она состоит из множества различных процессов, которые могут (но не обязательно) выполняться на разных процессорах. Данная модель часто используется в больших системах реального времени. Эти системы собирают информацию, принимают на её основе решения и отправляют сигналы исполнительному механизму, который изменяет системное окружение. В принципе все процессы, связанные со сбором информации, принятием решений и управлением исполнительным механизмом, могут выполняться на одном процессоре под управлением планировщика заданий. Использование нескольких процессоров повышает производительность системы и её способность к восстановлению. Распределение процессов между процессорами может переопределяться (присуще критическим системам) или же находиться под управлением диспетчера процессов [7]. Архитектура клиент-сервер В архитектуре клиент-сервер программное приложение моделируется как набор сервисов, предоставляемых серверами, ко множеству клиентов, использующих эти сервисы. Клиенты должны знать о доступных серверах, хотя могут и не иметь представления о существовании других клиентов (рис. 4.6). 62

64 Рис. 4.6 Самой простой архитектурой клиент-сервер является двухуровневая, в которой приложение состоит из сервера (или множества идентичных серверов) и группы клиентов. Существует два вида такой архитектуры [7]: 1. Модель тонкого клиента. В этой модели вся работа приложения и управление данными выполняются на сервере. На клиентской машине запускается только ПО уровня представления. 2. Модель толстого клиента. В этой модели сервер только управляет данными. На клиентской машине реализована работа приложения и взаимодействие с пользователем системы. Главный недостаток модели тонкого клиента большая загруженность сервера и сети. Все вычисления выполняются на сервере, а это может привести к значительному сетевому трафику между клиентом и сервером. В современных компьютерах достаточно вычислительной мощности, однако она практически не используется в модели тонкого клиента [7]. Напротив, модель толстого клиента использует вычислительную мощность локальных машин; уровень выполнения приложения и уровень представления помещаются на клиентский компьютер. Сервер здесь, по существу, является сервером транзакций. Применяются разные типы архитектуры клиент-сервер [7]: Двухуровневая архитектура тонкого клиента: наследуемые системы, в которых нецелесообразно разделять выполнение приложения и управления данными; приложения с интенсивными вычислениями, например компиляторы, но с незначительным объемом управления данными; приложения, в которых обрабатываются большие массивы данных (запросы), но с небольшим объемом вычислений в самом приложении. Двухуровневая архитектура толстого клиент: приложения, где пользователю требуется интенсивная обработка данных; приложения с относительно постоянным набором функций на стороне пользователя, применяемых в среде с хорошо отлаженным системным управлением. 63

65 Трехуровневая и многоуровневая архитектуры клиент-сервер: большие приложения с сотнями и тысячами клиентов; приложения, в которых часто меняются и данные, и методы обработки; приложения, в которых выполняется интеграция данных из многих источников. Архитектура распределенных объектов В модели клиент-сервер распределенной системы между клиентами и серверами существуют различия. Клиент запрашивает сервисы только у сервера, но не у других клиентов; серверы могут функционировать как клиенты и запрашивать сервисы у других серверов, но не у клиентов; клиенты должны знать о сервисах, предоставляемых определенными серверами, и о том, как взаимодействуют эти серверы. Такая модель отлично подходит ко многим типам приложений, но в то же время ограничивает разработчиков системы, которые вынуждены решать, где предоставлять сервисы. Они также должны обеспечить поддержку масштабируемости и разработать средства включения клиентов в систему на распределенных серверах [7]. Более общим подходом, применяемым в проектировании распределенных систем, является стирание различий между клиентом и сервером и проектирование архитектуры системы как архитектуры распределенных объектов. В этой архитектуре основными компонентами системы являются объекты, предоставляющие набор сервисов через свои интерфейсы (рис. 4.7). Другие объекты вызывают эти сервисы, не делая различий между клиентом (пользователем сервиса) и сервером (поставщиком сервиса) [7]. Объекты могут располагаться на разных компьютерах в сети и взаимодействовать посредством промежуточного ПО. По аналогии с системной шиной, которая позволяет подключать различные устройства и поддерживать взаимодействие между аппаратными средствами, промежуточное ПО можно рассматривать как шину программного обеспечения. Она предоставляет набор сервисов, позволяющий объектам взаимодействовать друг с другом, добавлять или удалять их из системы. Промежуточное ПО называют брокером запросов к объектам. Его задача обеспечивать интерфейс между объектами. Рис

66 Основные преимущества модели архитектуры распределенных объектов следующие [7]: Разработчики системы могут не спешить с принятием решений относительно того, где и как будут предоставляться сервисы. Объекты, предоставляющие сервисы, могут выполняться в любом месте (узле) сети. Следовательно, различие между моделями толстого и тонкого клиентов становятся несущественными, так как нет необходимости заранее планировать размещение объектов для выполнения приложения. Системная архитектура достаточно открыта, что позволяет при необходимости добавлять в систему новые ресурсы. В следующем разделе отмечается, что стандарты программной шины постоянно совершенствуются, что позволяет объектам, написанным на разных языках программирования, взаимодействовать и предоставлять сервисы друг другу. Гибкость и масштабируемость системы. Для того чтобы справиться с системными нагрузками, можно создавать экземпляры системы с одинаковыми сервисами, которые будут предоставляться разными объектами или разными экземплярами (копиями) объектов. При увеличении нагрузки в систему можно добавить новые объекты, не прерывая при этом работу других её объектов. Существует возможность динамически переконфигурировать систему посредством объектов, мигрирующих в сети по запросам. Объекты, предоставляющие сервисы, могут мигрировать на тот же процессор, что и объекты, запрашивающие сервисы, тем самым повышая производительность системы. В процессе проектирования систем архитектуру распределенных объектов можно использовать двояко [7]: 1. В виде логической модели, которая позволяет разработчикам структурировать и спланировать систему. В этом случае функциональность приложения описывается только в терминах и комбинациях сервисов. Затем разрабатываются способы предоставления сервисов с помощью нескольких распределенных объектов. На этом уровне, как правило, проектируют крупномодульные объекты, которые предоставляют сервисы, отражающие специфику конкретной области приложения. Например, в программу учета розничной торговли можно включить объекты, которые бы вели учет состояния запасов, отслеживали взаимодействие с клиентами, классифицировали товары и др. 2. Как гибкий подход к реализации систем клиент-сервер. В этом случае логическая модель системы это модель клиент-сервер, в которой клиенты и серверы реализованы как распределенные объекты, взаимодействующие посредством программной шины. При таком подходе легко заменить систему, например двухуровневую на многоуровневую. В этом случае ни сервер, ни клиент не могут быть реализованы в одном объекте, однако могут состоять из множества небольших объектов, каждый из которых предоставляет определенный сервис. 65

67 Объектно-ориентированное проектирование Объектно-ориентированное проектирование представляет собой стратегию, в райках которой разработчики системы вместо операций и функций мыслят в понятиях объекты. Программная система состоит из взаимодействующих объектов, которые имеют собственное локальное состояние и могут выполнять определенный набор операций, определяемый состоянием объекта (рис. 4.8). Объекты скрывают информацию о представлении состояний и, следовательно, ограничивают к ним доступ. Под процессом объектно-ориентированного проектирования подразумевается проектирование классов объектов и взаимоотношений между этими классами. Когда проект реализован в виде исполняемой программы, все необходимые объекты создаются динамически с помощью определений классов [7]. Рис. 4.8 Объектно-ориентированное проектирование только часть объектноориентированного процесса разработки системы, в которой на протяжении всего процесса создания ПО используется объектно-ориентированный подход. Этот подход подразумевает выполнение трех этапов [7]: Обьектно-ориентированный анализ создание объектноориентированной модели предметной области приложения ПО. Объектно-ориентированное проектирование разработка объектноориентированной модели системы ПО с учетом системных требований. Объектно-ориентированное программирование реализация архитектуры системы с помощью объектно-ориентированного языка программирования. Объектно-ориентированные системы можно рассматривать как совокупность автономных и в определенной мере независимых объектов. Изменение реализации какого-нибудь объекта или добавление новых функций не влияет на другие объекты системы. Часто существует четкое соответствие между реальными объ- 66

68 ектами (например, аппаратными средствами) и управляющими ими объектами программной системы. Такой подход облегчает понимание и реализацию проекта. Потенциально все объекты являются повторно используемыми компонентами, так как они независимо инкапсулируют данные о состоянии и операции. Архитектуру ПО можно разрабатывать на базе объектов, уже созданных в предыдущих проектах. Такой подход снижает стоимость проектирования, программирования и тестирования ПО. Кроме того, появляется возможность использовать стандартные объекты, что уменьшает риск, связанный с разработкой программного обеспечения. Объекты и классы объектов В настоящее время широко используются понятия объект и объектноориентированный. Эти термины применяются к различным типам объектов, методам проектирования, системам и языкам программирования. Во всех случаях применяется общее правило, согласно которому объект инкапсулирует данные о своем внутреннем строении. Это правило отражено в определении объекта и класса объектов [7]. Объект это нечто, способное пребывать в различных состояниях и имеющее определенное множество операций. Состояние определяется как набор атрибутов объекта. Операции, связанные с объектом, предоставляют сервисы (функциональные возможности) другим объектам (клиентам) для выполнения определенных вычислений. Объекты создаются в соответствии с определением класса объектов, которое служит шаблоном для создания объектов. В него включены объявления всех атрибутов и операций, связанных с объектом данного класса. Параллельные объекты. В общем случае объекты запрашивают сервис от любого объекта посредством передачи ему сообщения «запрос к сервису». Обычно нет необходимости в последовательном выполнении, при котором один объект ожидает завершения работы сервиса по сделанному запросу. Общая модель взаимодействия объектов позволяет их одновременное выполнение в виде параллельных процессов. Такие объекты могут выполняться на одном компьютере или на разных машинах как распределенные объекты. Существует два типа параллельных объектов [7]: 1. Серверы, в которых объект реализован как параллельный процесс с методами, соответствующими определенным операциям объекта. Методы запускаются в ответ на внешнее сообщение и могут выполняться параллельно с методами, связанными с другими объектами. По окончании всех действий выполнение объекта приостанавливается и он ожидает дальнейших запросов к сервису. 2. Активные объекты, у которых состояние может изменяться посредством операций, выполняющихся внутри самого объекта. Процесс, представляющий объект, постоянно выполняет эти операции, а следовательно, никогда не останавливается. 67

69 Процесс объектно-ориентированного проектирования Процесс объектно-ориентированного проектирования состоит из нескольких этапов [7]: 1. Определение рабочего окружения системы и разработка моделей её использования. 2. Проектирование архитектуры системы. 3. Определение основных объектов системы. 4. Разработка моделей архитектуры системы. 5. Определение интерфейсов объекта. Окружение системы и модели её использования. Первый этап в любом процессе проектирования состоит в выявлении взаимоотношений между проектируемым программным обеспечением и его окружением. Выявление этих взаимоотношений помогает решить, как обеспечить необходимую функциональность системы и как структурировать систему, чтобы она могла эффективно взаимодействовать со своим окружением [7]. Модель окружения системы и модель использования системы представляют собой две дополняющие друг друга модели взаимоотношений между данной системой и её окружением [7]: 1. Модель окружения системы это статическая модель, которая описывает другие системы из окружения разрабатываемого ПО. 2. Модель использования системы динамическая модель, которая показывает взаимодействие данной системы со своим окружением. Проектирование архитектуры. Когда взаимодействия между проектируемой системой ПО и её окружением определены, эти данные можно использовать как основу для разработки архитектуры системы. Конечно, при этом необходимо применять знания об общих принципах проектирования системных архитектур и данные о конкретной предметной области [7]. Определение объектов. Перед выполнением данного этапа проектирования уже должны быть сформированы представления относительно основных объектов проектируемой системы. Например, в системе «Метеостанция» приборы являются объектами, и требуется, по крайней мере, один объект на каждом уровне архитектуры. Это проявление основного принципа, согласно которому объекты обычно появляются в процессе проектирования. Вместе с тем требуется определить и документировать все другие объекты системы. Существует ряд подходов к определению классов объектов [7]: 1. Использование грамматического анализа естественного языкового описания системы. Объекты и атрибуты это существительные, операции и сервисы глаголы. Такой подход реализован в иерархическом методе объектноориентированного проектирования, который широко используется в аэрокосмической промышленности Европы. 2. Использование в качестве объектов ПО событий, объектов и ситуаций реального мира из области приложения, например самолетов, ролевых ситуаций менеджера, взаимодействий, подобных интерактивному общению на научных кон- 68

70 ференциях и т.д. Для реализации таких объектов могут потребоваться специальные структуры хранения данных (абстрактные структуры данных). 3. Применение подхода, при котором разработчик сначала полностью определяет поведение системы. Затем определяются компоненты системы, отвечающие за различные поведенческие акты (режимы работы системы), при этом основное внимание уделяется тому, кто инициирует и кто осуществляет данные режимы. Компоненты системы, отвечающие за основные режимы работы, считаются объектами. 4. Применение подхода, основанного на сценариях, в котором по очереди определяются и анализируются различные сценарии использования системы. Поскольку анализируется каждый сценарий, группа, отвечающая за анализ, должна идентифицировать необходимые объекты, атрибуты и операции. Метод анализа, при котором аналитики и разработчики присваивают роли объектам, показывает эффективность подхода, основанного на сценариях. Каждый из описанных подходов помогает начать процесс определения объектов. Но для описания объектов и классов объектов необходимо использовать информацию, полученную из разных источников. Объекты и операции, первоначально определенные на основе неформального описания системы, вполне могут послужить отправной точкой при проектировании. Затем для усовершенствования и расширения описания первоначальных объектов можно использовать дополнительную информацию, полученную из области применения ПО или анализа сценариев. Дополнительную информацию также можно получить в ходе обсуждения с пользователями разрабатываемой системы или анализа имеющихся систем. Модели архитектуры. Модели системной архитектуры показывают объекты и классы объектов, составляющих систему, и при необходимости типы взаимоотношений между этими объектами. Такие модели служат мостом между требованиями к системе и её реализацией. А это значит, что к данным моделям предъявлены противоречивые требования. Они должны быть абстрактными настолько, чтобы лишние данные не скрывали отношения между моделью архитектуры и требованиями к системе. Однако, чтобы программист мог принимать решения по реализации, модель должна содержать достаточное количество информации [7]. Эти противоречие можно обойти, разработав несколько моделей разного уровня детализации. Там, где существуют тесные рабочие связи между разработчиками требований, проектировщиками и программистами, можно обойтись одной обобщенной моделью. В этом случае конкретные решения по архитектуре системы можно принимать в процессе реализации системы. Когда связи между разработчиками требований, проектировщиками и программистами не такие тесные (например, если система проектируется в одном подразделении организации, а реализуется в другом), требуется более детализированная модель. Следовательно, в процессе проектирования важно решить, какие требуются модели и какой должна быть степень их детализации. Это решение зависит также от типа разрабатываемой системы. Систему последовательной обработки данных можно спроектировать на основе встроенной системы реального времени разными способами с использованием различных моделей архитектуры. Существует 69

71 множество систем, которым требуются все виды моделей. Но уменьшение числа созданных моделей сокращает расходы и время проектирования. Существует два типа объектно-ориентированных моделей системной архитектуры [7]: 1. Статические модели, которые описывают статическую структуру системы в терминах классов объектов и взаимоотношений между ними. Основными взаимоотношениями, которые документируются на данном этапе, являются отношения обобщения, отношения «используют-используются» и структурные отношения. 2. Динамические модели, которые описывают динамическую структуру системы и показывают взаимодействия между объектами системы (но не классами объектов). Документируемые взаимодействия содержат последовательность составленных объектами запросов к сервисам и описывают реакцию системы на взаимодействия между объектами. Специфицирование интерфейсов объектов. Важной частью любого процесса проектирования является специфицирование интерфейсов между различными компонентами системы. Интерфейсы необходимо определить так, чтобы объекты и другие компоненты можно было проектировать параллельно. Определив интерфейс, разработчики других объектов могут считать, что интерфейс уже реализован [7]. Модификация системной архитектуры Главное преимущество объектно-ориентированного подхода к проектированию системы состоит в том, что он упрощает задачу внесения изменений в системную архитектуру, поскольку представление состояния объекта не оказывает на нее никакого влияния изменение внутренних данных объекта не должно влиять на другие объекты системы. Более того, так как объекты слабо связаны между собой, обычно новые объекты просто вставляются без значительных воздействий на остальные компоненты системы Проектирование систем реального времени Введение В настоящее время компьютеры применяются для управления широким спектром разнообразных систем, начиная от простых домашних устройств и заканчивая крупными промышленными комплексами. Эти компьютеры непосредственно взаимодействуют с аппаратными устройствами. Программное обеспечение таких систем (управляющий компьютер плюс управляемые объекты) представляет собой встроенную систему реального времени, задача которой реагировать на события, генерируемые оборудованием, то есть в ответ на эти события вырабатывать управляющие сигналы. Такое ПО встраивается в большие аппаратные системы и должно обеспечивать реакцию на события, происходящие в окружении системы, в режиме реального времени [7]. 70

72 Система реального времени это программная система, которая должна реагировать на события в реальном масштабе времени, её корректное функционирование зависит не только от полученных результатов, но и от времени, в течение которого они получены. «Мягкая» система реального времени это система, в которой операции удаляются, если в течение определенного интервала времени не выдан результат. «Жесткая» система реального времени это система, операции которой становятся некорректными, то есть вырабатывается сигнал об ошибке, если в течение определенного интервала времени результат не выдан. На рис. 4.9 показана модель «сенсор система исполнительный механизм» для встроенной системы реального времени [7]. Рис. 4.9 Проектирование систем реального времени Процесс проектирования систем реального времени состоит из следующих этапов [7]: 1. Определение множества входных сигналов, которые будут обрабатываться системой, и соответствующих им системных реакций, то есть ответных сигналов. 2. Для каждого входного сигнала и соответствующего ему ответного сигнала вычисляются временные ограничения. Они применяются к обработке как входных, так и ответных сигналов. 3. Объединение процессов обработки входных и ответных сигналов в виде совокупности параллельных процессов. В корректной модели системной архитектуры каждый процесс связан с определенным классом входных и ответных сигналов. 4. Разработка алгоритмов, выполняющих необходимые вычисления для всех входных и ответных сигналов. Чтобы получить представление об объемах вычислительных и временных затрат в процессе обработки сигналов, разработка алгоритмов обычно проводится на ранних этапах процесса проектирования. 71

73 5. Разработка временного графика работы системы. 6. Сборка системы, работающей под управлением диспетчера управляющей программы. Моделирование систем реального времени. Системы реального времени должны реагировать на события, происходящие через нерегулярные интервалы времени. Такие события (или входные сигналы) часто приводят к переходу системы из одного состояния в другое. Поэтому одним из способов описания систем реального времени может быть модель конечного автомата и соответствующая диаграмма состояний [7]. Программирование систем реального времени. На архитектуру системы реального времени оказывает влияние язык программирования, который используется для реализации системы. До сих пор жесткие системы реального времени часто программируются на ассемблерных языках. Языки более высокого уровня также дают возможность сгенерировать эффективный программный код. Например, язык Си позволяет писать весьма эффективные программы. Однако в нем нет конструкций, поддерживающих параллельность процессов и управление совместно используемыми ресурсами. Кроме того, программы на С часто сложны для понимания [7]. Управляющие программы Управляющая программа (диспетчер) системы реального времени является аналогом операционной системы компьютера. Она управляет процессами и распределением ресурсов в системах реального времени, запускает и останавливает соответствующие процессы для обработки входных сигналов и распределяет ресурсы памяти и процессора. Однако обычно в управляющих программах отсутствуют более сложные средства, присущие операционным системам, например средства управления файлами [7]. Компоненты управляющей программы зависят от размеров и сложности проектируемой системы реального времени. Обычно управляющие программы состоят из следующих компонентов [7]: 1) часов реального времени, которые периодически предоставляют информацию для планирования процессов. 2) обработчика прерываний, который управляет апериодическими запросами к сервисам. 3) планировщика, который просматривает список процессов, которые назначены на выполнение, и выбирает один из них. 4) администратора ресурсов, который получив процесс, запланированный на выполнение, выделяет необходимые ресурсы памяти и процессора. 5) диспетчера, который запускает на выполнение какой-либо процесс. Управляющие программы для систем, предоставляющих сервисы на постоянной основе, например телекоммуникационных или мониторинговых систем с высокими требованиями к надежности, могут иметь еще несколько компонентов [7]: 72

74 1) конфигуратор, который отвечает за динамическое переконфигурирование аппаратных средств (не прекращая работу системы, из нее можно извлечь аппаратные модули и изменить систему посредством добавления новых аппаратных средств); 2) менеджер неисправностей, который отвечает за обнаружение аппаратных и программных неисправностей и предпринимает соответствующие действия по их исправлению. Управление процессами это выбор процесса на выполнение, выделение для него ресурсов памяти и процессора и запуск процесса. Периодическими называются процессы, которые должны выполняться через фиксированный предопределенный промежуток времени (например, при сборе данных или управлении исполнительными механизмами). Управляющая программа системы реального времени для определения момента запуска процесса использует свои часы реального времени. В большинстве систем реального времени есть несколько классов периодических процессов с разными периодами (интервалами времени между выполнением процессов) и длительностью выполнения. Управляющая программа должна быть способна в любой момент времени выбрать процесс, назначенный на выполнение [7]. Существует две основные стратегии планирования процессов [7]: 1. Невытесняющее планирование. Один процесс планируется на выполнение, он запускается и выполняется до конца или блокируется по каким-либо причинам, например при ожидании ввода данных. При таком планировании могут возникнуть проблемы, связанные с тем, что в случае нескольких процессов с разными приоритетами процесс с высоким приоритетом должен ждать завершения процесса с низким приоритетом. 2. Вытесняющее планирование. Выполнение процесса может быть приостановлено, если к сервису поступили запросы от процессов с более высоким приоритетом. Процесс с более высоким приоритетом имеет преимущество перед процессом с более низким уровнем приоритета, и поэтому ему выделяется процессор. Системы наблюдения и управления В настоящее время можно выделить несколько классов стандартных систем реального времени: мониторинговые системы (системы наблюдения), системы сбора данных, системы управления и др. Каждому типу систем соответствует особая структура процессов, поэтому при проектировании системы, как правило, архитектуру создают по одному из существующих стандартных типов [7]. Системы наблюдения и управления важный класс систем реального времени. Их основным назначением является проверка сенсоров (датчиков), предоставляющих информацию об окружении системы, и выполнение соответствующих действий в зависимости от поступившей от сенсоров информации. Системы наблюдения выполняют действия после регистрации особого значения сенсора. Системы управления непрерывно управляют аппаратными исполнительными механизмами на основании значений, получаемых от сенсоров [7]. 73

75 Системы сбора данных Эти системы представляют другой класс систем реального времени, которые обычно базируются на обобщенной архитектурной модели. Такие системы собирают данные с сенсоров в целях их последующей обработки и анализа. Данные, собранные с разных датчиков, помещаются в буфер, из которого затем извлекаются и обрабатываются. На мониторе оператора отображаются полученные данные. В системах реального времени, ведущих сбор и обработку данных, скорости выполнения и периоды процесса сбора и процесса обработки могут не совпадать. Если обрабатываются большие объемы данных, сбор данных может выполнятся быстрее, чем их обработка. Если же выполняются только простые вычисления, быстрее происходит обработка данных, а не их сбор. Чтобы сгладить разницу в скоростях сбора и обработки данных, в большинстве подобных систем для хранения входных данных используется специальные буферы [7] Проектирование с повторным использованием компонентов В большинстве инженерных разработок процесс проектирования основан на повторном использовании уже имеющихся компонентов. В таких сферах, как механика или электротехника, инженеры никогда не разрабатывают проект «с нуля». Их проекты базируются на компонентах, уже проверенных и протестированных в других системах. Как правило, это не только малые компоненты, например фланцы и клапаны, но также целые подсистемы, например двигатели, компрессоры или турбины [7]. Чтобы повторное использование ПО было эффективным, его необходимо учитывать на всех этапах процесса проектирования ПО или процесса разработки требований. Во время программирования возможно повторное использование на этапе подбора компонентов, соответствующих требованиям. Метод проектирования ПО, основанный на повторном использовании, предполагает максимальное использование уже имеющихся программных объектов. Такие объекты могут радикально различаться размерами [7]. Повторно используемые приложения. Можно повторно использовать целые приложения либо путем включения их в систему без изменения других подсистем, либо с помощью разработки семейств приложений, работающих на разных платформах и адаптированных к требованиям конкретных заказчиков. Повторно используемые компоненты. Можно повторно использовать компоненты приложений от подсистем до отдельных объектов. Например, система распознавания текста, разработанная как часть системы обработки текстов, может повторно использоваться в системах управления базами данных. Повторно используемые функции. Можно повторно использовать программные компоненты, которые реализуют отдельные функции, например математические. Основанный на стандартных библиотеках метод повторного использования применяется в программировании последние 40 лет. 74

76 Преимущества повторного использования ПО [7]: Повышение надежности. Компоненты, повторно используемые в других системах, оказываются значительно надежнее новых компонентов. Они протестированы и проверены в разных условиях работы. Ошибки, допущенные при их проектировании и реализации, обнаружены и устранены еще при первом их применении. Поэтому повторное использование компонентов сокращает общее количество ошибок в системе. Уменьшение проектных рисков. Для уже существующих компонентов можно более точно прогнозировать расходы, связанные с их повторным использованием, чем расходы, необходимые на их разработку. Такой прогноз важный фактор администрирования проекта, так как позволяет уменьшить неточности при предварительной оценке сметы проекта Эффективное использование специалистов. Часть специалистов, выполняющих одинаковую работу в разных проектах, может заниматься разработкой компонентов для их дальнейшего повторного использования, эффективно применяя накопленные ранее знания. Соблюдение стандартов. Некоторые стандарты, такие как стандарты интерфейса пользователя, можно реализовать в виде набора стандартных компонентов. Например, можно разработать повторно используемые компоненты для реализации различных меню пользовательского интерфейса. Все приложения предоставляют меню пользователям в одном формате. Использование стандартного пользовательского интерфейса повышает надежность систем, так как, работая со знакомым интерфейсом, пользователи совершают меньше ошибок. Ускорение разработки. Часто для успешного продвижения системы на рынке необходимо как можно более раннее её появление, причем независимо от полной стоимости её создания. Повторное использование компонентов ускоряет создание систем, так как сокращается время на их разработку и тестирование. Повторное использование, основанное на генераторах программ, возможно только в том случае, когда можно идентифицировать предметные абстракции и их отображение в исполняемый код. Вот предметные области, в которых применение такого подхода может быть успешным [7]: 1. Генераторы приложений для обработки экономических данных. На входе генератора описание приложения или диалоговая система, где пользователь определяет экранные формы и способы обработки данных. На выходе программа на каком-либо языке программирования, например C++ или SQL. 2. Генераторы программ синтаксического анализатора. На входе генератора грамматическое описание языка, на выходе программа грамматического разбора языковых конструкций. 3. Генераторы кодов CASE-средства. На входе генераторов архитектура ПО, а на выходе программная реализация проектируемой системы. Разработка ПО с использованием программных генераторов экономически выгодна, однако существенно зависит от полноты и корректности определения абстракций предметной области. Главное преимущество этого подхода состоит в относительной легкости разработки программ с помощью генераторов. 75

77 Проектирования интерфейса пользователя Введение Проектирование вычислительных систем охватывает широкий спектр проектных действий от проектирования аппаратных средств до проектирования интерфейса пользователя. Грамотно спроектированный интерфейс крайне важен для успешной работы системы. Сложный в применении интерфейс, как минимум, приводит к ошибкам пользователя. Иногда они просто отказываются работать с программной системой, несмотря на её функциональные возможности. Если информация представляется сбивчиво или непоследовательно, пользователи могут понять её неправильно, в результате чего их последующие действия могут привести к повреждению данных или даже к сбою в работе системы [7]. Все современные персональные компьютеры поддерживают графический интерфейс пользователя (graphical user interface GUI), который подразумевает использование цветного графического экрана с высоким разрешением и позволяет работать с мышью и клавиатурой. Основные элементы GUI следующие [7]: Окна. Позволяют отображать на экране информацию разного рода. Пиктограммы. Представляют различные типы данных. В одних системах пиктограммы представляют файлы, в других процессы. Меню. Ввод команд заменяется выбором команд из меню. Указатели. Мышь используется как устройство указания для выбора команд из меню и для выделения отдельных элементов в окне Графические элементы. Могут использоваться совместно с текстовыми. Принципы проектирования интерфейсов пользователя Разработчики интерфейсов всегда должны учитывать физические и умственные способности людей, которые будут работать с программным обеспечением. Основой принципов проектирования интерфейсов пользователя являются человеческие возможности [7]. Базовые принципы проектирования интерфейсов пользователя [7]: Учет знаний пользователя. В интерфейсе необходимо использовать термины и понятия, взятые из опыта будущих пользователей системы. Согласованность. Интерфейс должен быть согласованным в том смысле, что однотипные операции должны выполняться одним и тем же способом. Минимум неожиданностей. Поведение системы должно быть прогнозируемым. Способность к восстановлению. Интерфейс должен иметь средства, позволяющие пользователям восстановить данные после ошибочных действий. Руководство пользователя. Интерфейс должен предоставлять необходимую информацию в случае ошибок пользователя и поддерживать средства контекстно-зависимой справки. 76

78 Учет разнородности пользователей. В интерфейсе должны быть средства для удобного взаимодействия с пользователями, имеющими разный уровень квалификации и различные возможности. В интерфейсах должны быть средства, по возможности предотвращающие ошибки пользователя, а также позволяющие корректно восстановить информацию после ошибок. Эти средства бывают двух видов [7]: 1. Подтверждение деструктивных действий. Если пользователь выбрал потенциально деструктивную операцию, то он должен еще раз подтвердить свое намерение. 2. Возможность отмены действий. Отмена действия возвращает систему в то состояние, в котором она находилась до их выполнения. Не лишней будет поддержка многоуровневой отмены действий, так как пользователи не всегда сразу понимают, что совершили ошибку. Взаимодействие с пользователем Существует пять основных стилей взаимодействия программного обеспечения с оператором ЭВМ [7]: 1. Непосредственное манипулирование. Пользователь взаимодействует с объектами на экране. Например, для удаления файла пользователь просто перетаскивает его в корзину. 2. Выбор из меню. Пользователь выбирает команду из списка пунктов меню. Очень часто выбранная команда воздействует только на тот объект, который выделен на экране. При таком подходе для удаления файла пользователь сначала выбирает файл, а затем команду на удаление. 3. Заполнение форм. Пользователь заполняет поля экранной формы. Некоторые поля могут иметь свое меню (выпадающее меню или списки). В форме могут быть командные кнопки, при щелчке мышью на которых инициируют некоторое действие. Чтобы удалить файл с помощью интерфейса, основанного на форме, надо ввести в поле формы имя файла и затем щелкнуть на кнопке удаления, присутствующей в форме. 4. Командный язык. Пользователь вводит конкретную команду с параметрами, чтобы указать системе, что она должна дальше делать. Чтобы удалить файл, пользователь вводит команду удаления с именем файла в качестве параметра этой команды. 5. Естественный язык. Пользователь вводит команду на естественном языке. Чтобы удалить файл, пользователь может ввести команду «удалить файл с именем XXX». Представление информации В любой интерактивной системе должны быть средства для представления данных пользователям. Данные в системе могут отображаться по-разному: например, вводимая информация может отображаться непосредственно на дисплее 77

79 (как, скажем, текст в текстовом редакторе) или преобразовываться в графическую форму. Хорошим тоном при проектировании систем считается отделение представления данных от самих данных [7]. Чтобы найти наилучшее представление информации, необходимо знать, с какими данными работают пользователи и каким образом они применяются в системе. Принимая решение по представлению данных, разработчик должен учитывать ряд факторов [7]: 1. Что нужно пользователю точные значения данных или соотношения между значениями? 2. Насколько быстро будут происходить изменения значений данных? Нужно ли немедленно показывать пользователю изменение значений? 3. Должен ли пользователь предпринимать какие-либо действия в ответ на изменение данных? 4. Нужно ли пользователю взаимодействовать с отображаемой информацией посредством интерфейса с прямым манипулированием? 5. Информация должна отображаться в текстовом (описательно) или числовом формате? Важны ли относительные значения элементов данных? Использование в интерфейсах цвета. Во всех интерактивных системах, независимо от их назначения, поддерживаются цветные экраны, поэтому в пользовательских интерфейсах часто используются различные цвета. В некоторых системах цвета применяют в основном для выделения определенных элементов (например, в текстовых редакторах для выделения фрагментов текста); в других системах (таких, как системы автоматического проектирования) цветами обозначают разные уровни проектов [7]. Правильное использование цветов делает интерфейс пользователя более удобным для понимания и управления. Вместе с тем использование цветов может быть неправильным, в результате чего создаются интерфейсы, которые визуально неприглядны и даже провоцируют ошибки. Основным принципом разработчиков интерфейсов должно быть осторожное использование цветов на экранах. Наиболее важные правила эффективного использования цвета в пользовательских интерфейсах следующие [7]: 1. Использовать ограниченное количество цветов. Для окон не следует использовать более четырех или пяти разных цветов, в интерфейсе системы не должно быть более семи цветов. 2. Использовать разные цвета для показа изменений в состоянии системы. Если на экране изменились цвета, значит, произошло какое-то событие. Выделение цветом особенно важно в сложных экранах, в которых отображаются сотни разных объектов. 3. Используйте цветовое кодирование для помощи пользователю. Если пользователям необходимо выделять аномальные элементы, выделите их цветом; если требуется найти подобные элементы, выделите их одинаковым цветом. 4. Использовать цветовое кодирование продуманно и последовательно. Если в какой-либо части системы сообщения об ошибке отображаются, например, красным цветом, то во всех других частях подобные сообщения должны отображаться 78

80 таким же цветом. Тогда красный цвет не следует использовать где-либо еще. Если же красный цвет используется еще где-то в системе, пользователь может интерпретировать появление красного цвета как сообщение об ошибке. Следует помнить, что у определенных типов пользователей имеются свои представления о значении отдельных цветов. 5. Осторожно использовать дополняющие цвета. Физиологические особенности человеческого глаза не позволяют одновременно сфокусироваться на красном и синем цветах. Поэтому последовательность красных и синих изображений вызывает зрительное напряжение. Некоторые комбинации цветов также могут визуально нарушать или затруднять чтение. Средства поддержки пользователя Интерфейс пользователя должен всегда обеспечивать некоторый тип оперативной справочной системы. Справочные системы один из основных аспектов проектирования интерфейса пользователя. Справочную систему приложения составляют [7]: сообщения, генерируемые системой в ответ на действия пользователя; диалоговая справочная система; документация, поставляемая с системой. Сообщения об ошибках. Первое впечатление, которое пользователь получает при работе с программной системой, основывается на сообщениях об ошибках. Неопытные пользователи, совершив ошибку, должны понять появившееся сообщение об ошибке [7]. Диалоговая справочная система. При получении сообщения об ошибке пользователь часто не знает, что делать, и обращается к справочной системе за информацией. Справочная система должна предоставлять разные типы информации: как ту, что помогает пользователю в затруднительных ситуациях, так и конкретную информацию, которую ищет пользователь. Для этого справочная система должна иметь разные средства и разные структуры сообщений [7]. Документация пользователя. Документация не является частью пользовательского интерфейса, однако проектирование оперативной справочной поддержки вместе с документацией является хорошим правилом. Системные руководства предоставляют более подробную информацию, чем диалоговые справочные системы, и строятся так, чтобы быть полезными пользователям разного уровня [7]. Для того чтобы документация, поставляемая совместно с программной системой, была полезна всем системным пользователям, она должна содержать пять описанных ниже документов [7]: 1. Функциональное описание, в котором кратко представлены функциональные возможности системы. Прочитав функциональное описание и вводное руководство, пользователь должен определить, та ли это система, которая ему нужна. 2. Документ по инсталляции системы, в котором содержится информация по установке системы. Здесь должны быть сведения о дисках, на которых поставляется система, описание файлов, находящихся на этих дисках, и минимальные тре- 79

81 бования к конфигурации. В документе должна быть инструкция по инсталляции и более подробная информация по установке файлов, зависящих от конфигурации системы. 3. Вводное руководство, представляющее неформальное введение в систему, описывающее её «повседневное» использование. В этом документе должна содержаться информация о том, как начать работу с системой, как использовать общие возможности системы. Все описания должны быть снабжены примерами и содержать сведения о том, как восстановить систему после ошибки и как начать заново работу. 4. Справочное руководство, в котором описаны возможности системы и их использование, представлен список сообщений об ошибках и возможные причины их появления, рассмотрены способы восстановления системы после выявления ошибок. 5. Руководство администратора, необходимое для некоторых типов программных систем. В нем дано описание сообщений, генерируемых системой при взаимодействии с другими системами, и описаны способы реагирования на эти сообщения. Если в систему включена аппаратная часть, то в руководстве администратора должна быть информация о том, как выявить и устранить неисправности, связанные с аппаратурой, как подключить новые периферийные устройства и т.п. Оценивание интерфейса Оценивание интерфейса процесс, в котором оценивается удобство использования интерфейса и степень его соответствия требованиям пользователя [7]. Оценивание проводится в соответствии со следующими показателями удобства использования интерфейса [7]: Изучаемость. Количество времени обучения, необходимое для начала продуктивной работы с системой. Скорость работы. Скорость реакции системы на действия пользователя. Устойчивость. Устойчивость системы к ошибкам пользователя. Восстанавливаемость. Способность системы восстанавливаться после ошибок пользователя. Адаптируемость. Способность системы «подстраиваться» к разным стилям работы пользователей. 80

82 5. ПОДГОТОВКА К ЗАЩИТЕ ДИПЛОМНОГО ПРОЕКТА 5.1. Материалы, необходимые для защиты дипломного проекта Примерно за несколько дней до защиты дипломного проекта студенту необходимо собрать следующие материалы: 1) текст пояснительной записки; 2) листы утверждения: а) текст программы, б) описание программы, в) руководство оператора, г) руководство системного программиста; 3) плакаты; 4) текст выступления на мин; 5) отзыв руководителя и рецензию на дипломный проект; 6) письменные ответы на вопросы, замечания, содержащиеся в отзыве и рецензии, а также ответы на возможные вопросы; 7) слайды, кино-, фото- и видеоматериалы, компьютерные диски, платы, технические устройства и так далее Подготовка студента к публичному выступлению Культура речи докладчика «Кто не умеет говорить, тот карьеры не сделает», так говорил Наполеон Бонапарт, которому ораторское мастерство помогло реализовать свои амбиции и совершить головокружительную карьеру от бригадного генерала до императора. Грамотный, хорошо написанный доклад, который с изяществом и достоинством исполнен, произведет благоприятное впечатление на членов ГЭК и запомнится им, что позволит защитить диплом на отличную или хорошую оценку. Организация выступления Успешное выступление содержит не только хорошо подобранный материал, но и неопровержимые аргументы и доказательства. Такое выступление демонстрирует глубокое знание оратором темы и свободную ориентацию в сложных вопросах [2, 4]. Прежде всего, нельзя пренебрегать вступительной и заключительной частями выступления. С самого начала выступление должно вызывать интерес у слушателей, знакомить их с основным содержанием и идеями дипломного проекта. В итоговой части опытный докладчик еще раз кратко повторит ключевые моменты и смысл всего выступления. Основная часть доклада, идущая сразу же после вступительной части, содержит в себе суть дипломного проекта и описание всего процесса его разработки. Рубрики основной части должны быть тщательно обдуманы. При раскрытии основного содержания дипломного проекта невозможно держать аудиторию долгое время в напряжении, «выплескивая» на нее непрерывный поток информации. Здесь нужен 81

83 особый подход стремление «слиться» с аудиторией, сделать ее частью своего выступления [2, 4]. Чтобы добиться ясности и уверенности, что идеи дипломного проекта поняты и приняты присутствующими, необходимо излагать свои мысли точно, легко и просто, так, чтобы они дошли до всех слушателей. Организация самого выступления предусматривает компоновку разрозненных частей единого монолитного доклада. Выступление должно быть достаточно продолжительным, чтобы охватить все намеченные докладчиком вопросы. В целом, продолжительность доклада около 10 мин. Большинство присутствующих просто не в состоянии воспринять насыщенный поток информации, обрушивающейся на них. Однако содержание выступления, состоящего из четырех или шести основных аспектов, почти всегда дойдет до сознания слушателей и закрепится у них в мозгу. Вся несущественная информация, повторяющая одна другую или слишком углубляющаяся в детали, должна быть изъята из текста выступления [2, 4]. По завершении выступления у слушателей должно сложиться и укрепиться впечатление об ораторе и его личности. Для этого ему следует в заключение еще раз вернуться к основной идее своего доклада. Если выступающий ожидает каких-либо действий или реакции на выступление, то еще до окончания доклада он должен предупредить об этом присутствующих в зале, иногда открыто спросив их мнение и предложив высказаться. Хороший оратор всегда репетирует свое выступление, многократно повторяя мысли, которые он хочет донести до аудитории. Как только материал собран и распределен по пунктам, следует приступать к оценке его содержания. В это понятие входят анализ фактического материала, проработка форм и способов его подачи и уточнение личного отношения к нему самого выступающего [2, 4]. Язык выступления Для того, чтобы вызвать интерес у аудитории и удержать внимание присутствующих до конца выступления, нужно использовать всё богатство языка, быть внимательным к качеству и силе используемых слов. Большинство людей фиксируют факт, что язык выступающего был крайне интересен и профессионален, и помнят данный факт, однако мало кто в состоянии точно определить, в чем же конкретно заключался этот профессионализм. Существует десять основных правил, которые позволят докладчику сформировать позитивное отношение аудитории [2, 4]: Докладчик должен быть простым в общении. Докладчик должен быть открытым и четким в выражении своих мыслей. Необходимо пытаться раскрыть различные аспекты дипломного проекта под разным углом зрения. Докладчик должен быть конкретным. Докладчик должен быть понятным. Необходимо ссылаться на факты и апеллировать к здравому смыслу. 82

84 Докладчик должен быть личностью. Не надо бояться употреблять индивидуальные, присущие только собственной речи слова и выражения. Докладчик должен быть уравновешенным. Необходимо использовать плавный ритм речи, избегать предложений и тем, отвлекающих от раскрытия основной идеи выступления. Докладчик должен быть энергичным. Нельзя употреблять большое количество вступительных слов и идиоматических выражений. Необходимо избегать пустословия. Докладчик должен быть целенаправленным. Аудитория придает значение лишь тому, что она слышит, и намерения докладчика, если они не подкреплены весомыми словами, не вызовут у слушателей особого восприятия. Докладчик должен быть красноречивым. Время от времени необходимо употреблять риторические фразы и выражения, что усилит эффект выступления. Докладчик должен адаптироваться к ситуации. Необходимо изучать слушательскую аудиторию, попытаться приспособить доклад к её потребностям и надеждам. Представление доклада Уже с самого начала выступления докладчик должен установить контакт с аудиторией. Как он двигается, в какой позе стоит, зрительный контакт, выражение его лица, движения рук и, наконец, одежда все это мгновенно оценивается аудиторией. Значение имеют также и внутренние импульсы оратора, его психологическое воздействие на публику. Если докладчик произносит слов в минуту, то он сможет продержать слушателей в напряжении в течение всего выступления, особенно если при этом используются разнообразные интонации и модуляции голоса, придающие словам дополнительный смысл и силу. Тембр и модуляция голоса зачастую свидетельствуют о том, верит ли человек в то, о чем говорит, или нет [2, 4]. Чтобы успешно защитить дипломный проект, нужно постараться избавиться от нервозности, произнести вдохновенную речь, донести до сознания слушателей живым и энергичным языком смысл дипломного проекта, его основную идею. Простой, не слишком напористый, привычный и свободный стиль речи должен привлечь внимание и интерес слушателей, а изменения тембра голоса и манеры подачи материала еще больше усилят симпатии публики и заставят ее слушать с повышенным вниманием и отдачей. Для того, чтобы использовать технику ораторского искусства, овладеть голосовыми возможностями, нужно тщательно готовить и репетировать речь выступления. Если выступающий стремится выглядеть естественно, ему следует [2, 4]: выучить наизусть текст своего выступления; верить в то, что он говорит; быть уверенным в своих способностях и умении взаимодействовать с аудиторией; обладать хорошей дикцией и страстным желанием защитить дипломный проект. 83

85 Использование плакатов Одни только слова не в состоянии сделать выступление полноценным и донести до слушателей смысл дипломного проекта. Плакаты помогут в этом и станут важной частью выступления. Они позволят выделить или подчеркнуть важнейшие идеи, уточнить содержание проблем и качество взаимоотношений. Плакаты также могут оказаться очень полезными, когда выступающий конструирует выводы на основе многочисленных фактов, приводит цифры, статистические материалы и аргументы в подтверждение своих идей, анализа тенденций и направлений развития [2, 4]. Однако, при подаче доклада, выступающий обязан проследить, чтобы его хорошо подготовленная речь не затерялась в бесконечных цифровых данных и чертежах. Плакаты никогда не смогут полностью заменить живое красноречивое выступление. Основные выводы и рекомендации по культуре речи 1. Доклад должен быть простым, кратким и понятным. 2. Необходимо использоваться ясный технический язык, не увлекаться клише и идиоматическими выражениями. 3. Необходимо говорить понятно, вслушиваясь в смысл произносимых слов; прислушиваться к себе. 4. Нужно говорить несколько медленнее обычного, использовать модуляции и тембр голоса, которые акцентировали бы внимание на сути темы, подчеркивали отдельные её аспекты. 5. Следует использовать эффект паузы. Краткое молчание и тишина могут оказаться очень эффективными и привлекающими внимание. 6. Не реагировать на внешние раздражители и посторонний шум. 7. При использовании плакатов и наглядных пособий необходимо помнить, что они являются лишь иллюстративным материалом. Главное в докладе личность докладчика и его речь. 8. Не злоупотреблять статистикой и цифрами. 9. Необходимо прибегать к примерам и конкретными фактам, что поможет подкрепить правоту провозглашаемых идей. 10. Нужно избегать жаргона. 11. В конце выступления необходимо еще раз вернуться к основным пунктам и идеям доклада. 12. Когда выступление закончено необходимо убедиться, что все присутствующие это поняли. 13. Нельзя поощрять провокационных и не имеющих отношения к тематике доклада вопросов Невербальное поведение во время выступления Известно, что первое впечатление о человеке складывается достаточно быстро. Специалисты считают, что для определения степени привлекательности человека и формирования к нему отношения достаточно лишь четырех минут общения. Прак- 84

86 тика доказывает, что около 55% сигналов от собеседника воспринимается благодаря мимике и жестам; 30% информации доходит вместе с интонацией собеседника. Немаловажную роль играет также то, с какой скоростью говорит человек. Оценивается также, как человек одевается. Невербальное поведение докладчика может иметь позитивную или негативную окраску и является критерием доверия или недоверия, искренности или неискренности, уверенности или неуверенности. Чтобы освоить правила грамотного невербального поведения студенту необходимо [2, 4]: 1. Научиться вести себя таким образом, чтобы, с одной стороны, быть понятным членам ГЭК, а с другой стороны, давать о себе желательную невербальную информацию. 2. Научиться понимать невербальный язык членов ГЭК. Умение вести себя так, чтобы аудитория восприняла выступление адекватно, является необходимым условием успешной защиты дипломного проекта. Если человеку уже доводилось выступать перед большой аудиторией, то, возможно, ему знакомо ощущение, что неожиданно начинают деревенеть ноги, некуда деть руки, лицо превращается в застывшую маску, а голос начинает предательски дрожать. Поэтому к защите нужно подготовиться, а не полагайтесь на свое обаяние и природную остроту ума. Часто написанный текст доклада хорош только сам по себе, студентудипломнику трудно воспроизвести его, поскольку текст не соответствует его личностным особенностям, манере выражаться. Поэтому в процессе подготовки к публичному выступлению необходимо обязательно отрабатывать произнесение речи как индивидуально перед зеркалом, так и перед аудиторией знакомыми или родственниками. Необходимо шлифовать речь доклада, учиться действовать экспромтом, находить контакт с аудиторией, участвовать в дискуссии, отвечать на «каверзные» вопросы. Репетиции студента-дипломника должны быть направлены на отработку следующих приемов [2, 4]: Предварительное установление контакта с аудиторией. Выступление необходимо начать с установления визуального контакта с аудиторией. Еще до того, как произнесены первые слова, необходимо сделать паузу и обвести глазами аудиторию. При этом у присутствующих сложится ощущение, что докладчик поздоровался с каждым лично. Обращение к аудитории. При докладе необходимо обращаться к членам комиссии, поддерживать с ними визуальный контакт. Ни в коем случае нельзя поворачиваться с слушателям спиной. Уважение чужих границ. Докладчику необходимо не нарушать личное пространство аудитории не подходить близко к столам членов комиссии (минимальное расстояние около 1,5 м). Язык тела. Идеальная поза для публичного выступления: спина прямая, голова слегка приподнята, ноги расставлены таким образом, чтобы положение докладчика было максимально устойчивым и комфортным, центр тяжести был немного смещен вперед, как будто человек готовится сделать шаг. Такая поза показывает ак- 85

87 тивную, лидерскую позицию и позволяет добиться наибольшего влияния на аудиторию. При выступлении и ответах на вопросы нельзя прохаживаться около плакатов. Язык жестов. Движения должны быть естественными. Если за человеком водится привычка совершать руками мелкие нефункциональные движения, то репетировать выступление необходимо с тяжелыми книгами в руках. Несколько таких репетиций навсегда отсекают подобную жестикуляцию. Общая рекомендация по жестам: жесты руками лучше вообще не делать, руками не размахивать. При выступлении студент держит в правой руке указку, в левой текст доклада. Движения совершаются медленно как в замедленном кадре. Лучше не поднимать руки выше пояса. Ни в коем случае нельзя подносить руки к лицу или трогать лицо или волосы, поскольку это жесты неуверенности в себе. Нельзя стоять со скрещенными руками, поскольку они создают физический барьер и говорят собеседнику: «Я Вам не доверяю». Вариант этого жеста человек правой рукой держится за полу пиджака или за другую руку. Жесты членов государственной экзаменационной комиссии [2, 4]: теребит мочку уха «Продолжайте, я Вас внимательно слушаю»; изучает свой манжет или ремешок от часов скучает (студент ему неинтересен); сидит, откинувшись назад, хочет послушать, что докладчик ему скажет; отклоняется назад, сложив руки за головой, хочет, чтобы студент убедил его; неожиданно потирает подбородок заинтересован тем, что говорит студент; наклоняется вперед и потирает руки очень заинтересован тем, что говорит студент; поднимает вверх указательный палец достойно оценивает сказанное. Рекомендации в отношении одежды. В народе говорят: «Встречают по одежке провожают по уму». Поэтому, направляясь на защиту дипломного проекта, лучше придерживаться делового классического стиля одежды, основные черты которого: солидность, уверенность в себе, внушение доверия, привлекательность [6]: мужской вариант темный костюм, белая сорочка, красивый галстук, черные туфли; женский вариант темная юбка, белая блузка, колготки и модельные туфли. Однако все-таки трудно дать определенный совет в отношении одежды, поскольку многое зависит от индивидуальных особенностей человека. Существенно лишь то, чтобы человек себя комфортно чувствовал, и выполнялись следующие требования [6]: одежда должна быть в хорошем состоянии, чистой и хорошо отглаженной; обувь должна быть начищена до блеска Подготовка к ответам на вопросы Нельзя определенно знать, какие вопросы зададут студенту во время защиты дипломного проекта. Однако, готовясь к защите, можно повысить свои шансы, упраж- 86

88 няясь в ответах на некоторые общие вопросы. Обоснованность и краткость в ответах важное достоинство студента-дипломника. Прежде чем заговорить, необходимо сделать небольшую паузу, которая только подчеркнет вдумчивость докладчика. Нельзя перескакивать с одной темы на другую, напрасно теряя время. Слушателей больше интересует качество, а не количество ответов [3]. Необходимо внимательно слушать, о чем спрашивают члены комиссии, и быть готовым к вопросам, на которые трудно ответить. Как только вопрос задан на него необходимо дать ответ. Нельзя позволять слушателям задавать сразу много вопросов, а потом уже пытаться отвечать на них. Студент должен работать в режиме «вопрос-ответ». Если вопрос непонятен, то необходимо переспросить. Отвечать на непонятные вопросы значит защитить диплом на низкую оценку [3]. Возможно, члены комиссии захотят посмотреть, как студент отвечает в ситуации прессинга. Не поддавайтесь на провокации. Ведите себя достойно и уверенно. Отвечая на вопросы, внимание членов комиссии необходимо постоянно обращать на плакаты, поскольку они содержат в наглядной и концентрированной форме наиболее значимые результаты проделанной работы Процедура публичной защиты дипломного проекта Защита дипломного проекта происходит публично на заседании государственной экзаменационной комиссии. Такая защита должна носить характер дискуссии и проходить в обстановке высокой требовательности, принципиальности и соблюдения этики, при этом обстоятельному анализу должны подвергаться достоверность и обоснованность всех полученных выводов и результатов работы. Заседание ГЭК начинается с того, что секретарь объявляет о защите дипломного проекта, называя автора и тему, при этом говорится об отзыве и рецензии на работу. Затем слово предоставляется дипломнику. Особенно важно, чтобы речь дипломника была ясной, грамматически точной, уверенной, что делает её понятной и убедительной. Это вовсе не означает, что выступление готовится в какой-то упрощенной форме, учитывая, что состав ГЭК представлен специалистами различных направлений, которые иногда весьма далеки от тематики защищаемого дипломного проекта. Наоборот, студент должен поставить себе задачу сделать доклад строго техническим, хорошо аргументированным по содержанию. Тогда выступление будет понятно широкой аудитории специалистов. Речь дипломника должна быть не только ясной для понимания и уверенной, но и выразительной, что зависит от темпа, громкости и интонации. Если человек говорит торопливо, проглатывая окончания слов или очень тихо и невнятно, то качество выступления резко снижается. Спокойная, неторопливая манера изложения всегда импонирует слушателям. Совершенно недопустимо нарушение норм литературного произношения, в частности, употребление неправильных ударений в словах. Можно дать несколько советов, помогающих читать текст доклада [3]: все цифры в тексте записываются прописью, чтобы во время защиты не пришлось считать нули; 87

89 выделяемые слова подчеркиваются; делаются большие поля при печатании, чтобы можно было дополнить речь своими замечаниями; существительные повторяются, следует избегать местоимений; используются простые слова и простые утвердительные предложения; текст не перегружается подчиненными предложениями. Выбор одежды, позы при выступлении с докладом, а также жестов, манер и других внешних форм поведения являются важными для студента. Известная элегантность, аккуратность, подтянутость в одежде способствует благоприятному впечатлению и расположению со стороны членов комиссии. Дипломник произносит речь, стоя у плакатов, обращая на них внимание при помощи указки. Неприглядное впечатление оставляет тот, кто во время выступления прохаживается возле стола с членами комиссии или поворачивается спиной к слушателям [3]. После окончания выступления члены ГЭК могут задать любые вопросы по теме дипломного проекта, уточнить результаты работы и задать все те вопросы, которые их интересуют. Отвечая на вопросы, нужно касаться только существа дела. Дипломнику следует проявлять скромность в оценке полученных результатов и тактичность по отношению к членам комиссии. Прежде чем отвечать на вопрос, необходимо внимательно выслушать оппонента. При этом надо учитывать, что четкий, логичный и аргументированный ответ на предыдущий вопрос может исключить последующий. Какой бы остротой и резкостью не отличались замечания, дипломник обязан вести дискуссию на высоком экономическом и техническом уровне, проявлять выдержку и корректность. После ответов на вопросы процедура защиты заканчивается. Члены комиссии выставляют оценки в ведомость, и подводится суммарная оценка за дипломный проект. 88

90 БИБЛИОГРАФИЧЕСКИЙ СПИСОК 1. Инструкция о порядке подготовки и издания внутривузовской литературы / составители: Т.И. Парубочая, Г.А. Никитин, В.И. Кокорев, Е.В. Гераскина. Челябинск: Изд-во ЮУрГУ, с. 2. Королько, В.Г. Основы паблик рилейшнз / В.Г. Королько. М.: «Рефлбук». К.: «Ваклер», с. 3. Кузин, Ф.А. Кандидатская диссертация: Методика написания, правила оформления и порядок защиты. Практическое пособие для аспирантов и соискателей ученой степени / Ф.А. Кузин. 3-е изд., доп. М.: «Ось-89», с. 4. Политический консультант в российских избирательных кампаниях: Психологическое пособие для политиков и политических консультантов / Ю. Косолапова, Е. Егорова-Гантман, Д. Водотынский и др. М.: «ИМА-пресс», с. 5. Селетков, С.Г. Соискателю ученой степени / С.Г. Селетков. 3-е изд., перераб. и доп. Ижевск: Изд-во ИжГТУ, с. 6. Соловьев, Э.Я. Современный этикет. Деловой протокол / Э.Я. Соловьев. 4-е изд., перераб. и доп. М.: Издательство «Ось-89», с. 7. Соммервилл, И. Инженерия программного обеспечения / И. Соммервилл; пер. с англ. 6-е издание. М.: Издательский дом «Вильямс», с. 8. СТО ЮУрГУ Стандарт организации. Система управления качеством образовательных процессов. Курсовая и выпускная квалификационная работа. Требования к содержанию и оформлению / составители: Т.И. Парубочая, Н.В. Сырейщикова, А.Е. Шевелев, Е.В. Шевелева. Челябинск: Изд-во ЮУрГУ, с. 9. Требования к выпускной квалификационной работы студентов специальности «Прикладная информатика (в экономике)»: метод. рекомендации / под общ. ред. О.Б. Назаровой. Магнитогорск : МаГУ, с. 89

91 ПРИЛОЖЕНИЯ Приложение 1 Министерство образования и науки Российской Федерации Государственное образовательное учреждение высшего профессионального образования «Южно-Уральский государственный университет» Факультет Кафедра РАБОТА (ПРОЕКТ) ПРОВЕРЕНА ДОПУСТИТЬ К ЗАЩИТЕ Рецензент, (должность) Заведующий кафедрой (И.О. Ф.) (И.О. Ф.) 200_ г. 200_ г. (НАИМЕНОВАНИЕ ТЕМЫ) ПОЯСНИТЕЛЬНАЯ ЗАПИСКА К ВЫПУСКНОЙ КВАЛИФИКАЦИОННОЙ РАБОТЕ (ПРОЕКТУ) ЮУрГУ ХХХХХХ.200_.ХХХ.ПЗ ВКР(ВКП) Консультант, (должность) Руководитель проекта, (должность) (И.О. Ф.) (И.О. Ф.) 200_ г. 200_ г. Консультант, (должность) Автор проекта студент группы ХХ-ХХХ (И.О. Ф.) (И.О. Ф.) 200_ г. 200_ г. Консультант, (должность) Нормоконтролер, (должность) (И.О. Ф.) (И.О. Ф.) 200_ г. 200_г. Челябинск 200_ 90

92 Приложение 2 Федеральное агентство по образованию Российской Федерации Государственное образовательное учреждение высшего профессионального образования «Южно-Уральский государственный университет» Факультет Кафедра Специальность УТВЕРЖДАЮ Заведующий кафедрой (И.О. Ф.) 200 г. З А Д А Н И Е на выпускную квалификационную работу (проект) студента (Ф. И.О. полностью) Группа 1 Тема работы (название) утверждена приказом по университету от 200_ г. (утверждена от 200_ г. ) 2 Срок сдачи студентом законченной работы 200 г. 3 Исходные данные к работе (проекту) 91

93 4 Перечень вопросов, подлежащих разработке 5 Иллюстративный материал (плакаты, альбомы, раздаточный материал, макеты, электронные носители и др.) Общее количество иллюстраций 6 Дата выдачи задания Руководитель (подпись) И.О. Ф.) Задание принял к исполнению (подпись студента) (И.О. Ф.) 92

94 КАЛЕНДАРНЫЙ ПЛАН Наименование этапов выпускной квалификационной работы (проекта) Срок выполнения этапов работы (проекта) Отметка о выполнении руководителя Заведующий кафедрой /И.О. Ф. / (подпись) Руководитель работы (проекта) /И.О. Ф. / (подпись) Студент /И.О. Ф. / (подпись) 93

95 Приложение 3 Пример оглавления дипломного проекта Введение: актуальность; формулировка проблемы, темы, цели, задач; формулировка объекта, предмета исследования; теоретико-методологическая основа; практическая значимость; положения, выносимые на защиту; апробация решений. Раздел 1. Аналитическая часть Технико-экономическая характеристика предметной области: характеристика предприятия (миссия, оргструктура и др.); краткая характеристика подразделения или видов его деятельности; экономическая сущность задачи; 1.2. Постановка задачи: обоснование необходимости и цели использования вычислительной техники для решения задачи (построение модели as-is и её предварительный анализ для определения «узких» мест); цель и назначение автоматизированного варианта решения задачи (предложения по устранению «узких» мест); общая характеристика организации решения задачи на ЭВМ; формализация расчетов; 1.3. Анализ существующих разработок и обоснование выбора технологии проектирования: определение критериев для анализа; сравнительная характеристика существующих разработок; Раздел 2. Разработка проектных решений Разработка концепции новой АС или модернизации старой: цели и задачи; изменения в оргструктуре; бизнес-процессы (to-be); бизнес-функции; анализ и выбор решения; 2.2. Обоснование проектных решений по видам обеспечения АС: организационное обеспечение; лингвистическое обеспечение (глоссарий, терминологическое единство); математическое обеспечение (формализация объектов); информационное обеспечение (внешний документооборот, логическая и физическая модели данных); программное обеспечение (схема комплекса программ, описание межмодульных интерфейсов); 94

96 технологическое обеспечение (карты, и инструкции, техпаспорт); 2.3. Разработка системной архитектуры: прикладная архитектура; архитектура данных; техническая архитектура; сетевая архитектура; архитектура платформ; Раздел 3. Реализация проектных решений Информационное обеспечение задачи: информационная модель и ее описание; используемые классификаторы и системы кодирования; характеристика нормативно-справочной и входной оперативной информации; характеристика результатной информации Программное обеспечение задачи: общие положения (дерево функций и сценарий диалога); структурная схема пакета (дерево вызова процедур и программ); описание программных модулей; схема взаимосвязи программных модулей и информационных файлов Технологическое обеспечение задачи: организация технологии сбора, передачи, обработки и выдачи информации; схема технологического процесса сбора, передачи, обработки и выдачи информации Проведение мероприятий по сопровождению и конфигурационному управлению АС: анализ дефектов и модификаций (включая, разработку примеров для выполнения модификаций); реализация модификации; оценка и принятие результатов сопровождения; перенос на иную платформу (в иную среду). Раздел 4. Организационно-экономический раздел 4.1 Экономическое обоснование 4.2 Сетевое планирование 4.3 Построение сетевого графика 4.4 Расчет параметров событий сетевого графика 4.5 Расчет параметров работ сетевого графика 4.6 Расчет затрат на проведение работ 4.7 Текущие затраты на стадии эксплуатации 4.8 Экономический эффект Раздел 5. Безопасность жизнедеятельности 8.1 Анализ достоинств интерфейса пользователя 8.2 Рекомендации по организации рабочего места пользователя Рекомендации по выбору помещения для размещения рабочего места Требования к параметрам микроклимата 95

97 8.2.3 Требования к уровню шума и вибрации на рабочем месте Требования к уровням электромагнитных полей на рабочих местах Требования к организации искусственного освещения Требования к организации рабочего места оператора Требования электробезопасности к оргтехнике Мероприятия по обеспечению пожарной безопасности 8.3 Рекомендации по организации режимов труда и отдыха пользователя Заключение Список используемой литературы Приложения 96

98 Приложение 4 Примеры плакатов ИНФОРМАЦИОННАЯ СИСТЕМА УЧЕТА И ПОИСКА ЭЛЕКТРОННЫХ КОМПОНЕНТОВ Цель работы -разработка программного обеспечения подсистемы учёта и поиска электронных компонентов для автоматизированной системы технологической подготовки производства на предприятии ООО «Технотрейд». Для достижения поставленной цели решались следующие задачи: 1. Исследование процессов построения информационнопоисковых подсистем технологической подготовки производства. 2. Проектирование структуры программного комплекса на базе архитектуры «клиент-сервер». 3. Разработка алгоритмов функционирования программного комплекса. 4. Разработка базы данных в среде InterBase для хранения информации об электронных компонентах. 5.Разработка интерфейса клиентской части на базе компилятора Borland C++ Builder

99 К л и е н т П о л ь з о в а т е л ь О бозреватель клиента (In tern et E x plo rer) п р о т о к о л С е р в е р W e b сервер (A p ach e) W e b интерфейс (P H P ) T C P /I P или IP X /S P X протоколы С е р в е р С У Б Д (In terb ase) БД (In terb ase) К л и е н т А д м и н и с т р а т о р, п о л ь з о в а т е л ь П рограмма администратора (T T D B ase) T C P / I P и л и IP X /S P X протоколы Изм Лист документа Подпись Дата Разраб. К олтаковат.а Консульт. Канашев Е.А Руковод. Н.контр. Злакоманов Зав.каф. КазариновЛ.С. ЮУрГУ-Д Г Информационнаясистема учетаи поискаэлектронных компонентов Структурнаясхемакомплекса Литер. Масса Масшт. Лист Листов ЮУрГУ Кафедра АиУ 98

100 Да Начало Выбрать режим обслуживания банкоматов Выбрать способ тестирования технических терминалов Указать оператору способ тестирования подлежащей исполнению Результат тестирования совпадает с эталонным Нет Выбрать требующее сообщение об ошибке Начать тестирование с начала Нет Конец Да Нет Работа в данном режиме закончена Да Начать тестирование в следующем режиме Нет Вывести сообщение орезультатах Да Изм Лист документа Подпись Дата Разраб. Пищенко М. Н. Консульт. Канашев Е.А Руковод. Н.контр. Злакоманов Зав.каф. КазариновЛ.С. ЮУрГУ-Д Д2.2 Автоматизированноерабочее местоуправлениясистемой банкомата Схемапрограммы Литер. Масса Масшт. Лист Листов ЮУрГУ Кафедра АиУ

101 Информационо-поисковая система технологического назначения Сбор и подготовка информации Учет, хранение и поиск информации Размножение и распределение информации Ввод и вывод информации Корректировка информации Анализ функционирования ИПС ТН ЮУрГУ-Д Б Изм Лист документа Подпись Дата Разраб..КолтаковаТ.А Консульт.Канашев Е.А Руковод. Н.контр. Злакоманов В.В. Зав.каф. КазариновЛ.С. Информационнаясистемаучетаи поискаэлектронныхкомпонентов Схемаорганизационной структуры Литер. Масса Масшт. Лист Листов ЮУрГУ Кафедра АиУ 100

102 ALALOGS U_COMPONENTS_ID U_COMPONENTS_ID_FOR TIPE_LIST U_TYPE_LIST_ID CTYPENAME_S CTYPENAME_L FIRM_LIST U_FIRMLIST_ID FIRMNAME Address WWWADDRES E_MAIL COMPONENTS U_COMPONENTS_ID U_TYPE_LIST_ID CNAME U_FIRMLIST_ID NCOST_OPT U_CURR_ID_OPT NCOST_ROZN U_CURR_ID_ROZN COM_USE_USEL CHARACTERISTIC U_FILENAME_ID DEALERS ID U_COMPONENTS_ID U_DEALER_ID N_COST_OPTOV NCURRENCY_OPT N_COST_ROZN NCURRENCY_ROZN CURRENCY U_CURRENCY_ID CCURRENCY ENGINEERING_DATA U_FILENAME_ID FILENAME U_FILEFORMAT_ID DEALER_LIST U_DEALER_ID CDEALER ADDRESS WWWADDRESS E_MAIL D CURRENCY U_CURRENCY_ID CCURENCY FILEFORMAT_LIST U_FILEFORMAT_ID FILEFORMAT ЮУрГУ-Д Д6.2 Изм Лист документа Подпись Дата Разраб. КолтаковаТ.А Консульт Канашев Е.А Руковод. Н.контр. Злакоманов Зав.каф. КазариновЛ.С. Информационнаясистема учетаи поискаэлектронных компонентов Инфологическаямодель Литер. Масса Масшт. Лист Листов ЮУрГУ Кафедра АиУ 101

103 Изм Лист документа Подпись Дата Разраб..КолтаковаТ.А Консульт.Канашев Е.А Руковод. Н.контр. Злакоманов В.В. Зав.каф. КазариновЛ.С. ЮУрГУ-Д А Информационнаясистема учетаи поискаэлектронных компонентов Видеограмма Литер. Масса Масшт. Лист Листов ЮУрГУ Кафедра АиУ 102

Внедрение (Эксплуатация) системы

Внедрение (Эксплуатация) системы Проектирование автоматизированных информационных систем бухгалтерского учета 1. Принципы и методы создания автоматизированных информационных систем 2. Стадии и этапы проектирования автоматизированных информационных

Подробнее

Министерство образования Российской Федерации. Санкт-Петербургский государственный инженерно-экономический университет

Министерство образования Российской Федерации. Санкт-Петербургский государственный инженерно-экономический университет Министерство образования Российской Федерации Санкт-Петербургский государственный инженерно-экономический университет Факультет предпринимательства и финансов Кафедра коммерческой деятельности и предпринимательства

Подробнее

ПРОГРАММА аттестационных испытаний для поступающих на 2 и последующие курсы специальности «Прикладная информатика (в сфере сервиса)»

ПРОГРАММА аттестационных испытаний для поступающих на 2 и последующие курсы специальности «Прикладная информатика (в сфере сервиса)» ПРОГРАММА аттестационных испытаний для поступающих на 2 и последующие курсы специальности «Прикладная информатика (в сфере сервиса)» Курс Экзамен Форма проведения экзамена 2 курс 3 курс 4 курс 5 курс Комплексный

Подробнее

ТРЕБОВАНИЯ К ВЫПУСКНОЙ КВАЛИФИКАЦИОННОЙ РАБОТЕ СТУДЕНТОВ СПЕЦИАЛЬНОСТИ «ПРИКЛАДНАЯ ИНФОРМАТИКА (В ЭКОНОМИКЕ)»

ТРЕБОВАНИЯ К ВЫПУСКНОЙ КВАЛИФИКАЦИОННОЙ РАБОТЕ СТУДЕНТОВ СПЕЦИАЛЬНОСТИ «ПРИКЛАДНАЯ ИНФОРМАТИКА (В ЭКОНОМИКЕ)» Министерство образования и науки Российской Федерации ГОУ ВПО «Магнитогорский государственный университет» ТРЕБОВАНИЯ К ВЫПУСКНОЙ КВАЛИФИКАЦИОННОЙ РАБОТЕ СТУДЕНТОВ СПЕЦИАЛЬНОСТИ 080801 «ПРИКЛАДНАЯ ИНФОРМАТИКА

Подробнее

Фонд оценочных средств для государственной итоговой аттестации по специальности «Программирование в компьютерных системах»

Фонд оценочных средств для государственной итоговой аттестации по специальности «Программирование в компьютерных системах» Фонд оценочных средств для государственной итоговой аттестации по специальности 09.02.03 «Программирование в компьютерных системах». 1. Общие положения Государственная итоговая аттестация (ГИА) направлена

Подробнее

ЧАСТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «АКАДЕМИЯ СОЦИАЛЬНОГО ОБРАЗОВАНИЯ»

ЧАСТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «АКАДЕМИЯ СОЦИАЛЬНОГО ОБРАЗОВАНИЯ» ЧАСТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «АКАДЕМИЯ СОЦИАЛЬНОГО ОБРАЗОВАНИЯ» Фонд оценочных средств дисциплины ОП.14. Информационные технологии в профессиональной деятельности специальность

Подробнее

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ УДМУРТСКИЙ ГОСУДАРСТВЕНННЫЙ УНИВЕРСИТЕТ ФИЛИАЛ Г.ГУБКИНСКИЙ ЯМАЛО-НЕНЕЦКИЙ АВТОНОМНЫЙ ОКРУГ

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ УДМУРТСКИЙ ГОСУДАРСТВЕНННЫЙ УНИВЕРСИТЕТ ФИЛИАЛ Г.ГУБКИНСКИЙ ЯМАЛО-НЕНЕЦКИЙ АВТОНОМНЫЙ ОКРУГ МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ УДМУРТСКИЙ ГОСУДАРСТВЕНННЫЙ УНИВЕРСИТЕТ ФИЛИАЛ Г.ГУБКИНСКИЙ ЯМАЛО-НЕНЕЦКИЙ АВТОНОМНЫЙ ОКРУГ Методические рекомендации для обучающихся по выполнению

Подробнее

Документирование на этапах проектирования ИС

Документирование на этапах проектирования ИС Документирование на этапах проектирования ИС 1 Этап 1. Системный анализ проекта ПС 1.1. Исследования и определение концепции версии ПС Результаты обследования и описание объекта и целей его информатизации

Подробнее

Технологическое обеспечение (обеспечивающие подсистемы) информационных технологий

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

Подробнее

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р УДК 658.012.011.56:006.354 Группа П87 Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р Единая система стандартов автоматизированных систем управления Автоматизированные системы управления

Подробнее

ОСНОВНЫЕ ТРЕБОВАНИЯ, ПРЕДЪЯВЛЯЕМЫЕ К КУРСОВОМУ ПРОЕКТУ. 1. Задание на курсовое проектирование

ОСНОВНЫЕ ТРЕБОВАНИЯ, ПРЕДЪЯВЛЯЕМЫЕ К КУРСОВОМУ ПРОЕКТУ. 1. Задание на курсовое проектирование 1 ОСНОВНЫЕ ТРЕБОВАНИЯ, ПРЕДЪЯВЛЯЕМЫЕ К КУРСОВОМУ ПРОЕКТУ 1. Задание на курсовое проектирование Каждому студенту выдается задание на курсовое проектирование. Задание включает: тему курсового проекта; исходные

Подробнее

Методические указания по подготовке курсовой работы по дисциплине

Методические указания по подготовке курсовой работы по дисциплине ДОНСКОЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ УПРАВЛЕНИЕ ДИСТАНЦИОННОГО ОБУЧЕНИЯ И ПОВЫШЕНИЯ КВАЛИФИКАЦИИ Кафедра «Экономика и управление» Методические указания по подготовке курсовой работы по дисциплине

Подробнее

ПАМЯТКА ДЛЯ ПОДГОТОВКИ И ЗАЩИТЫ ДИПЛОМНОЙ РАБОТЫ

ПАМЯТКА ДЛЯ ПОДГОТОВКИ И ЗАЩИТЫ ДИПЛОМНОЙ РАБОТЫ ПАМЯТКА ДЛЯ ПОДГОТОВКИ И ЗАЩИТЫ ДИПЛОМНОЙ РАБОТЫ 1. Требования к содержанию дипломной работы Дипломная работа должна содержать изложение цели и задач, поставленных перед дипломником, состояния изучаемой

Подробнее

Код компетенции. Название компетенции. способностью использовать основы философских знаний для формирования мировоззренческой позиции

Код компетенции. Название компетенции. способностью использовать основы философских знаний для формирования мировоззренческой позиции Код компетенции ОК-1 Название компетенции способностью использовать основы философских знаний для формирования мировоззренческой позиции ОК-2 способностью анализировать основные этапы и закономерности

Подробнее

Для специальности «Экономика и управление на предприятии» Цикл СД. Ф.03. Федеральный компонент

Для специальности «Экономика и управление на предприятии» Цикл СД. Ф.03. Федеральный компонент МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Кемеровский государственный университет Экономический факультет Методические указания по выполнению курсовых работ по дисциплине Организация производства

Подробнее

Порядок разработки структурными подразделениями ЗАО «Предприятие» проектной документации, подлежащей согласованию

Порядок разработки структурными подразделениями ЗАО «Предприятие» проектной документации, подлежащей согласованию Приложение к приказу Генерального директора от ЗАКРЫТОЕ АКЦИОНЕРНОЕ ОБЩЕСТВО НАИМЕНОВАНИЕКОМПАНИИ УТВЕРЖДЕНО Приказом Генерального директора от Порядок разработки структурными подразделениями ЗАО «Предприятие»

Подробнее

АННОТАЦИИ ДИСЦИПЛИН НАПРАВЛЕНИЯ ДОПОЛНИТЕЛЬНОЙ ПРОФЕССИОНАЛЬНОЙ ПРОГРАММЫ «БЕЗОПАСНОСТЬ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ И СЕТЕЙ»

АННОТАЦИИ ДИСЦИПЛИН НАПРАВЛЕНИЯ ДОПОЛНИТЕЛЬНОЙ ПРОФЕССИОНАЛЬНОЙ ПРОГРАММЫ «БЕЗОПАСНОСТЬ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ И СЕТЕЙ» АННОТАЦИИ ДИСЦИПЛИН НАПРАВЛЕНИЯ ДОПОЛНИТЕЛЬНОЙ ПРОФЕССИОНАЛЬНОЙ ПРОГРАММЫ «БЕЗОПАСНОСТЬ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ И СЕТЕЙ» Аннотация к дисциплине «Информатика и программирование» Дисциплина «Информатика и

Подробнее

АННОТАЦИИ программ учебной и производственной практик Направления подготовки бакалавров: Прикладная информатика Профиль подготовки

АННОТАЦИИ программ учебной и производственной практик Направления подготовки бакалавров: Прикладная информатика Профиль подготовки АННОТАЦИИ программ учебной и производственной практик Направления подготовки бакалавров: 09.03.03 Прикладная информатика Профиль подготовки Прикладная информатика в экономике Аннотация рабочей программы

Подробнее

1. ЦЕЛИ И ЗАДАЧИ ГОСУДАРСТВЕННОЙ ИТОГОВОЙ АТТЕСТАЦИИ

1. ЦЕЛИ И ЗАДАЧИ ГОСУДАРСТВЕННОЙ ИТОГОВОЙ АТТЕСТАЦИИ 2 1. ЦЕЛИ И ЗАДАЧИ ГОСУДАРСТВЕННОЙ ИТОГОВОЙ АТТЕСТАЦИИ Целью государственной итоговой аттестации (ГИА) является установление уровня подготовки выпускника к выполнению профессиональных задач и соответствия

Подробнее

УТВЕРЖДАЮ Директор МИ (филиала) ВлГУ Н.В. Чайковская 20 г.

УТВЕРЖДАЮ Директор МИ (филиала) ВлГУ Н.В. Чайковская 20 г. УТВЕРЖДАЮ Директор МИ (филиала) ВлГУ Н.В. Чайковская 20 г. Фонд оценочных средств для государственной итоговой аттестации по направлению подготовки 09.03.03 «Прикладная информатика» 1. Общие положения

Подробнее

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА ПАСПОРТ ПРОГРАММЫ ГОСУДАРСТВЕННОЙ (ИТОГОВОЙ) АТТЕСТАЦИИ... 5

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА ПАСПОРТ ПРОГРАММЫ ГОСУДАРСТВЕННОЙ (ИТОГОВОЙ) АТТЕСТАЦИИ... 5 СОДЕРЖАНИЕ ПОЯСНИТЕЛЬНАЯ ЗАПИСКА... 3 1. ПАСПОРТ ПРОГРАММЫ ГОСУДАРСТВЕННОЙ (ИТОГОВОЙ) АТТЕСТАЦИИ... 5 2. СТРУКТУРА И СОДЕРЖАНИЕ ГОСУДАРСТВЕННОЙ ИТОГОВОЙ АТТЕСТАЦИИ... 6 3. УСЛОВИЯ РЕАЛИЗАЦИИ ПРОГРАММЫ

Подробнее

Предисловие 3 1. Экономическая информация в автоматизированных информационных

Предисловие 3 1. Экономическая информация в автоматизированных информационных Описаны технологии организации, хранения и обработки данных. Предложена авторская методика разработки информационно-логической модели данных предметной области, ориентированная на офисный персонал. Детальное

Подробнее

Программа и методические указания по проведению производственной практики.

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

Подробнее

Кафедра «Вычислительная техника и информационные системы» СТРУКТУРА И ТЕМАТИКА ДИПЛОМНЫХ РАБОТ НА УЧЕБНЫЙ ГОД

Кафедра «Вычислительная техника и информационные системы» СТРУКТУРА И ТЕМАТИКА ДИПЛОМНЫХ РАБОТ НА УЧЕБНЫЙ ГОД Кафедра «Вычислительная техника и информационные системы» СТРУКТУРА И ТЕМАТИКА ДИПЛОМНЫХ РАБОТ НА 2016-2017 УЧЕБНЫЙ ГОД Специальность: 5В070300- Информационные системы РАССМОТРЕНО: на заседании кафедры

Подробнее

Приложение 3м МИНОБРНАУКИ РОССИИ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ» Факультет информатики

Подробнее

«Уфимский государственный нефтяной технический университет» Кафедра «Промышленная безопасность и охрана труда»

«Уфимский государственный нефтяной технический университет» Кафедра «Промышленная безопасность и охрана труда» ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «Уфимский государственный нефтяной технический университет» Кафедра «Промышленная безопасность и охрана

Подробнее

ПОЛОЖЕНИЕ О МАГИСТЕРСКОЙ ДИССЕРТАЦИИ

ПОЛОЖЕНИЕ О МАГИСТЕРСКОЙ ДИССЕРТАЦИИ МИНИСТЕРСТВО ОБРАЗОВАНИЯ и НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования НИУ «МЭИ» УТВЕРЖДАЮ Ректор 2014 г. Принято на

Подробнее

Метаданные теста. Текст вопроса. 1 Экономическая информация включает: 2 Информационный ресурс может быть определен как: 3 Информатизация это:

Метаданные теста. Текст вопроса. 1 Экономическая информация включает: 2 Информационный ресурс может быть определен как: 3 Информатизация это: Автор теста: Гагарина Н.Л. Название курса: «Информационные системы в экономике» Предназначено для студентов всех специальностей 3 курса Семестр: летний Проходной балл: 50 Количество кредитов: 3 Учебный

Подробнее

МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ВЫПОЛНЕНИЮ КУРСОВОЙ РАБОТЫ. Для студентов специальности «Компьютерная безопасность»

МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ВЫПОЛНЕНИЮ КУРСОВОЙ РАБОТЫ. Для студентов специальности «Компьютерная безопасность» МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ВЫПОЛНЕНИЮ КУРСОВОЙ РАБОТЫ Для студентов специальности «Компьютерная безопасность» Введение Современные требования к специалистам в области компьютерной безопасности предполагают

Подробнее

ПРОГРАММА ИТОГОВОЙ ГОСУДАРСТВЕННОЙ АТТЕСТАЦИИ

ПРОГРАММА ИТОГОВОЙ ГОСУДАРСТВЕННОЙ АТТЕСТАЦИИ ПРОГРАММА ИТОГОВОЙ ГОСУДАРСТВЕННОЙ АТТЕСТАЦИИ 1. Цели итоговой государственной аттестации Целями итоговой государственной аттестации являются проверка и оценка степени освоения общекультурных универсальных

Подробнее

МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО КУРСОВОМУ ПРОЕКТИРОВАНИЮ для студентов специальности " Информационная безопасность автоматизированных систем "

МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО КУРСОВОМУ ПРОЕКТИРОВАНИЮ для студентов специальности  Информационная безопасность автоматизированных систем МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО КУРСОВОМУ ПРОЕКТИРОВАНИЮ для студентов специальности 090305 " Информационная безопасность автоматизированных систем " 1 1 ОБЩИЕ МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ВЫПОЛНЕНИЮ, ОФОРМЛЕНИЮ

Подробнее

АННОТАЦИЯ РАБОЧЕЙ ПРОГРАММЫ по дисциплине

АННОТАЦИЯ РАБОЧЕЙ ПРОГРАММЫ по дисциплине МИНИСТЕРСТВО СЕЛЬСКОГО ХОЗЯЙСТВА РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «КУБАНСКИЙ ГОСУДАРСТВЕННЫЙ АГРАРНЫЙ УНИВЕРСИТЕТ»

Подробнее

5. Требования к структуре 5.1 Материалы магистерской диссертации должны состоять из структурных элементов, расположенных в следующем порядке:

5. Требования к структуре 5.1 Материалы магистерской диссертации должны состоять из структурных элементов, расположенных в следующем порядке: способность самостоятельно проводить научные исследования, выполнять проектные работы, систематизировать и обобщать фактический материал; умение формулировать выводы и практические рекомендации по результатам

Подробнее

Определение 1: Определение 2:

Определение 1: Определение 2: РАЗРАБОТКА ИС Жизненный цикл ИС Определение 1: Жизненный цикл ИС это процесс ее построения и развития. Определение 2: Жизненный цикл ИС период времени, который начинается с момента принятия решения о необходимости

Подробнее

АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ

АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ ГОСУДАРСТВЕННЫЙ СТАНДАРТ СОЮЗА ССР ЕДИНАЯ СИСТЕМА СТАНДАРТОВ АВТОМАТИЗИРОВАННЫХ СИСТЕМ УПРАВЛЕНИЯ АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СТАДИЯМ СОЗДАНИЯ ГОСТ 24.60286 ГОСУДАРСТВЕННЫЙ

Подробнее

Тема 1. Экономическая информация и информационные процессы в организационно - экономической сфере.

Тема 1. Экономическая информация и информационные процессы в организационно - экономической сфере. 1 Тема 1. Экономическая информация и информационные процессы в организационно - экономической сфере. 1.1. Информационные процессы в экономике. Основные понятия информатики и информатизации. Понятие и экономической.

Подробнее

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

I. Общие положения Выпускная квалификационная работа призвана способствовать систематизации и закреплению полученных студентами знаний и умений. МИНОБРНАУКИ РОССИИ Федеральное государственное бюджетное образовательное учреждение высшего Приложение 3 к приказу от 12.09.2013 г. 1017-О профессионального образования «Уфимский государственный авиационный

Подробнее

АННОТАЦИИ РАБОЧИХ ПРОГРАММ ПРОФЕССИОНАЛЬНЫХ МОДУЛЕЙ

АННОТАЦИИ РАБОЧИХ ПРОГРАММ ПРОФЕССИОНАЛЬНЫХ МОДУЛЕЙ 1 2 АННОТАЦИИ РАБОЧИХ ПРОГРАММ ПРОФЕССИОНАЛЬНЫХ МОДУЛЕЙ основной профессиональной образовательной программы среднего профессионального образования базового подготовки по специальности среднего профессионального

Подробнее

Освоение каждого профессионального модуля завершается оценкой компетенций студентов по системе «освоен / не освоен».

Освоение каждого профессионального модуля завершается оценкой компетенций студентов по системе «освоен / не освоен». Специальность 230115 Программирование в компьютерных системах базовая подготовка ОБЩАЯ ХАРАКТЕРИСТИКА ПРИМЕРНЫХ ПРОГРАММ ПРОФЕССИОНАЛЬНЫХ МОДУЛЕЙ Основная профессиональная образовательная программа по

Подробнее

ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ ВЫПУСКНОЙ КВАЛИФИКАЦИОННОЙ РАБОТЫ

ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ ВЫПУСКНОЙ КВАЛИФИКАЦИОННОЙ РАБОТЫ МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное автономное образовательное учреждение высшего образования «Крымский федеральный университет имени В.И. Вернадского» МЕДИЦИНСКИЙ

Подробнее

Филиал «Угреша» УТВЕРЖДАЮ Проректор по учебной работе С.В. Моржухина 20 ПРОГРАММА ДИСЦИПЛИНЫ. "Проектирование информационных систем"

Филиал «Угреша» УТВЕРЖДАЮ Проректор по учебной работе С.В. Моржухина 20 ПРОГРАММА ДИСЦИПЛИНЫ. Проектирование информационных систем Государственное образовательное учреждение высшего профессионального образования Московской области «Международный университет природы, общества и человека «Дубна» Филиал «Угреша» УТВЕРЖДАЮ Проректор по

Подробнее

Методические рекомендации по организации курсового проектирования в ГБПОУ ЗКНО. I. Общие положения

Методические рекомендации по организации курсового проектирования в ГБПОУ ЗКНО. I. Общие положения Методические рекомендации по организации курсового проектирования в ГБПОУ ЗКНО I. Общие положения 1.1. Курсовой проект (КП) должен представлять собой решение комплексной технической задачи, включающей

Подробнее

Новокузнецкий институт (филиал) Факультет информационных технологий. Фонд оценочных средств для государственной итоговой аттестации

Новокузнецкий институт (филиал) Факультет информационных технологий. Фонд оценочных средств для государственной итоговой аттестации МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Кемеровский государственный университет» Новокузнецкий

Подробнее

Программа практики одобрена на заседании Методической комиссии факультета информационных технологий от года, протокол 55.

Программа практики одобрена на заседании Методической комиссии факультета информационных технологий от года, протокол 55. Рабочая программа дисциплины составлена в соответствии с требованиями ФГОС ВО к структуре и результатам освоения образовательных программ магистратуры по направлению подготовки 09.04.01 «Информатика и

Подробнее

1. Общая информация о дисциплине 1.1. Название дисциплины: Информационные системы в бизнесе

1. Общая информация о дисциплине 1.1. Название дисциплины: Информационные системы в бизнесе 1. Общая информация о дисциплине 1.1. Название дисциплины: Информационные системы в бизнесе 1.2.1. Трудоёмкость дисциплины по учебному плану очной формы обучения: 128 часов (4 ЗЕ) из них: лекций 16 час.

Подробнее

ИНФОРМАЦИОННОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРОЦЕССОВ АВТОМАТИЗАЦИИ (ТЕХНИЧЕСКИЕ СИСТЕМЫ)

ИНФОРМАЦИОННОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРОЦЕССОВ АВТОМАТИЗАЦИИ (ТЕХНИЧЕСКИЕ СИСТЕМЫ) ИНФОРМАЦИОННОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРОЦЕССОВ АВТОМАТИЗАЦИИ (ТЕХНИЧЕСКИЕ СИСТЕМЫ) Разработчик Артюшенко В.М., д-р тех. наук, проф. Рецензент Берлинер Э.М., д-р тех. наук, проф. I Организационно-методический

Подробнее

Методические указания по выполнению курсового проекта

Методические указания по выполнению курсового проекта МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ АСТРАХАНСКОЙ ОБЛАСТИ Государственное бюджетное образовательное учреждение Астраханской области среднего профессионального образования «Астраханский колледж вычислительной

Подробнее

Программа академической магистратуры

Программа академической магистратуры Акт соответствия результатов освоения основной профессиональной образовательной программы по направлению подготовки «Прикладная информатика», разработанной в соответствии с ФГОС ВПО по направлению подготовки

Подробнее

АННОТАЦИЯ РАБОЧЕЙ ПРОГРАММЫ ПРОФЕССИОНАЛЬНОГО МОДУЛЯ. «ВЫПОЛНЕНИЕ РАБОТ ПО ПРОФЕССИИ «Оператор ЭВМ»

АННОТАЦИЯ РАБОЧЕЙ ПРОГРАММЫ ПРОФЕССИОНАЛЬНОГО МОДУЛЯ. «ВЫПОЛНЕНИЕ РАБОТ ПО ПРОФЕССИИ «Оператор ЭВМ» Министерство образования и науки Российской Федерации Федеральное государственное автономное образовательное учреждение высшего профессионального образования «Российский государственный профессионально-педагогический

Подробнее

Тема. Автоматизированные рабочие места

Тема. Автоматизированные рабочие места Тема. Автоматизированные рабочие места Деятельность работников сферы управления в настоящее время ориентирована на использование развитых информационных технологий. Организация и реализация управленческих

Подробнее

2.СОСТАВ И СОДЕРЖАНИЕ

2.СОСТАВ И СОДЕРЖАНИЕ Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы Information technology. Set of standards for automated systems. Technical directions for developing

Подробнее

практического опыта выпускника и овладению общими и профессиональными компетенциями, установленными федеральными государственными образовательными

практического опыта выпускника и овладению общими и профессиональными компетенциями, установленными федеральными государственными образовательными практического опыта выпускника и овладению общими и профессиональными компетенциями, установленными федеральными государственными образовательными стандартами среднего профессионального образования по

Подробнее

Учебно-методические материалы по дисциплине «Информационные технологии в управлении»

Учебно-методические материалы по дисциплине «Информационные технологии в управлении» Учебно-методические материалы по дисциплине «Информационные технологии в управлении» Примерная тематика рефератов 1. Управление информатизацией в госорганах и расходы на ИКТ. 2. Роль свободного программного

Подробнее

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

накопление, содержание запасов и обеспечение ими горнодобывающей отрасли; УДК 658.7 МЕТОДОЛОГИЯ СОЗДАНИЯ АВТОМАТИЗИРОВАННЫХ СИСТЕМ ТЕХНИЧЕСКОГО ОБЕСПЕЧЕНИЯ ГОРНОДОБЫВАЮЩЕГО КОМПЛЕКСА Жильцов А.А., студент; Синюкова Т.Б. ст. преподаватель (ГВУЗ «Донецкий национальный технический

Подробнее

СОДЕРЖАНИЕ ОСНОВНОЙ ПРОФЕССИОНАЛЬНОЙ ОБРАЗОВАТЕЛЬНОЙ ПРОГРАММЫ

СОДЕРЖАНИЕ ОСНОВНОЙ ПРОФЕССИОНАЛЬНОЙ ОБРАЗОВАТЕЛЬНОЙ ПРОГРАММЫ СОДЕРЖАНИЕ ОСНОВНОЙ ПРОФЕССИОНАЛЬНОЙ ОБРАЗОВАТЕЛЬНОЙ ПРОГРАММЫ 1. ОБЩИЕ ПОЛОЖЕНИЯ... 3 1.1. Цель программы... Ошибка! Закладка не определена. 1.2. Сроки освоения программы... Ошибка! Закладка не определена.

Подробнее

1. Общая информация о дисциплине 1.1. Название дисциплины: Информационные системы управления

1. Общая информация о дисциплине 1.1. Название дисциплины: Информационные системы управления 1. Общая информация о дисциплине 1.1. Название дисциплины: Информационные системы управления 1.2.1. Трудоёмкость дисциплины по учебному плану очной формы обучения: 144 часов (4 ЗЕ) из них: лекций 0 час.

Подробнее

МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО НАПИСАНИЮ ДИПЛОМНОЙ РАБОТЫ для студентов специальностей «Государственное управление и экономика» «Бизнес-администрирование»

МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО НАПИСАНИЮ ДИПЛОМНОЙ РАБОТЫ для студентов специальностей «Государственное управление и экономика» «Бизнес-администрирование» МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО НАПИСАНИЮ ДИПЛОМНОЙ РАБОТЫ для студентов специальностей «Государственное управление и экономика» «Бизнес-администрирование» ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДИПЛОМНОЙ РАБОТЫ Введение Во

Подробнее

МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО НАПИСАНИЮ И ПОДГОТОВКЕ МАГИСТЕРСКОЙ ДИССЕРТАЦИИ

МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО НАПИСАНИЮ И ПОДГОТОВКЕ МАГИСТЕРСКОЙ ДИССЕРТАЦИИ МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО НАПИСАНИЮ И ПОДГОТОВКЕ МАГИСТЕРСКОЙ ДИССЕРТАЦИИ Москва 2014 Оглавление I. Общие положения 3 II. Структура и содержание магистерской диссертации....4 1. Титульный лист 4 2.

Подробнее

РУКОВОДЯЩИЙ ДОКУМЕНТ ПО СТАНДАРТИЗАЦИИ

РУКОВОДЯЩИЙ ДОКУМЕНТ ПО СТАНДАРТИЗАЦИИ УДК 65.015.13.011.56:006.354 Группа П87 РУКОВОДЯЩИЙ ДОКУМЕНТ ПО СТАНДАРТИЗАЦИИ МЕТОДИЧЕСКИЕ УКАЗАНИЯ ОКСТУ 0024 АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. Основные положения РД 50 680 88 Дата введения 01.01.90 Настоящие

Подробнее

АННОТАЦИЯ К РАБОЧЕЙ ПРОГРАММЕ по дисциплине

АННОТАЦИЯ К РАБОЧЕЙ ПРОГРАММЕ по дисциплине Федеральное государственное бюджетное образовательное учреждение высшего образования «Саратовский государственный технический университет имени Гагарина Ю.А.» Кафедра «Прикладные информационные технологии»

Подробнее

АННОТАЦИИ РАБОЧИХ ПРОГРАММ УЧЕБНЫХ ДИСЦИПЛИН

АННОТАЦИИ РАБОЧИХ ПРОГРАММ УЧЕБНЫХ ДИСЦИПЛИН МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Тамбовский государственный технический университет»

Подробнее

ПРОГРАММА. УТВЕРЖДЕНА Решением Ученого совета СГАСУ, протокол 2013 г. Ректор СГАСУ М.И. Бальзанников

ПРОГРАММА. УТВЕРЖДЕНА Решением Ученого совета СГАСУ, протокол 2013 г. Ректор СГАСУ М.И. Бальзанников Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Самарский государственный архитектурно-строительный

Подробнее

АННОТАЦИЯ К РАБОЧЕЙ ПРОГРАММЕ УЧЕБНОЙ ДИСЦИПЛИНЫ

АННОТАЦИЯ К РАБОЧЕЙ ПРОГРАММЕ УЧЕБНОЙ ДИСЦИПЛИНЫ АННОТАЦИЯ К РАБОЧЕЙ ПРОГРАММЕ УЧЕБНОЙ ДИСЦИПЛИНЫ Автор: О.В. Матянина, преподаватель специальных дисциплин Илекского зоотехнического техникума филиала ФГБОУ ВПО Оренбургский ГАУ. Специальность: 230401

Подробнее

о дипломных проектах и научно исследовательских работах

о дипломных проектах и научно исследовательских работах Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Ивановский государственный химико-технологический

Подробнее

12. Понятие организационной структуры управления. 13. Особенности российской модели управления. 14. Управление в условиях глобализации. 15.

12. Понятие организационной структуры управления. 13. Особенности российской модели управления. 14. Управление в условиях глобализации. 15. Методические указания по дисциплине «Теория управления» для студентов направления подготовки 081100 «Государственное и муниципальное управление» квалификация (бакалавр) (самостоятельная работа, методические

Подробнее

«Производственная практика» Фонд оценочных средств раздела ООП

«Производственная практика» Фонд оценочных средств раздела ООП Министерство образования и науки РФ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Карачаево-Черкесский государственный университет имени У.Д. Алиева»

Подробнее

Учебно-методические материалы по дисциплине «Офисные информационные технологии»

Учебно-методические материалы по дисциплине «Офисные информационные технологии» Учебно-методические материалы по дисциплине «Офисные информационные технологии» Самостоятельная работа студентов В ходе изучения настоящего курса значительное место отводится самостоятельной работе студентов,

Подробнее

Дипломное проектирование

Дипломное проектирование Информатика и программное обеспечение Дипломное проектирование Как успешно защитить диплом и получить от этого удовольствие Структура дипломной к.т.н., доц. работы. Лагерев Д.Г. к.т.н., доц. Булатицкий

Подробнее

C. типа "Черный ящик", не параметризованные, параметризованные, типа "Белый (прозрачный) ящик" D. управляемые извне, управляемые, с комбинированным

C. типа Черный ящик, не параметризованные, параметризованные, типа Белый (прозрачный) ящик D. управляемые извне, управляемые, с комбинированным Тестовые задания по дисциплине «Основы информационных систем» для подготовки к 1-му рубежнму контролю Специальность 5B070300 «Информационные системы» (1 курс, группа ИС-504) @@@ Основные понятия теории

Подробнее

Методические рекомендации для самостоятельной работы обучающихся по дисциплине. _Разработка web-приложений

Методические рекомендации для самостоятельной работы обучающихся по дисциплине. _Разработка web-приложений ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «ОРЕНБУРГСКИЙ ГОСУДАРСТВЕННЫЙ АГРАРНЫЙ УНИВЕРСИТЕТ» Кафедра «Автоматизированные системы обработки информации и управления»

Подробнее

ПОЧУ «Улан-Удэнский торгово-экономический техникум» Положение об организации выполнения и защиты курсовой работы (проекта) СМК.3-ПП-4.2.

ПОЧУ «Улан-Удэнский торгово-экономический техникум» Положение об организации выполнения и защиты курсовой работы (проекта) СМК.3-ПП-4.2. Предисловие Настоящее Положение разработано на основании: Федерального закона от 29 декабря 2012 г. 273-ФЗ «Об образовании в Российской Федерации». Порядка организации и осуществления образовательной деятельности

Подробнее

Обоснование путей создания эталонной модели данных единого информационного пространства ВС РФ 1

Обоснование путей создания эталонной модели данных единого информационного пространства ВС РФ 1 Обоснование путей создания эталонной модели данных единого информационного пространства ВС РФ 1 Ктн доцент Чумичкин А.А. Интеграционные процессы, протекающие практически во всех областях человеческой деятельности,

Подробнее

4 ПОРЯДОК ВЫПОЛНЕНИЯ КУРСОВЫХ РАБОТ (ПРОЕКТОВ) 4.1 Руководство и порядок выполнения курсовых работ (проектов)

4 ПОРЯДОК ВЫПОЛНЕНИЯ КУРСОВЫХ РАБОТ (ПРОЕКТОВ) 4.1 Руководство и порядок выполнения курсовых работ (проектов) 4 ПОРЯДОК ВЫПОЛНЕНИЯ КУРСОВЫХ РАБОТ (ПРОЕКТОВ) 4.1 Руководство и порядок выполнения курсовых работ (проектов) Студент выполняет курсовую работу (проект) по утвержденной теме в соответствии с заданием и

Подробнее

АННОТАЦИЯ. Формируемые компетенции: - способность анализировать социально-значимые проблемы и процессы, происходящие в

АННОТАЦИЯ. Формируемые компетенции: - способность анализировать социально-значимые проблемы и процессы, происходящие в Дисциплина «Оценка рисков с использованием ППП» Структура нагрузки: всего часов/зачетных единиц 180/5, в том числе: лекции 36 часов, практические занятия 18 часов, лабораторные занятия 18 часов, самостоятельная

Подробнее

СТРУКТУРА КУРСОВОГО ПРОЕКТА ПО ДИСЦИПЛИНЕ «ТЕПЛОТЕХНИКА» 1 ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

СТРУКТУРА КУРСОВОГО ПРОЕКТА ПО ДИСЦИПЛИНЕ «ТЕПЛОТЕХНИКА» 1 ПОЯСНИТЕЛЬНАЯ ЗАПИСКА СТРУКТУРА КУРСОВОГО ПРОЕКТА ПО ДИСЦИПЛИНЕ «ТЕПЛОТЕХНИКА» 1 ПОЯСНИТЕЛЬНАЯ ЗАПИСКА Пояснительную записку выполняют на листах белой бумаги формата А4 (на ее одной стороне) без рамки. Рекомендуемый объем записки

Подробнее

СПИСОК ЭКЗАМЕНАЦИОННЫХ ВОПРОСОВ, ВЫНОСИМЫХ НА ГОСУДАРСТВЕННЫЙ ЭКЗАМЕН

СПИСОК ЭКЗАМЕНАЦИОННЫХ ВОПРОСОВ, ВЫНОСИМЫХ НА ГОСУДАРСТВЕННЫЙ ЭКЗАМЕН Исполнитель: Профильная кафедра Адресат: ДИ СПИСОК ЭКЗАМЕНАЦИОННЫХ ВОПРОСОВ, ВЫНОСИМЫХ НА ГОСУДАРСТВЕННЫЙ ЭКЗАМЕН Институт ИКТ Образовательная программа ВПО Кафедра ПИЭ аббревиатура института ВПО, СПО

Подробнее

Основные процедуры преобразования информации в информационных технологиях

Основные процедуры преобразования информации в информационных технологиях Контроль ввода Регистрация Основные процедуры преобразования в информационных технологиях Концептуальная модель базовой информационной технологии содержит процессы, процедуры и операции информационного

Подробнее

ИНСТРУКЦИЯ ПО ПОДГОТОВКЕ, ОФОРМЛЕНИ Ю И ПРЕДСТАВЛЕНИ Ю К ЗАЩИТЕ ДИПЛОМНЫХ ПРОЕКТОВ (РАБОТ) В ВЫС ШИХ УЧЕБНЫХ ЗАВЕДЕНИЯХ

ИНСТРУКЦИЯ ПО ПОДГОТОВКЕ, ОФОРМЛЕНИ Ю И ПРЕДСТАВЛЕНИ Ю К ЗАЩИТЕ ДИПЛОМНЫХ ПРОЕКТОВ (РАБОТ) В ВЫС ШИХ УЧЕБНЫХ ЗАВЕДЕНИЯХ УТВЕРЖДЕНО приказом Министерства образования Республики Беларусь от 27 июня 1997 г.n 356 Зарегистрировано в Национальном реестре правовых актов Республики Беларусь 23 декабря 1999 г. N 8/2344 Инструкция

Подробнее

А.У. Кобилов, кандидат экономических наук, доцент, ТГЭУ

А.У. Кобилов, кандидат экономических наук, доцент, ТГЭУ А.У. Кобилов, кандидат экономических наук, доцент, ТГЭУ ПРОГРЕССИВНЫЕ ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В НАЛОГОВОЙ СИСТЕМЕ Важным органом, занимающимся аккумуляцией денежных средств в бюджетной системе, является

Подробнее

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ЧАСТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «БРЯНСКИЙ ИНСТИТУТ УПРАВЛЕНИЯ И БИЗНЕСА» КАФЕДРА ИНФОРМАТИКИ И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Методические

Подробнее

МЕТОДИЧЕСКИЕ УКАЗАНИЯ АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ РД Информационные данные

МЕТОДИЧЕСКИЕ УКАЗАНИЯ АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ РД Информационные данные МЕТОДИЧЕСКИЕ УКАЗАНИЯ АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ РД 50-680-88 Информационные данные Утверждены Постановлением Государственного комитета СССР по стандартам от 28 декабря 1988 г. N 4622

Подробнее

АННОТАЦИЯ рабочей программы дисциплины «Информационные технологии и платформы разработки ИС»

АННОТАЦИЯ рабочей программы дисциплины «Информационные технологии и платформы разработки ИС» АННОТАЦИЯ рабочей программы дисциплины «Информационные технологии и платформы разработки ИС» Цель и задачи дисциплины Цели дисциплины «Информационные технологии и платформы разработки информационных систем»:

Подробнее

ГОСТ Р Библиографическая запись. Сокращение слов и словосочетаний

ГОСТ Р Библиографическая запись. Сокращение слов и словосочетаний ПОРЯДОК организации и проведения научно-исследовательских работ в Государственном бюджетном учреждении культуры города Москвы «Центральная универсальная научная библиотека имени Н. А. Некрасова» Настоящий

Подробнее

ИНФОРМАЦИОННОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРОЦЕССОВ АВТОМАТИЗАЦИИ (ПРОМЫШЛЕННОСТЬ)

ИНФОРМАЦИОННОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРОЦЕССОВ АВТОМАТИЗАЦИИ (ПРОМЫШЛЕННОСТЬ) ИНФОРМАЦИОННОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРОЦЕССОВ АВТОМАТИЗАЦИИ (ПРОМЫШЛЕННОСТЬ) Разработчик Савинов В.А., канд. тех. наук, проф. Рецензент Берлинер Э.М., д-р тех. наук, проф. I Организационно-методический

Подробнее

ПРОФЕССИОНАЛЬНЫЙ СТАНДАРТ

ПРОФЕССИОНАЛЬНЫЙ СТАНДАРТ УТВЕРЖДЕН приказом Министерства труда и социальной защиты Российской Федерации от 2013 г. ПРОФЕССИОНАЛЬНЫЙ СТАНДАРТ Программист I. Общие сведения Разработка программного 06.001 (наименование вида профессиональной

Подробнее

Программно-аппаратные средства обеспечения информационной безопасности

Программно-аппаратные средства обеспечения информационной безопасности Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Томский государственный университет систем

Подробнее

Министерство образования Калининградской области ГБОУ СПО КО «ХПТ»

Министерство образования Калининградской области ГБОУ СПО КО «ХПТ» Министерство образования Калининградской области ГБОУ СПО КО «ХПТ» УТВЕРЖДАЮ Зам. директора по УМР З.А. Гринько 2012 г. ПРОГРАММА ИТОГОВОЙ ГОСУДАРСТВЕННОЙ АТТЕСТАЦИИ ВЫПУСКНИКОВ ПО СПЕЦИАЛЬНОСТИ 230701

Подробнее

Программа производственной практики. Направление подготовки Информатика и вычислительная техника

Программа производственной практики. Направление подготовки Информатика и вычислительная техника 17 ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ МОСКОВСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ СВЯЗИ И ИНФОРМАТИКИ Программа производственной практики Направление

Подробнее

СИСТЕМНОЕ И ПРИКЛАДНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ. Лекция 4: Жизненный цикл ПО Требования Техническое задание

СИСТЕМНОЕ И ПРИКЛАДНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ. Лекция 4: Жизненный цикл ПО Требования Техническое задание СИСТЕМНОЕ И ПРИКЛАДНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ Лекция 4: Жизненный цикл ПО Требования Техническое задание Жизненный цикл программного обеспечения Понятие жизненного цикла Жизненный цикл период: с момента

Подробнее

МИНСКИЙ ИНСТИТУТ УПРАВЛЕНИЯ. Кафедра автоматизированных информационных систем. С.А. Медведев г.

МИНСКИЙ ИНСТИТУТ УПРАВЛЕНИЯ. Кафедра автоматизированных информационных систем. С.А. Медведев г. МИНСКИЙ ИНСТИТУТ УПРАВЛЕНИЯ Кафедра автоматизированных информационных систем УТВЕРЖДАЮ Декан учетно-финансового факультета С.А. Медведев 2006 г. Рабочая программа по дисциплине «Автоматизированные информационные

Подробнее

ÈÍÔÎÐÌÀÖÈÎÍÍÛÅ ÑÈÑÒÅÌÛ È ÒÅÕÍÎËÎÃÈÈ Â ÝÊÎÍÎÌÈÊÅ

ÈÍÔÎÐÌÀÖÈÎÍÍÛÅ ÑÈÑÒÅÌÛ È ÒÅÕÍÎËÎÃÈÈ Â ÝÊÎÍÎÌÈÊÅ Î. Þ. Íåò ñîâà ÈÍÔÎÐÌÀÖÈÎÍÍÛÅ ÑÈÑÒÅÌÛ È ÒÅÕÍÎËÎÃÈÈ Â ÝÊÎÍÎÌÈÊÅ УЧЕБНОЕ ПОСОБИЕ ДЛЯ ВУЗОВ 3-е издание, исправленное и дополненное Êíèãà äîñòóïíà â ýëåêòðîííîé áèáëèîòå íîé ñèñòåìå biblio-online.ru Ìîñêâà

Подробнее

АНО ВО «Современный технический университет» Положение о курсовой работе (проекте)

АНО ВО «Современный технический университет» Положение о курсовой работе (проекте) 1. Общие положения... 3 2. Организация выполнения курсовой работы (проекта)... 4 3. Защита курсовой работы (проекта)... 7 Приложение 1... 9 Лист регистрации изменений... 10 Страница 2 из 11 1. Общие положения

Подробнее

Примерный перечень вопросов к вступительному экзамену в магистратуру по направлению подготовки «Прикладная информатика»

Примерный перечень вопросов к вступительному экзамену в магистратуру по направлению подготовки «Прикладная информатика» ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО РЫБОЛОВСТВУ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «МУРМАНСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» Примерный

Подробнее

ОБОСНОВАНИЕ ПРОЕКТНЫХ РЕШЕНИЙ ПО ОСНОВНЫМ ВИДАМ ОБЕСПЕЧЕНИЯ ИС «АРМ ЭКОНОМИСТА ПО АНАЛИЗУ ИНВЕСТИЦИОННЫХ ПРОЕКТОВ» Еремин Р.В., Назарова Ю.Н.

ОБОСНОВАНИЕ ПРОЕКТНЫХ РЕШЕНИЙ ПО ОСНОВНЫМ ВИДАМ ОБЕСПЕЧЕНИЯ ИС «АРМ ЭКОНОМИСТА ПО АНАЛИЗУ ИНВЕСТИЦИОННЫХ ПРОЕКТОВ» Еремин Р.В., Назарова Ю.Н. ОБОСНОВАНИЕ ПРОЕКТНЫХ РЕШЕНИЙ ПО ОСНОВНЫМ ВИДАМ ОБЕСПЕЧЕНИЯ ИС «АРМ ЭКОНОМИСТА ПО АНАЛИЗУ ИНВЕСТИЦИОННЫХ ПРОЕКТОВ» Еремин Р.В., Назарова Ю.Н. Волгоградский государственный аграрный университет Волгоград,

Подробнее

МЕТОДИЧЕСКИЕ УКАЗАНИЯ

МЕТОДИЧЕСКИЕ УКАЗАНИЯ МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ Государственное образовательное учреждение высшего профессионального образования "Ижевский государственный технический университет" УТВЕРЖДАЮ Ректор И.В. Абрамов

Подробнее

КОНЦЕПЦИЯ И СТРУКТУРА ИНТЕГРИРОВАННОЙ ВЕДОМСТВЕННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ ФСИН РОССИИ

КОНЦЕПЦИЯ И СТРУКТУРА ИНТЕГРИРОВАННОЙ ВЕДОМСТВЕННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ ФСИН РОССИИ Нам пишут РОССИХИНА Лариса Витальевна - кандидат технических наук, капитан внутренней службы, старший преподаватель цикла радиотехнических систем Воронежского колледжа Федеральной службы исполнения наказаний

Подробнее

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ПРОФСОЮЗОВ ВЫСШЕГО ОБРАЗОВАНИЯ «АКАДЕМИЯ ТРУДА И СОЦИАЛЬНЫХ ОТНОШЕНИЙ»

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ПРОФСОЮЗОВ ВЫСШЕГО ОБРАЗОВАНИЯ «АКАДЕМИЯ ТРУДА И СОЦИАЛЬНЫХ ОТНОШЕНИЙ» ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ПРОФСОЮЗОВ ВЫСШЕГО ОБРАЗОВАНИЯ «АКАДЕМИЯ ТРУДА И СОЦИАЛЬНЫХ ОТНОШЕНИЙ» УТВЕРЖДЕНО Наблюдательным советом ОУП ВО «АТиСО» от «04» марта 2015 г. Протокол 1 ПОЛОЖЕНИЕ о курсовой

Подробнее

Приложение 4. Аннотация программы учебной практики

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

Подробнее

Содержание и методы создания информационных систем и информационных технологий

Содержание и методы создания информационных систем и информационных технологий Содержание и методы создания информационных систем и информационных технологий Создание автоматизированных информационных систем и технологий управления может осуществляться по двум вариантам. 1) Первый

Подробнее

1. Общие положения 1.1. Настоящее Положение определяет требования к содержанию, объему и структуре научно-квалификационной работы (диссертации)

1. Общие положения 1.1. Настоящее Положение определяет требования к содержанию, объему и структуре научно-квалификационной работы (диссертации) 1. Общие положения 1.1. Настоящее Положение определяет требования к содержанию, объему и структуре научно-квалификационной работы (диссертации) аспиранта (далее НКР), и ее защите в ФГБОУ ВО «Нижегородский

Подробнее