МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО ВЫПОЛНЕНИЮ ДИПЛОМНЫХ РАБОТ
Выполнение дипломной работы — заключительный этап обучения в вузе. Студент должен проявить умение самостоятельно решать поставленные перед ним научно-технические задачи, используя знания и навыки, приобретенные за время обучения. При этом студент несет личную ответственность за качество выполнения и оформления работы, достоверность результатов, представление работы в установленный срок и за ее защиту.
Руководитель и консультант несут ответственность за правильность принципиальных направлений работы и выбор темы.
Выполнение дипломной работы можно разбить на четыре этапа:
учебно-исследовательская работа (УИР) (01 сентября - 31 декабря) (деканатский зачет)
преддипломная практика (13 февраля – 31 марта);
выполнение задания на дипломную работу, подготовка пояснительной записки (01 апреля – 31 мая);
непосредственная подготовка к защите (составление доклада, оформление презентации) и защита дипломной работы на заседании Государственной аттестационной комиссии (01 июня – середина июня).
Структура методических указаний построена в соответствии с этими этапами.
1. УИР И ПРЕДДИПЛОМНАЯ ПРАКТИКА
1.1. Прохождение УИР и преддипломной практики. В начале 9-го семестра студенты 5-го курса приглашаются на организационное собрание, проводимое кафедрой. Студентам предлагается выбрать руководителя дипломной работы. У одного руководителя, как правило, не более двух-трёх дипломников. Исключения должны обговариваться с заведующим кафедрой. Руководитель — преподаватель кафедры. Если дипломная работа целиком выполняется на кафедре, то руководитель, как правило, одновременно является и консультантом.
В 9-м семестре студенты выполняли учебно-исследовательскую работу (УИР). Она специально введена в учебный план, чтобы студенты могли раньше выбрать себе руководителя, определиться с темой дипломной работы, начать подбор литературы и других информационных источников, осваивать программные средства.
На организационном собрании студентов знакомят с порядком прохождения преддипломной практики, требованиями к дипломной работе. Студенты могут скопировать файл, содержащий бланк задания на дипломную работу.
После организационного собрания студент встречается с руководителем, и они обсуждают направление работы.
Дипломную работу можно выполнять в организации (где в дальнейшем, возможно, предстоит работать студенту уже в качестве молодого специалиста) или на кафедре. Первый вариант предпочтительнее, т.к. студент быстрее адаптируется в своем будущем рабочем коллективе, знакомится с его проблематикой, осваивает оборудование и программные средства, с которыми ему предстоит работать. Второй вариант уместен, когда студент продолжает развивать задание, полученное еще в период учебы или на практике, проходившей в МИЭМ.
Если дипломная работа выполняется не в МИЭМ, то целесообразно и желательно назначение консультанта от организации. В его обязанности кроме консультаций по теме дипломной работы входит оказание дипломнику технической и организационной помощи. (МИЭМ не оплачивает работу консультанта!).
Целью преддипломной практики является завершение теоретической и производственной подготовки студента к дипломной работе.
Как планировать преддипломную практику? Во-первых, в соответствии с выбранным направлением работы, следует наметить литературные источники. В процессе их изучения студент составляет обзор, который в дальнейшем войдет в пояснительную записку. Во-вторых, следует выбрать средства вычислительной техники и программное обеспечение для выполнения дипломной работы. Нужно безотлагательно начать их освоение, чтобы не потерять в дальнейшем время из-за отсутствия соответствующих навыков. Для этого полезно составить и решить серию простых учебных задач, похожих на те, которые предстоит решать дипломнику. Например, если предстоит разработать систему управления некоторым динамическим объектом, то следует провести моделирование на ЭВМ похожих систем, освоить соответствующие библиотеки программ для научно-технических расчетов.
Завершается преддипломная практика окончательным выбором темы, уточнением ее формулировки, составлением задания на дипломную работу. Должен быть создан солидный "задел", который позволит обоснованно оценить ожидаемые результаты. Кроме того, должна быть продумана структура пояснительной записки и составлен ее развернутый план (оглавление). Этот план помещается в задание на дипломную работу и поэтому без крайней необходимости не должен изменяться.
По итогам преддипломной практики руководитель проставляет студенту зачет с оценкой.
Госэкзамен по специальности предположительно будет проходить в понедельник 30 марта 2009 года.
Студент сдает зачетную книжку, два экземпляра заполненного бланка задания на дипломную работу (с подписями руководителя, консультанта и самого студента) и файл для подготовки приказа ректора.
Пример. (руководитель и консультант)
Файл Юренков.doc
| Юренков Вадим Валерьевич |
«Классификация посетителей web-сайтов по их поведению» Руководитель: Лавренов С.М., доц., к.т.н. Консультант: Беляев А.А., нач. отдела партнерств «Рамблер интернет холдинг» |
или (руководитель одновременно является консультантом)
Файл Пржевальский.doc
| Пржевальский Константин Николаевич |
«Исследование нейронных сетей адаптивного резонанса в системах распознавания образов» Руководитель и консультант: Истратов А.Ю., доц., к.т.н. |
Из этих файлов формируется приказ ректора о темах дипломных работ.
В зачетной книжке рядом с фотографией нужно разместить следующие сведения:
· Фамилия, Имя, Отчество полностью в дательном падеже;
· Дата рождения;
· Контактный телефон.
(Эти данные нужны деканату для подготовки дипломов)
Если студент не получил зачёт по преддипломной практике, то он не допускается к сдаче госэкзамена.
1.2. Тематика дипломных работ.
Темы дипломных работ должны соответствовать специальности "Информационные системы и технологии", а также отвечать современному уровню развития науки и техники и в значительной мере отражать практические и научные проблемы, для решения которых предназначены автоматизированные системы обработки информации и управления (АСУ, ГПС, системы автоматизированного проектирования, автоматические системы управления, информационно-справочные системы, экспертные и интеллектуальные системы и т.д.).
При выборе темы необходимо учитывать нужды производства (но без ущерба для учебных целей), личную направленность работ руководителя и консультанта, возможность использования современных и перспективных вычислительных средств.
Конкретная тематика дипломных работ определяется тем, в какой области народного хозяйства должны использоваться системы, в разработке математического и программного обеспечения которых должен участвовать при выполнении дипломной работы студент.
Независимо от того, каково конкретное содержание задачи, рассматриваемой в дипломной работе, в процессе ее выполнения должен быть проведен анализ объекта автоматизации, сделана математическая (системная) постановка задачи, построены модели, разработан алгоритм получения решения, выполнена программная реализация алгоритма, решены конкретные примеры, проанализированы полученные результаты. Иными словами, студент должен продемонстрировать свою квалификацию в качестве системного аналитика и программиста. Тема дипломной работы должны быть такова, чтобы студент мог при ее выполнении продемонстрировать свои знания в области информационных систем, умение применить их в практической ситуации, навыки в разработке программного обеспечения или нетривиальном использовании существующих программных средств.
Недопустимо, когда в дипломной работе присутствует только один из перечисленных компонентов, например, кодируются готовые алгоритмы.
1.3. Оформление задания на дипломную работу.
В задании на дипломную работу указывается ее тема и сроки выполнения, раскрывается содержание пояснительной записки.
Пункты, перечисляемые в разделе IV.A, — это заголовки разделов в будущей пояснительной записке. Менять их в дальнейшем без крайней необходимости не следует, т.к. на заседании ГАК могут сверить пункты задания с оглавлением пояснительной записки и при обнаружении несоответствия утверждать, что задание не выполнено или выполнено не полностью. По этой же причины пункты задания не следует делать "слишком обязывающими", если соответствующий материал еще не подготовлен.
Оформленное задание подписывают руководитель, консультант и студент. Студент сдает оба заполненных бланка ответственному от кафедры за проведение дипломных работ. Задание утверждает заведующий кафедрой. На основании задания кафедра готовит Приказ ректора, в котором утверждается тема дипломной работы, руководитель и консультант. После этого в оба экземпляра ответственный от кафедры проставляет дату и номер приказа. Один экземпляр после утверждения выдается студенту для подшивки в пояснительную записку, второй хранится на кафедре.
2. ВЫПОЛНЕНИЕ ЗАДАНИЯ НА ДИПЛОМНУЮ РАБОТУ
Трудно дать конкретные рекомендации, не учитывая специфику задания. Студенту следует предусмотреть совместно с руководителем и консультантом разумный график выполнения работы и стараться не допускать больших отклонений от него. Следует учитывать, что отладка программного обеспечения обычно занимает половину (если не больше) времени, затрачиваемого на программирование. Поэтому еще раз повторим совет: начинайте осваивать программные средства, еще не располагая алгоритмами, подлежащими реализации. Точно так же, не откладывайте написание пояснительной записки, а старайтесь каждый этап вашей работы немедленно оформлять в виде соответствующего раздела. Руководитель и консультант оказывают помощь студенту в выполнении дипломной работы, но следует помнить, что роль руководителя иная, чем при других видах занятий в вузе. Руководитель помогает студенту оценить различные варианты решений, но осуществить выбор — задача самого студента. И ему придется отстаивать свой выбор на заседании Государственной экзаменационной комиссии, не ссылаясь на полученные рекомендации.
2.1. Содержание пояснительной записки
Пояснительная записка должна отражать этапы работы специалиста по информационным системам над конкретной проблемой.
1) Обзор литературы (состояние вопроса).
2) Описание предметной области.
3) Описание используемых инструментальных средств для разработки программного обеспечения
3) Разработка информационной модели.
4) Синтез алгоритма и его исследование.
5) Программная реализация.
6) Выводы и практические рекомендации.
Конечно, предлагаемую схему расположения материала в дипломной работе ни в коем случае нельзя рассматривать как догму. Но еще раз подчеркнем: дипломная работа не должна сводиться только к демонстрации навыков программирования. Ее автор должен показать умение приложить знание теории информационных систем в реальных практических задачах.
2.2. Оформление пояснительной записки.
Пояснительная записка оформляется на листах бумаги стандартного формата А4 (210х297). Текст размещается на одной стороне листа. Пояснительная записка переплетается с прозрачной обложкой.
Все страницы имеют сквозную нумерацию, начиная с титульного листа. На титульном листе номер не проставляется.
Расположение материала в пояснительной записке следующее.
1. Титульный лист;
2. Задание на дипломную работу;
3. Реферат (одна страница);
4. Оглавление с постраничной разметкой;
5. Введение с кратким обзором по рассматриваемому вопросу и мотивировкой выбора направления данной работы; (обзор можно вынести и в отдельную главу).
6. Основная часть работы, содержащая разделы:
<Предметная область, информационная модель>
<Описание алгоритма>
<Описание программного обеспечения>
7. Заключение;
8. Библиографический список;
9. Приложения — материалы (чертежи, таблицы, графики, блок-схемы, распечатки большого формата и т.п.), включение которых в основной текст по каким-либо причинам признано необязательным.
Ориентировочный объем пояснительной записки составляет примерно 40 – 60 страниц шрифтом Times New Roman (размер 12 пунктов) через 1,5 интервала.
2.3. Описание алгоритма.
К сожалению, в общем случае нельзя дать однозначных рекомендаций по описанию алгоритмов. Когда-то были популярны блок-схемы алгоритмов (в ГОСТе они называются схемами алгоритмов). Сейчас они используются при внешнем, наиболее грубом описании алгоритма. Ведь в них даже нет адекватного средства для наглядного изображения оператора цикла: "для k от 1 до N с шагом 1 выполнить".
Постепенно пришли к выводу, что наиболее полным формальным описанием алгоритма является программа. В то же время из формального описания алгоритма на языке программирования бывает трудно понять содержательный смысл выполняемых действий (даже при использовании комментариев в тексте программы). Поэтому описание алгоритма должно быть прежде всего неформальным, рассчитанным на читателя-человека, а не машину. В качестве классического образца можно предложить книги Д.Кнута (см. например, [5]), где формальной записи алгоритма на языке MIX предшествует ясное неформальное изложение с использованием математической символики. Можно также использовать в качестве образца описание алгоритмов, представленных в [1; 6; 7].
Следует подробно описывать алгоритм не всей программы, а только нетривиальной ее части, понимание которой может вызвать затруднения. Так, не нужно детализировать описание начального диалога программы с пользователем, когда запрашиваются некоторые параметры и проверяется их принадлежность некоторому диапазону.
В описании алгоритма не следует использовать внутренних имен функций и модулей, из которых состоит программа. Следует давать им названия, отражающие смысл. При описании программного обеспечения желательно дать таблицу соответствия содержательных и формальных имен. Например, если в программе, функция, выполняющая оценку точности решения, носит имя accur(), то в описании алгоритма следует использовать осмысленное название "модуль оценки точности". В тексте программы в свою очередь должен быть комментирующий текст, поясняющий читателю назначение функции accur().
Еще отметим, что не во всякой дипломной работе можно говорить об алгоритме в строгом смысле этого слова. Допустим, разрабатывается программа на языке Пролог. Тогда алгоритм скрыт в используемых языковых средствах, и уместнее говорить о сценарии работы программы. Это же касается использования прикладных программных пакетов, предназначенных, например, для моделирования динамических систем. В общем, термин "алгоритм" можно использовать и в этом случае, но понимать его в расширительном смысле, как алгоритм взаимодействия пользователя с прикладной программной системой. Синонимами здесь будут такие термины как "сценарий", методика", "последовательность действий".
Итак, выбор адекватного языка описания алгоритма представляет собой нетривиальную задачу и должен производиться взвешенно. Здесь полезны обсуждения с руководителем и консультантом.
2.4. Описание программного обеспечения.
Требования к объему и детализации описания программного обеспечения зависят от задач и характера дипломной работы, от объема разрабатываемых программ. Программное обеспечение должно быть описано в соответствии с основными требованиями ГОСТов, составляющих Единую систему программной документации (ЕСПД) [2]. В реальной практике в ТЗ (техническое задание) включается раздел "Требования к программной документации", в котором определяется состав документов, передаваемых Заказчику вместе с программным обеспечением: например, "Руководство системного программиста", "Руководство оператора", "Программа и методика испытаний" и т.д. В документах имеются повторяющиеся разделы (например, "Назначение программы"), поэтому в дипломной работе нецелесообразно педантично воспроизводить форму этих документов. Достаточно продемонстрировать умение описывать программное обеспечение так, что из пунктов описания легко потом скомпоновать документы, определенные ТЗ. При наиболее полном описании разработанного программного обеспечения рекомендуем раскрыть в дипломной работе следующие пункты (они выбраны из ЕСПД).
1) Общие сведения о программе (программном комплексе — далее это уточнение будет опускаться).
Здесь указываются:
· обозначение и наименование программы;
· программное обеспечение, необходимое для функционирования программы;
· языки программирования, на которых написана программа;
· основные характеристики: объем и время работы программы.
Остановимся подробнее на последнем пункте. Объем программы измеряется дважды: во-первых, определяется объем исходных текстов программ, во-вторых, объем исполняемых модулей.
2) Функциональное назначение.
Указываются классы решаемых задач и (или) назначение программы и сведения о функциональных ограничениях на ее применение.
3) Структура программы. Программное обеспечение обычно создается коллективом разработчиков (бригадой программистов), дипломник разрабатывает часть модулей. Следует в общих чертах описывать всю систему и подробно - модули, разработанные автором.
Структуру взаимодействия модулей предпочтительно изображать в виде графа подчиненности модулей, чтобы наглядно показать иерархическую структуру комплекса. Служебные подпрограммы, используемые практически всеми модулями комплекса, целесообразно показывать отдельно, чтобы не загромождать схему большим количеством связей.
Для каждого модуля приводится его название и описывается назначение.
4) Используемые технические средства. Здесь перечисляется минимальный состав технических средств, обеспечивающий работу программы: тип процессора, объем оперативной памяти, наличие жесткого диска, требуемый объем дискового пространства, тип дисплейного адаптера, наличие принтера и его тип, какое-либо специализированное оборудование (плоттер, мышь и т.д.)
5) Требования к программному окружению. Операционная система и ее минимально допустимая версия, наличие в оперативной памяти специализированных драйверов, используемые стандартные библиотеки (например, библиотеки для научно-технических расчетов, библиотеки графических примитивов, библиотеки классов и т.д.)
6) Настройка программы (процедура инсталляции). Какие действия должен предпринять программист при установке программы на жесткий диск
7) Эксплуатация программы.
7.1) Описание входных данных.
Входная информация разделяется на переменную и постоянную. Например, программы, эксплуатируемые на производственном участке, читают нормативно-справочную информацию из файлов, содержимое которых обновляется достаточно редко. В то же время оперативный план может меняться ежедневно.
Для входной информации указывается тип кодирования, формат (например, постоянная информация может выбираться из обычных текстовых файлов в формате ASCII, либо из файлов в формате некоторой базы данных). Следует также указывать технические средства ввода данных: клавиатура, мышь, сканер и т.д.
7.2) Описание выходных данных.
Здесь указываются характер и организация выходных данных; формат, описание и способ кодирования. Описывается информация, поступающая на выходные устройства: экран терминала, принтер, плоттер. Описываются файлы с выходной информацией.
Сообщения об ошибках в выходную информацию не включаются.
7.3) Выполнение программы.
Описывается последовательность действий пользователя (оператора), обеспечивающая загрузку, запуск, выполнение и завершение программы, приведено описание функций, формата и возможных вариантов команд, с помощью которых пользователь осуществляет загрузку и управляет выполнением программы, а также ответы программы на эти команды.
Здесь рекомендуется выделить подраздел "Сообщения пользователю", в котором привести тексты сообщений, выдаваемых в ходе выполнения программы, описания их содержания и соответствующие действия пользователя (в случае сбоя, возможности повторного запуска программы и т.п.)
Рекомендуется использовать поясняющие примеры, таблицы, схемы, графики. Полезные рекомендации имеются в [3].
8) Текст программы.
Текст программы приводится на исходном языке и снабжается подробными комментариями. В оформлении текста программы применяются элементы структурного программирования для улучшения восприятия (отступы внутри тела циклов и условных блоков, "содержательные" имена идентификаторов и т.п.)
9) Методика испытаний.
Здесь описываются требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля. Приводится перечень тестовых примеров и соответствующих контрольных распечаток.
2.5. Библиографический список
Автор дипломной работы должен перечислить в этом списке использованные источники (книги, статьи, документы...). Библиографическое описание включает следующие обязательные элементы: автор(ы), основное заглавие, место и дата издания, объем. Общая схема библиографической записи выглядит так [4]:
Заголовок (Фамилия И.О. индивидуальных авторов; наименование коллективного автора). Основное заглавие: Сведения, относящиеся к заглавию (раскрывают тематику, вид, жанр, назначение документа и т.д.) /Сведения об ответственности (содержит информацию о составителях, редакторах, переводчиках и т.п., об организациях, от имени которых опубликован документ). — Сведения об издании (содержат сведения о повторности издания, его переработке и т.п.). — Место издания: Издательство или издающая организация, дата издания. — Объем (сведения о количестве страниц, листов).
Если используется составная часть издания (например, статья в журнале или сборнике), то составляется аналитическое описание в следующем виде:
Сведения о составной части // Сведения о документе, в котором помещена составная часть.
Первая часть библиографического аналитического описания содержит сведения об авторах, заглавии, сведения, относящиеся к заглавию. Во второй части (после //) приводится краткое библиографическое описание документа, в котором опубликована составная часть (автор, если он не совпадает с автором составной части, заглавие, сведения, относящиеся к заглавию; сведения об ответственности, которые приводятся в основном для сборников научных трудов; сведения об издании, месте и годе издания), а также указываются страницы, на которых помещена данная статья или раздел. В случае с сериальными изданиями или многотомниками дополнительно указывается номер тома или выпуска.
Приведем примеры.
1) Описание книги:
Касаткин А.И. Профессиональное программирование на языке Си. Управление ресурсами: Справ.пособие. — Мн.: Выш. шк., 1992. — 432 с.
Место издания указывается сокращенно для следующих городов: Москва – М., Санкт-Петербург – СПб (Ленинград – Л.), Киев – К., Минск – Мн.
Перед названием издательства указывается двоеточие. Области описания отделяются тире.
2) Описание статьи, входящей в книгу:
Хоор К. О структурной организации данных // Дал У., Дейкстра Э., Хоор К. Структурное программирование. — М.: Мир,1975, С.98-197.
Указаны страницы, принадлежащие статье.
3) Описание статьи из журнала:
Меффорд М. Клавиатура от A до Z // КомпьютерПресс,1991, N11, С.29-39; N12, С.41-55.
Т.к. статья разбита на несколько номеров журнала, описание для каждого номера дается через точку с запятой.
4) Описание технического руководства:
Turbo Debugger. Version 2.5. User's Guide. Borland International. — [s.l.](USA),1991. — XIV pp.+428 pp.
В книге не указано место издания, поэтому в квадратных скобках добавляем информацию, не содержащуюся в издании. Для этого используются сокращения: без года – б.г. (т.е. не указан год издания), без места – б.м. (не указано место издания). В текстах, набранных латиницей, используются соответственно сокращения — s.a. (sine anno), s.l. (sine loco).
В книге использована двойная пагинация (страницы оглавления имеют независимую нумерацию римскими цифрами). Это отражено в библиографическом описании.
Описания источников в библиографическом списке должны быть пронумерованы и расположены по алфавиту авторов. Сначала располагаются издания на русском языке, а затем на иностранных языках.
Часто дипломники не делают никаких ссылок на литературу, приведенную в библиографическом списке. Это неправильно и может вызвать справедливые обвинения в плагиате. Ссылки в тексте работы следует оформлять так: [номер по списку] или [номер по списку, номер страницы] или [номер по списку, номер тома или журнала, номер страницы]. Примеры: [3], [1,с.3-5,8], [12,2,с.47]. Если нужно сослаться сразу на несколько работ, то в квадратные скобки помещается перечень порядковых номеров, разделяемых точкой с запятой: [2; 7,с.23-48; 9].
2.6. Оформление дипломной работы.
Для оформления текста пояснительной записки рекомендуется придерживаться требований ГОСТ 7.32-2001 «Отчет о научно-исследовательской работе»
http://www.gsnti-norms.ru/norms/common/doc.asp?2&/norms/stands/7_32.htm
Студент-дипломник при этом научится оформлять отчеты в соответствии с требованиями ГОСТ.
Ниже приводятся выдержки из этого ГОСТа, которые можно использовать как руководство по оформлению:
(заменяйте слово «НИР» словами «дипломная работа»)
Структурными элементами являются: титульный лист; реферат; содержание; нормативные ссылки; определения; обозначения и сокращения; введение; основная часть; заключение; список использованных источников; приложения.
Не все эти элементы являются обязательными.
Реферат
Реферат должен содержать: сведения об объеме отчета, количестве иллюстраций, таблиц, приложений, количестве использованных источников; перечень ключевых слов; текст реферата. Перечень ключевых слов должен включать от 5 до 15 слов или словосочетаний из текста отчета, которые в наибольшей мере характеризуют его содержание и обеспечивают возможность информационного поиска. Ключевые слова приводятся в именительном падеже и печатаются строчными буквами в строку через запятые. Текст реферата должен отражать: объект исследования или разработки; цель работы; метод или методологию проведения работы; результаты работы; основные конструктивные, технологические и технико-эксплуатационные характеристики; степень внедрения; рекомендации по внедрению или итоги внедрения результатов НИР; область применения; экономическую эффективность или значимость работы; прогнозные предположения о развитии объекта исследования. Если отчет не содержит сведений по какой-либо из перечисленных структурных частей реферата, то в тексте реферата она опускается, при этом последовательность изложения сохраняется.
Пример составления реферата на отчет о НИР
Реферат
Отчет 85 с., 2 ч., 24 рис., 12 табл., 50 источников, 2 прил.
РАСХОДОМЕРНЫЕ УСТАНОВКИ, ПОРШНЕВЫЕ РАСХОДОМЕРЫ, ТАХОМЕТРИЧЕСКИЕ РАСХОДОМЕРЫ. ИЗМЕРЕНИЕ, БОЛЬШИЕ РАСХОДЫ, ГАЗЫ
Объектом исследования являются поршневые установки для точного воспроизведения и измерения больших расходов газа.
Цель работы — разработка методики метрологических исследований установок и нестандартной аппаратуры для их осуществления.
В процессе работы проводились экспериментальные исследования отдельных составляющих и общей погрешности установок.
В результате исследования впервые были созданы две поршневые реверсивные расходомерные установки: первая на расходы до 0,07 м3
/с, вторая —до 0,33 м3
/с.
Основные конструктивные и технико-эксплуатационные показатели: высокая точность измерения при больших значениях расхода газа.
Степень внедрения — вторая установка по разработанной методике аттестована как образцовая.
Эффективность установок определяется их малым влиянием на ход измеряемых процессов. Обе установки могут применяться для градуировки и поверки промышленных ротационных счетчиков газа, а также тахометрических расходомеров.
Содержание
Содержание включает введение, наименование всех разделов, подразделов, пунктов (если они имеют наименование), заключение, список использованных источников и наименование приложений с указанием номеров страниц, с которых начинаются эти элементы отчета о НИР.
Нормативные ссылки
Структурный элемент «Нормативные ссылки» содержит перечень стандартов, на которые в тексте стандарта дана ссылка. Перечень ссылочных стандартов начинают со слов: «В настоящем отчете о НИР использованы ссылки на следующие стандарты». В перечень включают обозначения стандартов и их наименования в порядке возрастания регистрационных номеров обозначений.
Определения
Структурный элемент «Определения» содержит определения, необходимые для уточнения или установления терминов, используемых в НИР. Перечень определений начинают со слов: «В настоящем отчете о НИР применяют следующие термины с соответствующими определениями».
Обозначения и сокращения
Структурный элемент «Обозначения и сокращения» содержит перечень обозначений и сокращений, применяемых в данном отчете о НИР. Запись обозначений и сокращений проводят в порядке приведения их в тексте отчета с необходимой расшифровкой и пояснениями. Допускается определения, обозначения и сокращения приводить в одном структурном элементе «Определения, обозначения и сокращения».
Введение
Введение должно содержать оценку современного состояния решаемой научно-технической проблемы, основание и исходные данные для разработки темы, обоснование необходимости проведения НИР, сведения о планируемом научно-техническом уровне разработки, о патентных исследованиях и выводы из них, сведения о метрологическом обеспечении НИР. Во введении должны быть показаны актуальность и новизна темы, связь данной работы с другими научно-исследовательскими работами.
Основная часть
В основной части отчета приводят данные, отражающие сущность, методику и основные результаты выполненной НИР. Основная часть должна содержать:
а) выбор направления исследований, включающий обоснование направления исследования, методы решения задач и их сравнительную оценку, описание выбранной общей методики проведения НИР;
б) процесс теоретических и (или) экспериментальных исследований, включая определение характера и содержания теоретических исследований, методы исследований, методы расчета, обоснование необходимости проведения экспериментальных работ, принципы действия разработанных объектов, их характеристики;
в) обобщение и оценку результатов исследований, включающих оценку полноты решения поставленной задачи и предложения по дальнейшим направлениям работ, оценку достоверности полученных результатов и их сравнение с аналогичными результатами отечественных и зарубежных работ, обоснование необходимости проведения дополнительных исследований, отрицательные результаты, приводящие к необходимости прекращения дальнейших исследований.
Заключение
Заключение должно содержать: краткие выводы по результатам выполнений НИР или отдельных ее этапов; оценку полноты решений поставленных задач; разработку рекомендаций и исходных данных по конкретному использованию результатов НИР; оценку технико-экономической эффективности внедрения; оценку научно-технического уровня выполненной НИР в сравнении с лучшими достижениями в данной области.
Приложения
В приложения рекомендуется включать материалы, связанные с выполненной НИР, которые по каким-либо причинам не могут быть включены в основную часть. В приложения могут быть включены: промежуточные математические доказательства, формулы и расчеты; таблицы вспомогательных цифровых данных; протоколы испытаний; описание аппаратуры и приборов, применяемых при проведении экспериментов, измерений и испытаний; инструкции, методики, разработанные в процессе выполнения НИР; иллюстрации вспомогательного характера; акты внедрения результатов НИР и др.
Правила оформления отчета
Общие требования
Страницы текста отчета о НИР и включенные в отчет иллюстрации и таблицы должны соответствовать формату А4. Отчет о НИР должен быть выполнен на одной стороне листа белой бумаги формата А4 через полтора интервала. Цвет шрифта должен быть черным, высота букв, цифр и других знаков — не менее 1,8 мм (кегль не менее 12). Текст отчета следует печатать, соблюдая следующие размеры полей: правое — 10 мм, верхнее — 20 мм, левое и нижнее — 20 мм. Разрешается использовать компьютерные возможности акцентирования внимания на определенных терминах, формулах, теоремах, применяя шрифты разной гарнитуры.
Фамилии, названия учреждений, организаций, фирм, название изделий и другие имена собственные в отчете приводят на языке оригинала. Допускается транслитерировать имена собственные и приводить названия организаций в переводе на язык отчета с добавлением (при первом упоминании) оригинального названия.
Сокращение русских слов и словосочетаний в отчете — по ГОСТ 7.12.
(http://www.gsnti-norms.ru/norms/common/doc.asp?0&/norms/stands/7_12.htm)
Построение отчета
Наименования структурных элементов отчета «Список исполнителей», «Реферат», «Содержание», «Нормативные ссылки», «Определения», «Обозначения и сокращения», «Введение», «Заключение», «Список использованных источников» служат заголовками структурных элементов отчета.
Основную часть отчета следует делить на разделы, подразделы и пункты. Пункты, при необходимости, могут делиться на подпункты. При делении текста отчета на пункты и подпункты необходимо, чтобы каждый пункт содержал законченную информацию. Разделы, подразделы, пункты и подпункты следует нумеровать арабскими цифрами и записывать с абзацного отступа. Разделы должны иметь порядковую нумерацию в пределах всего текста, за исключением приложений.
Пример — 1,
2, 3 и т. д.
Номер подраздела или пункта включает номер раздела и порядковый номер подраздела или пункта, разделенные точкой.
Пример — 1.1, 1.2, 1.3 и т. д.
Номер подпункта включает номер раздела, подраздела, пункта и порядковый номер подпункта, разделенные точкой.
Пример — 1.1.1.1, 1.1.1.2, 1.1.1.3 и т. д.
После номера раздела, подраздела, пункта и подпункта в тексте точку не ставят. Если раздел или подраздел имеет только один пункт или пункт имеет один подпункт, то нумеровать его не следует. Разделы, подразделы должны иметь заголовки. Пункты, как правило, заголовков не имеют. Заголовки должны четко и кратко отражать содержание разделов, подразделов. Заголовки разделов, подразделов и пунктов следует печатать с абзацного отступа с прописной буквы без точки в конце, не подчеркивая. Если заголовок состоит из двух предложений, их разделяют точкой.
Нумерация страниц отчета
Страницы отчета следует нумеровать арабскими цифрами, соблюдая сквозную нумерацию по всему тексту отчета. Номер страницы проставляют в центре нижней части листа без точки. Титульный лист включают в общую нумерацию страниц отчета. Номер страницы на титульном листе не проставляют. Иллюстрации и таблицы, расположенные на отдельных листах, включают в общую нумерацию страниц отчета. Иллюстрации и таблицы на листе формата АЗ учитывают как одну страницу.
Нумерация разделов, подразделов, пунктов, подпунктов отчета
Разделы отчета должны иметь порядковые номера в пределах всего документа, обозначенные арабскими цифрами без точки и записанные с абзацного отступа. Подразделы должны иметь нумерацию в пределах каждого раздела. Номер подраздела состоит из номеров раздела и подраздела, разделенных точкой. В конце номера подраздела точка не ставится. Разделы, как и подразделы, могут состоять из одного или нескольких пунктов. Если документ не имеет подразделов, то нумерация пунктов в нем должна быть в пределах каждого раздела, и номер пункта должен состоять из номеров раздела и пункта, разделенных точкой. В конце номера пункта точка не ставится.
Пример
1 Типы и основные размеры
1.1
1.2 Нумерация пунктов первого раздела документа
1.3
2 Технические требования
2.1
2.2 Нумерация пунктов второго раздела документа
2.3
Если документ имеет подразделы, то нумерация пунктов должна быть в пределах подраздела и номер пункта должен состоять из номеров раздела, подраздела и пункта, разделенных точками, например:
3 Методы испытаний
3.1 Аппараты, материалы и реактивы
3.1.1
3.1.2 Нумерация пунктов первого подраздела третьего раздела документа
3.1.3
3.2 Подготовка к испытанию
3.2.1
3.2.2 Нумерация пунктов второго подраздела третьего раздела документа
3.2.3
Если раздел состоит из одного подраздела, то подраздел не нумеруется. Если подраздел состоит из одного пункта, то пункт не нумеруется. Наличие одного подраздела в разделе эквивалентно их фактическому отсутствию. Пункты, при необходимости, могут быть разбиты на подпункты, которые должны иметь порядковую нумерацию в пределах каждого пункта, например 4.2.1.1, 4.2.1.2, 4.2.1.3 и т. д.
Перечисления
Внутри пунктов или подпунктов могут быть приведены перечисления. Перед каждым перечислением следует ставить дефис или, при необходимости ссылки в тексте документа на одно из перечислений, строчную букву (за исключением ё, з, о, г, ь, и, ы, ъ), после которой ставится скобка. Для дальнейшей детализации перечислений необходимо использовать арабские цифры, после которых ставится скобка, а запись производится с абзацного отступа, как показано в примере.
Пример
а)___________
б) ___________
1)_____
2)_____
в)
___________
Каждый структурный элемент отчета следует начинать с нового листа (страницы). Нумерация страниц отчета и приложений, входящих в состав отчета, должна быть сквозная.
Иллюстрации
Иллюстрации (чертежи, графики, схемы, компьютерные распечатки, диаграммы, фотоснимки) следует располагать в отчете непосредственно после текста, в котором они упоминаются впервые, или на следующей странице. Иллюстрации могут быть в компьютерном исполнении, в том числе и цветные. На все иллюстрации должны быть даны ссылки в отчете. Чертежи, графики, диаграммы, схемы, иллюстрации, помещаемые в отчете, должны соответствовать требованиям государственных стандартов Единой системы конструкторской документации (ЕСКД). Допускается выполнение чертежей, графиков, диаграмм, схем посредством использования компьютерной печати. Фотоснимки размером меньше формата А4 должны быть наклеены на стандартные листы белой бумаги. Иллюстрации, за исключением иллюстрации приложений, следует нумеровать арабскими цифрами сквозной нумерацией. Если рисунок один, то он обозначается «Рисунок 1». Слово «рисунок» и его наименование располагают посередине строки. Допускается нумеровать иллюстрации в пределах раздела. В этом случае номер иллюстрации состоит из номера раздела и порядкового номера иллюстрации, разделенных точкой. Например, Рисунок 1.1. Иллюстрации, при необходимости, могут иметь наименование и пояснительные данные (подрисуночный текст). Слово «Рисунок» и наименование помещают после пояснительных данных и располагают следующим образом: Рисунок 1 — Детали прибора. Иллюстрации каждого приложения обозначают отдельной нумерацией арабскими цифрами с добавлением перед цифрой обозначения приложения. Например, Рисунок А.3. При ссылках на иллюстрации следует писать «... в соответствии с рисунком 2» при сквозной нумерации и «... в соответствии с рисунком 1.2» при нумерации в пределах раздела.
Таблицы
Таблицы применяют для лучшей наглядности и удобства сравнения показателей. Название таблицы, при его наличии, должно отражать ее содержание, быть точным, кратким. Название таблицы следует помещать над таблицей слева, без абзацного отступа в одну строку с ее номером через тире. При переносе части таблицы название помещают только над первой частью таблицы, нижнюю горизонтальную черту, ограничивающую таблицу, не проводят. Таблицу следует располагать в отчете непосредственно после текста, в котором она упоминается впервые, или на следующей странице. На все таблицы должны быть ссылки в отчете. При ссылке следует писать слово «таблица» с указанием ее номера. Таблицу с большим количеством строк допускается переносить на другой лист (страницу). При переносе части таблицы на другой лист (страницу) слово «Таблица» и номер ее указывают один раз справа над первой частью таблицы, над другими частями пишут слово «Продолжение» и указывают номер таблицы, например: «Продолжение таблицы 1». При переносе таблицы на другой лист (страницу) заголовок помещают только над ее первой частью. Таблицу с большим количеством граф допускается делить на части и помещать одну часть под другой в пределах одной страницы. Если строки и графы таблицы выходят за формат страницы, то в первом случае в каждой части таблицы повторяется головка, во втором случае — боковик. Если повторяющийся в разных строках графы таблицы текст состоит из одного слова, то его после первого написания допускается заменять кавычками; если из двух и более слов, то при первом повторении его заменяют словами «То же», а далее — кавычками. Ставить кавычки вместо повторяющихся цифр, марок, знаков, математических и химических символов не допускается. Если цифровые или иные данные в какой-либо строке таблицы не приводят, то в ней ставят прочерк. Цифровой материал, как правило, оформляют в виде таблиц. Пример оформления таблицы приведен на рисунке 1.
| Таблица |
____________ |
____________ |
____________ |
| номер |
название |
таблицы |
|
| Заголовки граф |
|||
| Головка |
Подзаголовки граф |
||
| Строки (горизонтальные ряды) |
|||
| Боковик для |
(графа заголовков) |
Графы |
(колонки) |
Рисунок 1
Таблицы, за исключением таблиц приложений, следует нумеровать арабскими цифрами сквозной нумерацией. Допускается нумеровать таблицы в пределах раздела. В этом случае номер таблицы состоит из номера раздела и порядкового номера таблицы, разделенных точкой. Таблицы каждого приложения обозначают отдельной нумерацией арабскими цифрами с добавлением перед цифрой обозначения приложения. Если в документе одна таблица, то она должна быть обозначена «Таблица 1» или «Таблица В. 1», если она приведена в приложении В. Заголовки граф и строк таблицы следует писать с прописной буквы в единственном числе, а подзаголовки граф — со строчной буквы, если они составляют одно предложение с заголовком, или с прописной буквы, если они имеют самостоятельное значение. В конце заголовков и подзаголовков таблиц точки не ставят. Таблицы слева, справа и снизу, как правило, ограничивают линиями. Допускается применять размер шрифта в таблице меньший, чем в тексте. Разделять заголовки и подзаголовки боковика и граф диагональными линиями не допускается. Горизонтальные и вертикальные линии, разграничивающие строки таблицы, допускается не проводить, если их отсутствие не затрудняет пользование таблицей. Заголовки граф, как правило, записывают параллельно строкам таблицы. При необходимости допускается перпендикулярное расположение заголовков граф. Головка таблицы должна быть отделена линией от остальной части таблицы. Оформление таблиц в отчете должно соответствовать ГОСТ 2.105. (http://www.montaz.ru/support/gost_2_105-95%20_2001_.pdf)
Примечания
Слово «Примечание» следует печатать с прописной буквы с абзаца и не подчеркивать. Примечания приводят в документах, если необходимы пояснения или справочные данные к содержанию текста, таблиц или графического материала. Примечания не должны содержать требований. Примечания следует помещать непосредственно после текстового, графического материала или в таблице, к которым относятся эти примечания. Если примечание одно, то после слова «Примечание» ставится тире и примечание печатается с прописной буквы. Одно примечание не нумеруют. Несколько примечаний нумеруют по порядку арабскими цифрами без проставления точки. Примечание к таблице помещают в конце таблицы над линией, обозначающей окончание таблицы.
Пример
Примечание
-__________________________________________ ____________________________
Несколько примечаний нумеруются по порядку арабскими цифрами.
Пример
Примечания
1_______________________________________________
2_______________________________________________
3_______________________________________________
Формулы и уравнения
Уравнения и формулы следует выделять из текста в отдельную строку. Выше и ниже каждой формулы или уравнения должно быть оставлено не менее одной свободной строки. Если уравнение не умещается в одну строку, то оно должно быть перенесено после знака равенства (=) или после знаков плюс (+), минус (-), умножения (х), деления (:), или других математических знаков, причем знак в начале следующей строки повторяют. При переносе формулы на знаке, символизирующем операцию умножения, применяют знак «X». Пояснение значений символов и числовых коэффициентов следует приводить непосредственно под формулой в той же последовательности, в которой они даны в формуле. Формулы в отчете следует нумеровать порядковой нумерацией в пределах всего отчета арабскими цифрами в круглых скобках в крайнем правом положении на строке.
Пример А=а:b,
(1)
В=с:е.
(2)
Одну формулу обозначают — (1)
.
Формулы, помещаемые в приложениях, должны нумероваться отдельной нумерацией арабскими цифрами в пределах каждого приложения с добавлением перед каждой цифрой обозначения приложения, например формула (В. 1). Ссылки в тексте на порядковые номера формул дают в скобках. Пример —... в формуле (1). Допускается нумерация формул в пределах раздела. В этом случае номер формулы состоит из номера раздела и порядкового номера формулы, разделенных точкой, например (3.1).
Ссылки
В отчете допускаются ссылки на данный документ, стандарты, технические условия и другие документы при условии, что они полностью и однозначно определяют соответствующие требования и не вызывают затруднений в пользовании документом. Ссылаться следует на документ в целом или его разделы и приложения. Ссылки на подразделы, пункты, таблицы и иллюстрации не допускаются, за исключением подразделов, пунктов, таблиц и иллюстраций данного документа. При ссылках на стандарты и технические условия указывают только их обозначение, при этом допускается не указывать год их утверждения при условии полного описания стандарта в списке использованных источников в соответствии с ГОСТ 7.1. Ссылки на использованные источники следует приводить в квадратных скобках.
Перечень обозначений и сокращений, условных обозначений, символов, единиц физических величин и терминов
Перечень должен располагаться столбцом. Слева в алфавитном порядке приводят сокращения, условные обозначения, символы, единицы физических величин и термины, справа — их детальную расшифровку.
Список использованных источников
Сведения об источниках следует располагать в порядке появления ссылок на источники в тексте отчета и нумеровать арабскими цифрами без точки и печатать с абзацного отступа.
Приложения
Приложение оформляют как продолжение данного документа на последующих его листах или выпускают в виде самостоятельного документа. В тексте документа на все приложения должны быть даны ссылки. Приложения располагают в порядке ссылок на них в тексте документа, за исключением справочного приложения «Библиография», которое располагают последним. Каждое приложение следует начинать с новой страницы с указанием наверху посередине страницы слова «Приложение», его обозначения и степени. Приложение должно иметь заголовок, который записывают симметрично относительно текста с прописной буквы отдельной строкой. Приложения обозначают заглавными буквами русского алфавита, начиная с А, за исключением букв Ё, З, И, О, Ч, Ь, Ы, Ъ. После слова «Приложение» следует буква, обозначающая его последовательность. Допускается обозначение приложений буквами латинского алфавита, за исключением букв I и O. В случае полного использования букв русского и латинского алфавитов допускается обозначать приложения арабскими цифрами. Если в документе одно приложение, оно обозначается «Приложение А». Текст каждого приложения, при необходимости, может быть разделен на разделы, подразделы, пункты, подпункты, которые нумеруют в пределах каждого приложения. Перед номером ставится обозначение этого приложения. Приложения должны иметь общую с остальной частью документа сквозную нумерацию страниц. При необходимости такое приложение может иметь «Содержание».
В Приложении к этим методическим указаниям дается статья о том как сделать в Word шаблон, удовлетворяющий приведенным требованиям (http://www.computerra.ru/gid/303592/)
3. ПОДГОТОВКА К ЗАЩИТЕ И ЗАЩИТА ДИПЛОМНОЙ РАБОТЫ.
В середине июня проходят заседания Государственной аттестационной комиссии (ГАК), на которых проводится защита дипломных работ. На кафедре заранее вывешивается график работы ГАК, и студенты записываются на определенные дни. В один день не может быть более 10 защит.
На защиту дипломник представляет следующие материалы:
· пояснительная записка (на титульном листе подписи студента, консультанта, руководителя, зав.кафедрой);
· отзыв руководителя дипломной работы.
· рецензия;
Последние два документа не подшиваются в пояснительную записку, а вкладываются в нее.
Отзыва консультанта не требуется. Дипломник готовит для заседания ГАК устный доклад и иллюстративный графический материал (компьютерную презентацию и комплекты распечаток слайдов).
3.1.Отзыв руководителя.
Руководитель составляет отзыв (допускается рукописный), в котором дает оценку полученным в дипломной работе результатам, отмечает глубину проработки темы, новизну и оригинальность найденных решений, характеризует дипломника как будущего специалиста, отмечает возможность внедрения работы. Заканчивается отзыв предложением оценки дипломной работы. Дается также заключение, достоин ли дипломник присвоения квалификации "инженер-математик".
3.2. Рецензия.
Рецензентом дипломной работы может быть любой специалист с высшим образованием, имеющий практический опыт в области, связанной с тематикой дипломной работы. Не допускается рецензирование сотрудником кафедры, на которой выполнялась дипломная работа. Консультант не может быть рецензентом. Рецензента рекомендует руководитель работы (по согласованию с зав. кафедрой). Рецензент знакомится с пояснительной запиской и на ее основании составляет рецензию.
Рецензия должна удовлетворять следующим требованиям:
1. Рецензия оформляется на стандартном листе бумаги, текст печатается через 1,5 интервала, объем не более одной-двух страницы;
2. В рецензии должны быть указаны цель и задачи, поставленные в дипломной работе, ее актуальность, перечислены результаты, полученные в дипломной работе, отмечены возможности внедрения результатов дипломной работы в практику (указать особо, если результаты дипломной работы внедрены);
3. В конце рецензии отмечаются положительные и отрицательные стороны рецензируемой работы. Рецензент не может уклоняться от оценки работы по существу. Недопустимо, например, такое заключение: "Работа заслуживает положительной оценки" (какой?).
В конце подпись рецензента с указанием должности и ученой степени. Если рецензент работает не в МИЭМ, то его подпись должна быть заверена в отделе кадров учреждения, где он работает, а также скреплена печатью.
Можно рекомендовать следующую форму рецензии.
РЕЦЕНЗИЯ
на дипломную работу студента факультета Прикладной математики Московского государственного института электроники и математики И.П.Сидорова "Синтез адаптивной системы стабилизации крена летательного аппарата".
.......................................................
На основе пояснительной записки можно сделать вывод, что в процессе выполнения дипломной работы И.П.Сидоров показал хорошее владение фундаментальными понятиями линейной алгебры, теории управления, продемонстрировал навыки программирования и моделирования на ЭВМ. Поэтому дипломная работа заслуживает отличной оценки, а И.П.Сидоров присвоения квалификации "инженер-математик".
| Подпись В.А.Федорова заверяю. Ст.инспектор ОК (подпись) Иванова С.И. <печать> |
02.06.2009 Ст. научный сотрудник ОКБ "Альфа", к.т.н. (подпись) /В.А.Федоров/ |
В настоящее время МИЭМ не оплачивает подготовку рецензии.
3.3. Подготовка доклада.
На устное сообщение о работе на заседании ГАК дипломнику отводится не более 10 минут (это немало — для сравнения заметим, для доклада по кандидатской диссертации Положением ВАК отводится 20 минут, а по докторской 30 минут). Нужно тщательно продумать план доклада, чтобы уложиться в отведенное время и дать сжатое, но полное изложение результатов работы.
Основная ошибка при составлении доклада — дипломник пытается прочитать комиссии лекцию о предметной области, об использованных средствах вычислительной техники, программном обеспечении. Комиссия ждет изложения РЕЗУЛЬТАТОВ работы, чтобы оценить уровень квалификации автора.
Образно говоря, доклад должен отвечать на три вопроса: ЗАЧЕМ? ЧТО? и КАК? Поэтому одну-две минуты следует уделить постановке задачи, далее кратко изложить все важные этапы и результаты работы и несколько подробнее остановится на наиболее интересных деталях работы, четко сформулировать конечные выводы. Закончить доклад нужно краткой характеристикой разработанного программного обеспечения и перспективами внедрения работы.
Текст доклада необходимо обсудить (и, возможно, не один раз) с руководителем и консультантом, и несколько раз отрепетировать, чтобы произносить его свободно, не запинаясь и не заглядывая ни в какие записи.
3.4. Графический материал.
Разумеется, за десять минут невозможно достаточно полно изложить результаты работы, если в процессе доклада не использовать заранее подготовленный графический материал. Для этого дипломник готовит компьютерную презентацию в пакете PowerPoint (он входит в состав Microsoft Office). Презентация содержит набор слайдов. Слайды распечатываются и их комплекты раздаются членам ГАК перед защитой.
Одновременно с подготовкой доклада дипломник должен продумать содержание слайдов, иллюстрирующих доклад. Обычно достаточно 10–12 слайдов. Их снабжают порядковыми номерами (Вставка → Номер слайда) и заголовками. Слайды выполняются на белом фоне. Не допускается использование каких-либо эффектов (выпадающие надписи и т.д.).
Нужно предварительно нарисовать эскизы слайдов на стандартных листах формата А4 и обсудить их содержание с руководителем (доклад и слайды одновременно), а затем готовить файл презентации.
Можно рекомендовать следующий план расположения материала на слайдах.
1. Предметная область, постановка задачи.
2. Математическая модель.
3. Структура программного обеспечения. (Здесь целесообразно изобразить граф подчиненности модулей, о котором говорилось ранее; если студент работал в составе коллектива (бригады программистов), то желательно модули, разработанные лично им, выделить цветом или рамкой).
4. Схемы алгоритмов (по выбору).
5. Входные и выходные данные для контрольного примера.
Еще раз подчеркнем, что предлагаемый перечень является примерным. Последний слайд может быть разбит на два и, напротив, первые два можно объединить. Иногда дипломники пытаются поместить на слайды чуть ли не все содержание пояснительной записки. Следует провести строгий отбор представляемого материала (например, изображать схемы не всех алгоритмов, описанных в работе, а только наиболее значимых).
Надписи на слайдах следует делать крупными, чтобы их можно было прочитать с расстояния не менее 10 м. Следует рисовать на слайдах укрупненные фрагменты выходных форм. Дело в том, что при проецировании слайдов на экран мелкие детали изображения трудно различить из-за недостаточно точной фокусировки.
3.5. Процедура защиты.
Накануне защиты дипломник передает ответственному секретарю ГАК упомянутые выше документы (пояснительную записку, отзыв, рецензию). Непосредственно в день защиты дипломник заранее копирует файл с презентацией на компьютер, присоединенный к проектору. Дипломников приглашают на защиту в соответствии с заранее составленным списком. Ответственный секретарь представляет комиссии дипломника и оглашает тему дипломной работы. Председательствующий предоставляет дипломнику слово для доклада.
Дипломник докладывает о своей работе, как уже говорилось, не более 10 минут. Неблагоприятное впечатление производит доклад, зачитываемый по бумажке. Учить доклад наизусть излишне, но следует свободно владеть его содержанием, и произносить, не заглядывая ни в какие бумаги. Во время доклада нужно активно использовать слайды.
После доклада члены ГАК и все желающие задают дипломнику вопросы. Вопросы, как правило, призваны выявить общую эрудицию дипломника: его спрашивают, почему он выбрал те или иные программные средства, какое место занимает его работа среди аналогичных. Некоторые дипломники психологически оказываются не готовы к этому, т.к. ждут вопросов, касающихся частных технических деталей. Могут быть заданы вопросы не только по докладу, но и непосредственно по тексту пояснительной записки. На вопросы следует отвечать кратко, чётко, не увлекаясь изложением излишних подробностей. Следует помнить, что это не доклад на конференции или научном семинаре, где слушателей интересует содержание работы. Это квалификационное мероприятие, где определяется уровень докладчика. Если ответ на какой-либо вопрос уже содержался в выступлении, не следует с досадой указывать спрашивающему, что он невнимательно слушал доклад. Не следует также негативно реагировать на вопросы, заданные "невпопад". Наивно полагать, что все члены ГАК должны детально разбираться в работе. Таким образом, защита дипломной работы является еще и своеобразной школой этики научной дискуссии, что может пригодиться и в дальнейшей деятельности.
Далее комиссия заслушивает рецензию и отзыв руководителя. Дипломнику предоставляется слово для ответа на замечания. На этом защита завершается.
После заслушивания всех дипломников, защита которых назначена на текущий день, комиссия (на закрытом заседании) обсуждает представленные работы, принимает решение о присвоении квалификации "инженер" и определяет оценки дипломных работ. После этого дипломники приглашаются в аудиторию. Им зачитывается решение ГАК.
Пояснительная записка после защиты хранится на кафедре.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Безбородов Ю.М. Индивидуальная отладка программ.— М.: Наука, 1982.— 192 с.
2. Благодатских В.А., Волнин В.А. Поскакалов К.Ф. Стандартизация разработки программных средств. — М.: Финансы и статистика, 2003. — 288 с.
3. Гримм С.Дж. Как писать руководства для пользователей ЭВМ. — М.: Радио и связь, 1985.— 160 с.
4. Калинин С.Ю. Библиографический аппарат научной работы. // Библиография, №2, 1993, С.36-45.
5. Кнут Д. Искусство программирования для ЭВМ. Т.1. Основные алгоритмы.— М.: Мир, 1976.— 736 с.
6. Кушниренко А.Г., Лебедев Г.В. Программирование для математиков.— М.: Наука, 1988.— 384 с.
7. Хьюз Дж., Мичтом Дж. Структурный подход к программированию.— М.: Мир, 1980.— 280 с.
Приложение
1. Бланк титульного листа дипломной работы (руководитель и консультант).
2. Бланк титульного листа дипломной работы (руководитель одновременно консультант).
(на титульном листе указывать ученое звание и ученую степень руководителя и консультанта)
3. Образец заполнения бланка задания
4. Образец отзыва
5. Образец рецензии
МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ
(ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)
КАФЕДРА МОСОИиУ
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
К ДИПЛОМНОЙ РАБОТЕ
по специальности 230201 «Информационные системы и технологии»
на тему:
Студент / /
Руководитель звание, степень / /
Консультант должность, место работы, звание, степень / /
Допущен к защите 01 июня 2009 г.
Зав. кафедрой ___________________
МОСКВА
МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ
(ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)
КАФЕДРА МОСОИиУ
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
К ДИПЛОМНОЙ РАБОТЕ
по специальности 230201 «Информационные системы и технологии»
на тему:
Студент / /
Руководитель и консультант звание, степень / /
Допущен к защите 01 июня 2009 г.
Зав.кафедрой ___________________
МОСКВА
МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ
(технический университет)
| Кафедра МОСОИиУ "УТВЕРЖДАЮ" Зав. кафедрой ___________ /Г.П.Путилов/ . .2009 |
З А Д А Н И Е
на дипломную работу
студент группы МС10-01 дневного отделения
Иванова Надежда Александровна
I. Тема работы. Автоматизация учётной работы в планово-финансовом управлении.
(Утверждена приказом по институту от . .2009 № )
II. Срок сдачи студентом законченной работы: 01 июня 2009 г.
III. Техническое задание. Провести анализ учётной работы планово-финансового управления (ПФУ). Построить информационную модель работы ПФУ. Разработать программы, автоматизирующие работу ПФУ. Провести анализ результатов, выполненной работы.
IV. Содержание расчетно-пояснительной записки.
А. Специальная часть проекта.
1. VBA – средство автоматизации Microsoft Office.
2. Информационная модель работы планово-финансового управления (ПФУ).
3. Автоматизация работы ПФУ.
Б. Решение задачи на ЭВМ.
1. Разработка структуры данных и алгоритмов их обработки.
2. Разработка программной реализации алгоритмов.
V. Консультанты по проекту
Консультант по специальной части
начальник планово-финансового управления ВНИИГЭ
/Петрова Е.В./
VI. Дата выдачи задания: 27 марта 2009 г.
Руководитель дипломной работы /доц., к.т.н. Лавренов С.М./
Задание принял к исполнению /Иванова Н.А./
27 марта 2009 г.
Отзыв
на дипломную работу
студентки факультета Прикладной математики МИЭМ Н.А.Ивановой "Автоматизация учётной работы в планово-финансовом управлении".
В дипломной работе предпринята попытка автоматизации планово-финансового управления (ПФУ) на основе программного продукта Microsoft Excel из пакета Microsoft Office 97 в среде Windows 98 с использованием возможностей встроенного языка VBA (Visual Basic for Applications). В частности, разработано программное обеспечение по двум основным направлениям деятельности ПФУ: плановые расходы и расчёт зарплаты. Причём по причине полной обособленности этих направлений программное обеспечение реализовано в виде двух отдельных модулей.
При выполнении дипломной работы были изучены принципы трёхуровневой архитектуры ANSI-SPARC и технология построения приложений этой архитектуры.
Дипломница показала глубокие знания в области проектирования баз данных и в работе с Excel. Ею освоен встроенный язык пакета Microsoft Office 97 VBA. Эти знания применены при создании двух локальных баз данных, представлений и создании многочисленных запросов к базам данным.
При реализации подсистем создано более 50 различных шаблонов для автоматического формирования документов в приложении Excel пакета Microsoft Office 97. Подсистемы реализованы средствами языка Visual Basic for Applications. Следует отметить, что результаты дипломной работы применены на практике, и разработанные программы успешно функционируют в планово-финансовом управлении.
При выполнении дипломной работы Н.А.Иванова продемонстрировала навыки проектирования баз данных и работы с СУБД Excel. Работа соответствует требованиям, предъявляемым к дипломным работам по специальности «Информационные системы и технологии» и заслуживает отличной оценки. Н.А.Иванова заслуживает присвоения квалификации "инженер".
Руководитель работы
доцент каф. МОСОИиУ, к.т.н.
С.М.Лавренов
Рецензия
на дипломную работу студентки факультета Прикладной математики Московского государственного института электроники и математики (МИЭМ) Н.А. Ивановой "Автоматизация учётной работы в планово-финансовом управлении".
Дипломная работа посвящена актуальной теме – созданию сложного программного обеспечения с использованием современных средств разработки приложений. Предметом автоматизации дипломной работы стало планово-финансовое управление (ПФУ). Автор автоматизировал два основных направления работы ПФУ: плановые расходы и расчёт зарплаты.
При выполнении дипломной работы были изучены принципы архитектуры ANSI-SPARC и технология построения приложений этой архитектуры. Показаны глубокие знания в области проектирования баз данных и в работе с процессором электронных таблиц Excel. Освоен встроенный язык пакета Microsoft Office 97 VBA. Знания применены при создании баз данных, представлений и создании многочисленных запросов к базам данных.
При реализации подсистемы создано более 50 различных шаблонов для автоматического формирования документов в приложении Excel пакета Microsoft Office 97. Подсистема реализована средствами языка Visual Basic for Applications. Продемонстрирован высокий уровень навыков составления алгоритмов.
Результаты дипломной работы применены на практике, и разработанное программное обеспечение успешно функционирует в планово-финансовом управлении ВНИИГЭ.
К работе имеются следующие замечания:
1) недостаточно обоснован выбор приложения Excel, т.е. не рассмотрены альтернативы использования других приложений и не показано, что используемое приложение является эффективнее по каким-либо критериям;
2) в рамках дипломной работы не рассмотрено ещё одно направление деятельности ПФУ – учёт кадров.
Однако эти замечания не снижают общего положительного впечатления от работы, выполненной на хорошем математическом уровне, с использованием современных средств создания программного обеспечения.
При выполнении дипломной работы Н.А.Иванова продемонстрировала навыки проектирования баз данных и работы с Excel. Работа соответствует требованиям, предъявляемым к дипломным работам по специальности «Информационные системы и технологии» и заслуживает отличной оценки. Н.А.Иванова заслуживает присвоения квалификации "инженер".
Ст. преподаватель каф. Кибернетики МИЭМ
А.Б. Соловьева
Приложение
Создание стилей для заголовков и многоуровневых списков в Word
Автор: Антон Кокин Опубликовано 25 января 2007 года
Последний месяц я плотно занимался разработкой шаблонов для создания программных документов, предусмотренных ГОСТами: техническое задание на программу, руководство пользователя, описание применения и других. Казалось бы, ничего сложного в этой деятельности нет. Вставляй нужные разделы, разрывы страниц, поля для будущего текста. Однако у меня возникли сложности с оформлением документов, а конкретно - со стилями заголовков и многоуровневых списков.
Согласно государственным стандартам, заголовки в документе должны начинаться с определенного абзацного отступа, оформляться единообразным шрифтом, и не иметь точки после последней цифры в нумерации. Кроме того, есть и другие требования к оформлению, которые нужно учитывать.
Опытный пользователь редактора Word, возможно, усмехнется и скажет: да что здесь сложного? Ввел текст для заголовка, придал ему нужный шрифт и форматирование либо применил к нему стиль заголовка нужного уровня и нажал кнопку "Нумерация" на панели форматирования. Всё так, но в итоге в документе образуется множество различных неупорядоченных стилей, в которых можно потеряться и которые никак не способствуют улучшению внешнего вида документа. А ведь есть еще и многоуровневые списки, представляющиеся многим совершенно запутанными и непонятными в применении.
В этой заметке я расскажу о своем способе укрощения заголовков и многоуровневых списков, создав для них соответствующие стили. Настоятельно рекомендую использовать стили при создании любых документов. Создание стиля займет всего несколько минут, но при последующем форматировании текста документа созданный вами стиль сэкономит массу времени и нервов.
Итак, передо мной стояла задача использовать в документе нумерованные заголовки четырех разных уровней для обозначения разделов документа. Эти разделы должны были иметь также свои нумерованные подразделы. Вот образец правильных многоуровневых нумерованных заголовков:
Первым делом необходимо отредактировать стандартные стили заголовков, встроенные в глобальный шаблон Normal.dot или в ваш собственный шаблон, разработанный для тех или иных документов. Для того, чтобы увидеть используемые стили в шаблоне или документе, выберите из пункта меню "Формат" (Format) подпункт (команду) "Стили и форматирование" (Styles and Formatting). Справа от рабочей области программы появится одноименная область задач, как на скриншоте ниже:
Стандартно отображаются основные стили трехуровневых заголовков и стиль "Обычный", то есть стиль простого текста документа. Чтобы отобразить больше стилей в этой области, вы можете выбрать в раскрывающемся списке "Показать" (Show) в нижней части области задач параметр "Специальное" (Custom). Откроется вот такое диалоговое окно:
Если задана категория "Доступные стили" (Available Styles), то в области "Отображаемые стили" будут отображены только те стили, которые использованы при создании данного документа. Обычно галочками отмечены три уровня заголовков. Если вам нужно использовать четвертый уровень заголовка, то отметьте флажком "Заголовок 4". Вполне возможно, что в области "Отображаемые стили" не будет такого стиля. В этом случае выберите категорию "Все" (All Styles) и отметьте флажками только заголовки с 1 по 4 и стиль "Обычный", а также те стили, которые были созданы лично вами. Закройте окно "Настройки формата" щелчком мыши на кнопке ОК.
Вторым нашим шагом будет тонкая настройка стилей заголовков. Заголовкам изначально присвоены шрифты с разным форматированием. Для создания программного документа, согласно ГОСТам, необходимо использовать единый шрифт для всего документа. Я использую шрифт Times New Roman 14 пт для стиля "Обычный". Для заголовков я тоже буду использовать этот шрифт, изменяя лишь его размер и интервалы.
Чтобы изменить стиль заголовка, наведите указатель мыши на "Заголовок 1" в области задач. Надпись отобразится в рамке и справа от нее появится кнопка с треугольником. Щелкните по этому треугольнику, и перед вами откроется контекстное меню для данного стиля. Выберите в нём команду "Изменить" (Modify), и появится диалоговое окно "Изменение стиля".
В поле "Основан на стиле" (Style based on) выберите из раскрывающегося списка значение "Нет" (No style). Поле "Стиль следующего абзаца" (Style for following paragraph) оставьте без изменения. Затем нажмите кнопку "Формат" в нижней части окна и выберите нужные команды для изменения настроек. Для изменения шрифта используйте команду "Шрифт", для изменения абзацного отступа и интервалов предусмотрена команда "Абзац". Произведите требуемые вам изменения. Я, например, для "Заголовка 1" установил следующие параметры: шрифт - Times New Roman полужирный 18 пт, абзац - выравнивание по левому краю, отступ первой строки на 1,5 см, интервал перед 0 пт, после 3 пт, междустрочный двойной, табуляция - установить 3,5 см с левого края без заполнителя.
Если вы хотите применить произведенные изменения для шаблона, на основе которого вы потом будете создавать ваши документы, то поставьте флажок в поле "Добавить в шаблон" (Add to template), иначе все эти изменения будут применены лишь к активному в данный момент документу.
Аналогично я изменил стиль оставшихся заголовков, соответственно уменьшив для каждого из них размер шрифта: "Заголовок 2" - полужирный 16 пт, "Заголовок 3" - полужирный 15 пт, "Заголовок 4" - полужирный 14 пт.
Таким образом, я настроил нужные мне в шаблоне стили заголовков. Теперь необходимо было создать стиль для многоуровневых списков.
Из пункта меню "Формат" выберите команду "Списки" (Bullets and Numbering). Откроется одноименное диалоговое окно. Перейдите на вкладку окна "Список стилей" (List Styles) и нажмите кнопку "Добавить" (Add). Перед вами откроется окно "Создание стиля" (New Style) со знакомым интерфейсом и кнопками:
В поле "Имя" (Name) введите название вашего стиля (пусть будет "Нумерация_заголовков"). Затем нажмите кнопку "Формат" в нижней части окна и выберите нужные команды для изменения настроек. Доступными будут всего лишь три команды: "Шрифт", "Нумерация" и "Сочетание клавиш".
Обратите внимание на поле "Применить форматирование к" (Apply formatting to). Стандартно там будет установлено значение "Заголовок 1". Задавая форматирование нумерации, вы применяете его исключительно к этому заголовку. Соответственно, выбрав в этом поле следующее значение - "Заголовок 2" - вы должны задать и для него то форматирование, которое ранее было задано для "Заголовка 2".
Выберите команду "Нумерация" (Numbering) и перед вами откроется диалоговое окно "Список". Щелкните мышью на любом образце списка и кнопка "Изменить" (Customize) в нижней части окна станет активной. Нажмите ее. Откроется новое окно, показанное на скриншоте ниже.
В этом окне нам предстоит настраивать стили нумерации каждого из заголовков. Выберите нужный уровень, например 1. В окне отобразятся параметры, применяемые к данному уровню. Здесь вы можете настроить шрифт нумерации, абзацный отступ. Если это окно открылось в кратком виде, нажмите кнопку "Больше" (More) и будут доступны дополнительные параметры для настройки.
Выберите команду "Шрифт". Перед вами появится уже знакомое диалоговое окно, в котором установите такие же параметры, которые вы задавали для "Заголовка 1". Обязательно снимите все флажки в группе "Видоизменение" (Effects) - они будут бледного цвета, задайте цвет текста, отсутствие подчеркивания и проверьте все остальные настройки в других вкладках окна.
В группе "Положение номера" (Number Position) установите положение по левому краю на 1,5 см. В группе "Положение текста" (Text Position) установите табуляцию после 3,5 см, отступ 0 см. Выберите из открывающегося списка в параметре "Связать уровень со стилем" (Link level to style) значение "Нет". Значение в поле "Символ после номера" (Follow number with) оставьте как есть - знак табуляции.
Повторите эти действия для всех ваших уровней-заголовков в шаблоне. По окончании нажмите кнопку ОК и не забудьте отметить флажком поле "Добавить в шаблон". В области задач "Стили и форматирования" появится новый элемент (стиль) с вашим именем "Нумерация_заголовков".
Последнее, что нам потребуется сделать - проверить на практике работу стилей. Для этого введите в документ несколько строк какого-нибудь текста. Введите не меньше семи строк, чтобы проверить разные уровни заголовков. Поставьте курсор мыши на первую строку текста и примените1
к ней стиль "Заголовок 1". Затем примените к этому же тексту созданный вами стиль "Нумерация_заголовков". Повторите эти действия в заданной последовательности (Заголовок -> Нумерация_заголовка) для остальных строк, каждый раз применяя для них разные уровни. Должен получиться примерно такой вот иерархический список:
Как вы можете заметить, в нижней части окна у меня отобразился уровень "Заголовок 2", но с нарушенной нумерацией - 1.1. Такое бывает. И исправить это очень легко. Достаточно щелкнуть правой кнопкой мыши на этом номере, чтобы отобразилось контекстное меню. Выберите в этом меню команду "Продолжить нумерацию" (Continue previous list) и заголовок получит правильный номер, в данном случае - 2.2.
Надеюсь, вы поняли, как создаются стили и как они модифицируются. Также искренне надеюсь, что эта заметка поможет вам создавать правильные стили заголовков и красиво, а главное единообразно оформлять ваши документы.
1. Применить стиль буквально означает следующее: поставьте курсор в строке, стиль которой вам нужно изменить. В области задач "Стили и Форматирование" щелкните мышью на нужном стиле. Стиль будет применен к строке.
Комментарий
По-видимому, в качестве образца можно использовать уже цитировавшийся ГОСТ 7.32-2001. Шрифт Times New Roman, размер (кегль) 12 пунктов. Абзацный отступ 0.85 см. Абзацный отступ для заголовка 1.27 см.
Приложение.
Следующий текст в дальнейшем планируется включить в основной текст методических указаний, привязав его к этапам выполнения дипломной работы (УИР, преддипломная практика, выполнение дипломной работы, оформление пояснительной записки, защита работы на заседании ГАК).
Введение
Первый раздел
пособия содержит основные понятия о проекте. Здесь приведены общие сведения о проекте и его жизненном цикле. Дано описание работ необходимых для реализации фаз жизненного цикла проекта (концепции, как начальной фазы; разработки; реализации; завершения). Причем проект рассматривается как абстрактный объект без привязки к предметной области.
Второй раздел
посвящен вопросам управления проектом, приведено понятие и проблемные области управления проектом. Процессы, направленные на достижение определенного результата подразделяются на две категории:
· процессы управления проектом,
· предметно-ориентированные процессы, включающие в себя описание и создание конечного продукта, ради которого предпринимается проект.
Процессы первой категории описывают проект как обобщенную абстрактную модель.
Процессы второй категории определяются жизненным циклом проекта и наполняют его специфическим содержанием предметной области.
В абстрактной модели в качестве объекта управления выступает проект, разбитый по фазам жизненного цикла. Для каждой фазы выполняется группа процессов управления, а именно процессы инициализации, планирования, организации исполнения, анализа, оперативного управления, завершения. Приведены перечни действий, составляющих сущность перечисленных процессов управления.
Третий раздел
содержит обоснование выбора методологии моделирования бизнес-процессов. В этом разделе приведены требования к модели предметной (проблемной) области (формализованность; применение графических средств отображения модели; наличие средств физической реализации модели, например программных средств создания информационной системы; оценка эффективности).
Все сущности, составляющие предприятие, должны быть соединены в единую систему понятным и непротиворечивым образом. Поэтому даже вопросов «простого» согласования компонентов системы достаточно для того, чтобы прилагать специальные усилия на уровне формирования архитектуры. С этой целью рассмотрена матрица согласованных моделей предметной (проблемной) области в архитектурах – схема Захмана. В качестве разделов построения архитектур используются такие как:
· цели создания системы и бизнес-правила;
· сотрудники, выполняющие работу (участники процесса);
· функции, реализуемые в системе;
· объекты – данные;
· коммуникации (сеть);
· время – события.
Столбцы матрицы фактически отражают архитектуры разделов обеспечения системы. Строки матрицы отражают уровни представления системы, к ним относятся уровни моделирования, уровни решения проектных задач. Описанные разделы и уровни схемы Захмана являются классификацией сущностей предприятия
и его информационной системы.
Матрица согласованных моделей служит простым, но достаточно мощным инструментом по применению системного подхода
для планирования работ по созданию и использованию автоматизированных информационных систем и стыковки этих работ.
В роли основных участников проектирования информационной системы (строки матрицы) выступают пользователи, заказчики, проектировщики, разработчики. Инициатором проекта, в принципе может быть любой из участников. Однако, как правило, в этой роли выступает заказчик, который финансирует разработку.
Основой разработки методологии для обоснования конфигурации предприятия является применение процессного подхода
, который подразумевает управление сквозными цепочками выполняемых функций, бизнес – процессом, как единым целым. В этой связи описана концептуальная схема управления бизнес-процессом. Приведены рекомендации по глубине декомпозиции бизнес-процесса.
В настоящее время существует большое число методологий моделирования предметных (проблемных) областей.
Некоторые из них получили статус официального стандарта, другие являются стандартом де-факто.
Во многом эти стандарты базируются на одних и тех же абстрактных категориях, но реализуются на основе различных подходов: функционально-ориентированного (структурного), объектно-ориентированного и комплексного.
В этом разделе дан краткий анализ подходов (сильные и слабые стороны подходов) и рекомендации по их применению.
Анализ показал, что ни одна из методологий в полной мере не удовлетворяет требованиям комплексного реинжиниринга бизнес-процессов, принадлежащих к различным классам и проектирования информационных систем. Подробное описание всех методологий выходит за рамки настоящего учебного пособия. В то же время разработчику – дипломнику необходимо иметь наиболее полное представление о технологии процесса разработки автоматизированной информационной системы на основе стандартов.
Поэтому в четвертом разделе
пособия приведена технология канонического проектирования.
Технология канонического проектирования отражает особенности ручной технологии индивидуального (оригинального) проектирования на уровне исполнителей без использования инструментальных средств, которые позволяют интегрировать выполнение некоторых операций. Причем все требования стандарта разработки автоматизированной информационной системы (АИС) рассматриваются в рамках жизненного цикла проекта и стадий канонического проектирования (см. таблицу В-1).
Подробно описан состав и содержание работ в виде технологической сети проектирования по этапам перечисленных выше стадий с указанием, а в некоторых случаях и с описанием методик проведения соответствующих работ.
Пятый раздел
посвящён структурному (функциональному) подходу к проектированию АИС. Здесь рассмотрены наиболее распространенные формализованные методы структурного анализа и проектирования: моделирование потоков данных и моделирование данных (подход «сущность – связь»).
Диаграммы потоков данных (
DFD), диаграммы «сущность – связь» (
ERD), дополненные диаграммами, отражающими архитектуру программного обеспечения, структурными схемами программ, диаграммами экранных форм – в совокупности дают полное описание информационной системы и ее программного обеспечения.
Описан компонентный состав диаграмм потоков данных в нотации Гейна - Сэрсона (внешние сущности; системы и подсистемы; процессы; накопители данных; потоки данных).
Рассмотрены вопросы построения иерархии диаграмм потоков данных, чтобы сделать требования к системе ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определёнными отношениями между ними.
Таблица В-1. Соответствие фаз проекта и стадий канонического проектирования и стандарта проектирования АИС.
| Фазы проекта. |
Стадии канонического проектирования. |
Стадии создания АИС по стандарту. |
| Фаза концепции проекта. |
Предпроектная стадия |
1.Исследование и обоснование создания системы. 2.Разработка технического задания. 3.Создание эскизного проекта. |
| Фаза разработки. |
Стадия проектирования. |
4.Техническое проектирование. 5.Рабочее проектирование. |
| Фаза реализации. |
Стадия внедрения. |
6.Ввод в действие. |
| Фаза завершения. |
Стадия эксплуатации и сопровождения. |
7.Функционирование. Сопровождение. Модернизация. |
Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Для проверки контекстной диаграммы нужно составить список событий. Список событий должен состоять из описаний действий внешних сущностей (событий) и соответствующих реакций системы на события. Для сложных ИС строится иерархия контекстных диаграмм. Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры ИС на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем. Конечной вершиной иерархии является спецификация. Спецификация процесса (описание логики, алгоритм функционирования) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу. Помимо диаграмм потоков DFD используются и другие диаграммы, отражающие системную архитектуру программного обеспечения (ПО), иерархию экранных форм и меню, структурные схемы программ и т.д. Состав диаграмм и степень их детализации определяются необходимой полнотой описания системы для непосредственного перехода к ее последующей реализации (программированию).
Далее приводится пример, который демонстрирует использование структурного подхода. Приведено описание предметной области и технология выполнения проекта.
Анализ функционального аспекта
поведения системы завершается построением полной контекстной диаграммы
, и представляет диаграмму нулевого уровня.
Результатами проектирования архитектуры являются:
─ модель процессов (диаграмма архитектуры системы- System Architecture Diagram- SAD и спецификации на структурированном языке);
─ модель данных (ERD и подсхемы ERD);
─ модель пользовательского интерфейса (классификация процессов на интерактивные и неинтерактивные функции, диаграмма последовательности форм (Form Sequence Diagram- FSD), показывающая, какие формы появляются в приложении, и в каком порядке).
Результатами детального проектирования являются:
─ модель процессов (структурные схемы интерактивных и не интерактивных функций);
─ модель данных (определение в ERD всех необходимых параметров для приложений);
─ модель пользовательского интерфейса (диаграмма последовательности форм (FSD), показывающая, какие формы появляются в приложении, и в каком порядке, взаимосвязь между каждой формой и определенной структурной схемой, между каждой формой и одной или более сущностью в (ERD)).
На этапе реализации строится реализационная модель. Процесс ее создания включает в себя:
─ генерацию предложений на структурированном языке запросов (SQL-предложений), определяющих структуру целевой БД (таблицы, индексы, ограничения целостности данных - ограничения непротиворечивости данных).
─ уточнение структурных схем программ (SCD) и диаграмм последовательности форм (FSD) с последующей генерацией кода приложений.
На основе анализа потоков данных и взаимодействия процессов с хранилищами данных осуществляется окончательное выделение подсистем.
| |
ОГЛАВЛЕНИЕ
1. Понятие и жизненный цикл проекта.
2. Управление проектом.
2.1. Понятие и проблемные области управления проектом.
2.2. Основные компоненты процесса управления проектами
2.2.1. Процессы инициализации.
2.2.2. Процессы планирования.
2.2.3. Процессы исполнения и контроля.
2.2.4. Процессы анализа.
2.2.5. Процессы оперативного управления.
2.2.6. Процессы завершения.
3. Обоснование выбора методологии моделирования бизнес – процессов.
3.1. Проблемная область и требования к ее модели.
3.2. Матрица согласованных моделей в архитектурах.
3.3. Процессный подход.
3.4. Методологии моделирования проблемных областей.
4. Требования стандартов и технология создания автоматизированных информационных систем.
4.1. Состав стадий и этапов канонического проектирования АИС.
4.2. Состав и содержание работ на предпроектной стадии создания АИС.
4.2.1. Сбор материалов обследования.
4.2.2. Анализ материалов обследования.
4.2.3. Составление ТЭО и формирование ТЗ.
4.3. Состав и содержание работ на стадии «Техно - рабочего проектирования».
4.3.1. Техническое проектирование.
4.3.2. Рабочее проектирование.
4.4. Состав и содержание работ на стадиях внедрения, эксплуатации и сопровождения проекта.
5. Структурный подход к проектированию информационных систем.
5.1. Моделирование потоков данных (процессов).
5.1.1. Общие сведения
5.1.2. Состав диаграмм потоков данных.
5.1.3. Построение иерархии диаграмм потоков данных.
5.1.4. Функциональные модели, используемые на стадии проектирования.
5.2. Пример использования структурного подхода в нотации CASE-средства Vantage Team Builder.
5.2.1. Описание предметной области.
5.2.2. Жизненный цикл и технология выполнения проекта.
Библиографический список.
1. Понятие и жизненный цикл проекта.
Методология управления процессом проектирования и реализацией разработки при выполнении дипломных работ включает в себя целый комплекс методов и является в общем методологией управления проектами.
Дипломная работа является некоторым упрощением понятия проект, поэтому в дальнейшем изложении для общности будем там, где это необходимо использовать понятие «проект».
Проект - это уникальный процесс, который состоит из совокупности скоординированной и управляемой деятельности (с начальной и конечной датами), предпринятой для достижения цели. Эта деятельность соответствует конкретным требованиям, и включает ограничения по срокам, стоимости и ресурсам.
Проекты разделяются по сферам деятельности на следующие виды:
─ технический проект (строительство здания или сооружения, внедрение новой производственной линии, разработка программного обеспечения и т. д.);
─ организационный проект (реформирование существующего или создание нового предприятия, внедрение новой системы управления, проведение международной конференции и т. д.);
─ экономический проект (приватизация предприятия, внедрение системы финансового планирования и бюджетирования, введение новой системы налогообложения и т. д.);
─ социальный проект (реформирование системы социального обеспечения, социальная защита необеспеченных слоев населения, преодоление последствий природных и социальных потрясений);
─ смешанный проект (проекты, реализуемые сразу в нескольких областях деятельности, к примеру, проект реформирования предприятия, включающий внедрение системы финансового планирования и бюджетирования, разработку и внедрение специального программного обеспечения и т. д.).
Жизненный цикл проекта.
Типичный жизненный цикл проекта состоит из четырех фаз:
─ фаза концепции;
─ фаза разработки;
─ фаза реализации;
─ фаза завершения.
Фаза концепции.
Результатом этой фазы является утверждение концепции проекта. Процесс разработки концепции включает в себя следующий перечень действий:
─ сбор исходных данных и анализ существующего состояния (предварительное обследование);
─ выявление потребности в изменениях (в проекте);
─ определение собственно проекта;
─ цели, задачи, результаты;
─ основные требования, ограничительные условия, критерии;
─ уровень риска;
─ окружение проекта, потенциальных участников;
─ требуемое время, ресурсы, средства и др.
─ определение и сравнительную оценку альтернатив;
─ представление предложений, их апробацию и экспертизу;
─ утверждение концепции и получение одобрения для следующей фазы.
Фаза разработки
.
На фазе разработки выявляются основные компоненты проекта, и осуществляется подготовка к его реализации. Основные работы этой фазы:
─ назначение руководителя проекта и формирование команды проекта,
─ в первую очередь, выбор ключевых членов команды;
─ установление деловых контактов и изучение целей, мотивации и требований заказчика и владельца проекта, других ключевых участников;
─ развитие концепции и разработка основного содержания проекта, в том числе конечный результаты и продукты, стандарты качества, структура проекта, основные работы, требуемые ресурсы;
─ структурное планирование, в том числе декомпозиция проекта;
─ календарные планы и укрупненные графики работ и обеспечения;
─ смета и бюджет проекта;
─ потребность в ресурсах;
─ процедуры управления проектом и техника контроля;
─ определение и распределение рисков;
─ организация и проведение торгов, заключение субконтрактов с основными исполнителями;
─ организация выполнения базовых проектных и опытно-конструкторских работ по проекту;
─ представление проектной разработки;
─ получение одобрения на продолжение работ по проекту.
Фаза реализации
.
На фазе реализации выполняются основные работы, необходимые для достижения целей проекта. Данная фаза включает в себя:
─ организацию и проведение торгов, заключение контрактов;
─ полный ввод в действие разработанной системы управления проектом;
─ организацию выполнения работ;
─ ввод в действие средств и способов коммуникации и связи участников проекта;
─ ввод в действие системы стимулирования (участников) проекта;
─ детальное проектирование и технические спецификации;
─ оперативное планирование работ;
─ установление системы информационного контроля ходом работ;
─ организацию и управление материально-техническим обеспечением, в том числе запасами, покупками, поставками;
─ выполнение операций, предусмотренных проектом (в том числе строительно-монтажных и пусконаладочных);
─ руководство, координацию работ, согласование темпов, мониторинг процесса, прогноз состояния, оперативный контроль и регулирование основных показателей проекта;
─ ход работ, их темпы;
─ качество работ и проекта;
─ продолжительность и сроки;
─ стоимость и другие показатели;
─ решение возникающих проблем и задач.
Фаза завершения
.
На завершающей фазе, или при окончании проекта, достигаются конечные цели проекта, подводятся итоги, разрешаются конфликты и проводится закрытие проекта. Основные работы этой фазы:
─ планирование процесса завершения;
─ эксплуатационные испытания окончательного продуктов проекта;
─ подготовка кадров для эксплуатации создаваемого объекта;
─ подготовка документации, сдача объекта заказчику и ввод в эксплуатацию;
─ оценка результатов проекта и подведение итогов;
─ подготовка итоговых документов;
─ закрытие работ и проекта;
─ разрешение конфликтных ситуаций;
─ реализация оставшихся ресурсов;
─ накопление фактических и опытных данных для последующих проектов;
─ расформирование команды проекта.
Цель завершающих операций при выполнении проекта заключается в том, чтобы повысить эффективность или отдачу от капиталовложений в следующий проект, внося на основе как позитивного, так и негативного опыта выполненного проекта изменения в структуру организации, схему финансирования и поставок, или посредством разработки более эффективного стиля управления.
В заключение следует отметить, что для большинства проектов в отношении их жизненного цикла верны следующие утверждения:
─ финансовые и трудовые затраты сравнительно невелики на начальной стадии проекта, резко возрастают на фазе выполнения и плавно понижаются по мере приближения к завершению проекта;
─ проектные риски максимальны в момент начала проекта и уменьшаются по мере его продвижения. Соответственно вероятность успешного завершения проекта минимальна в начальный момент и растет по мере того, как выполняются отдельные работы, и снижается влияние различных факторов риска;
─ возможность влияния ключевых участников проекта на окончательные характеристики результатов проекта, сроки и фактические затраты максимальны на начальных стадиях проекта и уменьшаются по мере его выполнения.
2. Управление проектом
.
2.1. Понятие и проблемные области управления проектом.
Управление проектом (УП), или Project Management (PM), - это искусство руководства и координации людских и материальных ресурсов на протяжении жизненного цикла проекта путем применения современных методов и техники управления для достижения определенных в проекте результатов по составу и объему работ, стоимости, времени, качеству и удовлетворению участников проекта.
Сущность методологии УП состоит в сосредоточении прав и ответственности за достижение целей проекта у одного человека или небольшой группы. Этот человек - менеджер проекта - обеспечивает реализацию проекта, выполняя ключевые функции по управлению проектом.
Для успешного управления проектом необходимо постоянно находить баланс между часто взаимно противоречивыми характеристиками:
─ содержание проекта, время, затраты и качество;
─ требования к проекту и ожидания от него у разных групп участников;
─ несоответствие результатов и ожиданий проекта.
Всю дисциплину управления проектом можно разделить на более или менее самостоятельные блоки (рис.2.1).
Управление интеграцией проекта описывает мероприятия, необходимые для того, чтобы различные составляющие проекта координировались должным образом.
Управление содержанием проекта описывает действия, необходимые для четкого определения, что именно должно быть сделано в ходе выполнения проекта, а что выходит за его рамки.
Рис.2.1. Проблемные области проекта.
Управление сроками проекта описывает действия, необходимые для завершения проекта в срок.
Управление затратами проекта описывает действия, гарантирующие, что
проект будет выполнен в рамках утвержденного бюджета.
Управление качеством выполнения проекта описывает действия, необходимые для гарантии того, что результат проекта будет удовлетворять требованиям, ради которых он был предпринят.
Управление людскими и прочими ресурсами описывает действия, обеспечивающие оптимальное использование людских и прочих ресурсов, вовлеченных в проект.
Управление взаимодействием в проекте описывает действия, обеспечивающие своевременные и полные генерацию, сбор, распространение и хранение информации о проекте, а также ее использование для принятия управленческих решений.
Управление рисками проекта описывает действия по идентификации и анализу проектных рисков, а также методы реагирования на них.
Управление закупками описывает действия по управлению процессом получения необходимых для проекта товаров и услуг со стороны внешних по отношению к проекту организаций и лиц.
2.2. Основные компоненты процесса управления проектами
Процессы как последовательности действий, направленных на достижение какого-либо определенного результата, подразделяют на две основные категории:
─ процессы управления проектом, которые включают в себя описание и организацию работ над проектом,
─ предметно- ориентированные процессы, включающие в себя описание и создание конечного продукта, ради которого предпринимается проект.
Процессы второй категории определяются жизненным циклом проекта и варьируются в зависимости от предметной области.
В качестве объекта управления выступает проект, разбитый по фазам. Для каждой фазы выполняются группы процессов управления (рис. 2.2.).
Управление проектированием в функциональном аспекте представляет совокупность взаимосвязанных процессов.
Под процессом управления подразумеваются действия и процедуры, связанные с решением конкретных задач или реализацией функций управления, к которым относятся:
─ процессы инициализации связанные с принятием решения о начале выполнения проекта или какого-либо очередного этапа, фазы;
─ процессы планирования - совокупность процедур связанная с определением целей и разработкой рабочих схем их достижения;
─ процессы организации исполнения, предназначенные для координации людей и других ресурсов для выполнения плана;
─ процессы анализа, дающие возможность определить соответствие плана и исполнения проекта поставленным целям и критериям и принять решения о необходимости применения корректирующих воздействий;
─ процессы оперативного управления - совокупность процедур, предназначенных для определения необходимых корректирующих воздействий, их согласования, утверждения и применения;
─ процессы завершения - процессы формализации выполнения проекта и составление отчётности.
На всех стадиях проекта процессы управления могут накладываться друг на друга и осуществляться с различными интенсивностями. Кроме того, процессы управления проектами связаны между собой своими результатами. Результат выполнения одного становится исходной информацией для другого. В реальном проекте этапы проекта могут не только предшествовать друг другу, но и накладываться.
Рис.2.2. Процессы управления фазами проекта.
Внутри каждой группы процессы управления проектами связаны друг с другом через свои выходы и входы:
─ Входы
- документы или документированные показатели, согласно которым процесс исполняется.
─ Выходы
- документы или документированные показатели, являющиеся результатом процесса.
─ Методы и средства (инструменты)
- механизмы, по которым вход преобразуется в выход.
Кратко представим состав и содержание выделенных групп процессов управления.
2.2.1. Процессы инициализации.
Процесс инициализации включает единственный процесс, побуждающий начало деятельности над проектом или его отдельной фазой.
2.2.2. Процессы планирования.
Планирование имеет большое значение для проекта и включает набор процессов. Некоторые процессы планирования имеют чёткие логические и информационные связи и выполняются в одном порядке практически во всех проектах. К примеру, вначале определяется состав работ проекта, а затем рассчитываются сроки выполнения и стоимость проекта. Эти основные процессы выполняются по несколько раз на протяжении каждой фазы проекта.
К основным процессам планирования проектных работ относятся:
─ планирование целей - разработка письменного описания постановки задачи (проектное обоснование, основные этапы и цели проекта);
─ декомпозиция целей - разделение этапов проекта на более мелкие и более управляемые компоненты для обеспечения более действенного контроля;
─ определение состава операций (работ) проекта - составление перечня операций, из которых состоит выполнение различных этапов проекта;
─ определение взаимосвязей операций - составление и документирование технологических взаимосвязей следования/предшествования между операциями;
─ оценка длительностей или объемов работ - оценка количества рабочих временных интервалов либо объемов работ, необходимых для завершения отдельных операций;
─ определение ресурсов (людей, оборудования, материалов) проекта.
─ назначение ресурсов - распределение ресурсов, необходимых для выполнения отдельных операций проекта;
─ оценка стоимости - определение составляющих стоимости операций проекта и оценка этих составляющих для каждой операции, ресурса;
─ составление расписания выполнения работ - определение последовательности выполнения работ проекта, длительностей операций и распределения во времени потребностей в ресурсах и затрат с учётом наложенных ограничений и взаимосвязей;
─ оценка бюджета – получение оценок стоимости по отдельным компонентам проекта (этапам, фазам, срокам);
─ разработка плана исполнения проекта - интеграция результатов остальных подпроцессов для составления полного документа;
─ определение критериев успеха - разработка критериев оценки исполнения проекта.
Кроме перечисленных основных процессов планирования выделяют ряд вспомогательных процессов, использование которых сильно зависит от природы конкретного проекта.
К таким процессам относятся:
─ планирование качества - определение того, какие стандарты качества использовать в проекте, и того, как этих стандартов достичь;
─ планирование организации - определение, документирование и назначение ролей, ответственности и взаимоотношений отчётности в организации;
─ подбор и назначение персонала - назначение человеческих ресурсов на выполнение работ проекта;
─ планирование взаимодействия - определение потоков информации и способов взаимодействия, необходимых для участников проекта;
─ идентификация риска - определение и документирование событий риска, которые могут повлиять на проект;
─ оценка риска - оценка вероятностей наступления событий риска, их характеристик и влияния на проект;
─ разработка методов реагирования - определение необходимых действий для предупреждения рисков и реакции на угрожающие события;
─ планирование поставок - определение того, что, как и когда должно быть поставлено.
Взаимосвязи между вспомогательными подпроцессами, как и само их наличие, зависят от природы проекта.
2.2.3.
Процессы исполнения и контроля.
Исполнение проекта (реализация плана) должно регулярно измеряться и анализироваться для того, чтобы выявить отклонения от намеченного плана и оценить их влияние на проект. Регулярное измерение параметров проекта и идентификация возникающих отклонений далее также относится к процессам исполнения и именуется контролем исполнения. Контроль исполнения проводится по всем параметрам, входящим в план проекта.
Процессы исполнения, как и в планировании, подразделяются на основные и вспомогательные процессы исполнения. К основным процессам исполнения относятся процессы, входящие в план проекта.
К вспомогательным процессам можно отнести следующие процессы:
─ учёт исполнения – подготовку и распределение необходимой для участников проекта информации с требуемой периодичностью;
─ подтверждение качества - регулярную оценку исполнения проекта с целью подтверждения соответствия принятым стандартам качества;
─ подготовку предложений - сбор рекомендаций, отзывов, предложений, заявок и т.д.;
─ выбор поставщиков – оценку предложений, выбор поставщиков и подрядчиков и заключение контрактов;
─ контроль контрактов - контроль исполнения контрактов поставщиками и подрядчиками;
─ развитие команды проекта.
2.2.4.
Процессы анализа.
Процессы анализа включают анализ плана и анализ исполнения проекта.
Анализ плана осуществляется с целью определения того, удовлетворяет составленный план предъявляемым к проекту требованиям и ожиданиям участников проекта или нет. Он выражается в оценке показателей плана всеми участниками проекта.
На стадии планирования результатом анализа плана может быть принятие решения о необходимости изменения начальных условий и составления новой версии плана либо принятие разработанной версии в качестве базового плана проекта, который служит основой для исполнения. В дальнейшем под процессами анализа понимаются процессы анализа исполнения.
Процессы анализа исполнения предназначены для оценки состояния и прогноза успешности исполнения проекта согласно критериям и ограничениям, определённым на стадии планирования.
Для большинства проектов в число основных ограничений и критериев успеха входят цели, сроки, качество и стоимость работ проекта. При отрицательном прогнозе принимается решение о необходимости корректирующих воздействий, выбор которых осуществляется в процессах управления изменениями.
Процессы анализа можно также разделить на основные и вспомогательные процессы.
Основными являются те процессы анализа, которые непосредственно связаны с целями проекта и показателями, характеризующими успешность исполнения проекта:
─ анализ сроков - определение соответствия фактических и прогнозируемых планом сроков исполнения операций проекта (директивных);
─ анализ стоимости - определение соответствия фактической и прогнозной стоимости операций и фаз проекта (директивных);
─ анализ качества - мониторинг результатов с целью их проверки на соответствие принятым стандартам качества и определение причин, которые привели к нежелательным результатам исполнения качества проекта;
─ подтверждение целей - процесс формальной приёмки результатов проекта его участниками (инвесторами, потребителями и т.д.).
Вспомогательные процессы анализа связаны с анализом факторов, влияющих на цели и критерии успеха проекта. Эти процессы включают:
─ оценку исполнения - анализ результатов работы и распределение проектной информации с целью снабжения участников проекта данными о том, как используются ресурсы для достижения целей проекта;
─ анализ ресурсов - определение соответствия фактической и прогнозной загрузки и производительности ресурсов запланированным, а также анализ соответствия фактического расхода материалов, машинного времени и т.д. плановым значениям.
В результате анализа либо принимается решение о продолжении исполнения проекта по намеченному ранее плану либо определяется необходимость применения корректирующих воздействий.
2.2.5.
Процессы оперативного управления.
Управление исполнением проекта - это определение и применение необходимых управляющих воздействий с целью успешной реализации проекта.
Если исполнение проекта происходит в соответствии с намеченным планом, то управление сводится к исполнению - доведению до участников проекта плановых заданий и контролю над их реализацией. Эти процессы включаются в процессы исполнения.
Если же в процессе реализации возникли отклонения, анализ которых показал, что необходимо определение и применение корректирующих воздействий, то требуется:
─ найти оптимальные корректирующие воздействия;
─ скорректировать план оставшихся работ;
─ согласовать намеченные изменения со всеми участниками проекта.
Процессы оперативного управления предназначены для определения, согласования и внесения необходимых изменений в план проекта. Их часто называют управлением изменениями и инициируются процессами анализа.
К основным процессам оперативного управления относятся:
─ общее управление изменениями - определение, согласование, утверждение и принятие решений к исполнению корректирующих воздействий и координация изменений по всему проекту;
─ управление ресурсами - внесение изменений в состав и назначение ресурсов на работы проекта;
─ управление целями - корректировка целей проекта по результатам процессов анализа;
─ управление качеством - разработка мероприятий по устранению причин неудовлетворительного исполнения.
Среди вспомогательных процессов управления выделяют:
─ управление рисками - реагирование на события и изменение рисков в процессе исполнения проекта;
─ управление контрактами - координация работы субподрядчиков, корректировка контрактов, разрешение конфликтов.
2.2.6.
Процессы завершения.
Проект завершается следующими процессами:
─ закрытием контрактов - завершением и закрытием контрактов, включая разрешение всех возникших споров;
─ административным завершением - подготовкой, сбором и распределением информации, необходимой для формального завершения проекта.
При реализации всех описанных выше процессов управления, образующих контур управления, используются определённые методы и средства.
Следует иметь в виду, что эти группы процессов не являются дискретными, фиксированными во времени событиями. Они представляют собой перекрывающиеся во времени работы события, которые имеют место с той или иной степенью интенсивности на каждой фазе проекта.
3. Обоснование выбора методологии моделирования бизнес – процессов.
3.1. Проблемная область и требования к ее модели.
Под проблемной областью понимается взаимосвязанная совокупность управляемых объектов предприятия (предметная область), субъектов управления, функций управления и программно-технических средств их реализации.
Для того чтобы получить адекватный проблемной области проект системы, необходимо иметь целостное, системное представление модели, которое отражает все аспекты функционирования предприятия. При этом под моделью понимается некоторая система, отображающая структуру или функционирование исследуемой проблемной области.
Проведение предварительного моделирования проблемной области позволяет сократить время и сроки выполнения проектировочных работ и получить более эффективный и качественный проект. Без проведения моделирования проблемной области велика вероятность получения некачественного проекта, в котором может быть допущено большое количество ошибок в решении стратегических вопросов, приводящих к экономическим потерям и высоким затратам на последующее перепроектирование системы. Вследствие этого все современные технологии проектирования систем основываются на использовании методологии моделирования проблемной области. Модели дают возможность оценить достоинства и недостатки существующей системы и построить эффективную архитектуру новой системы.
К моделям проблемных областей предъявляются следующие требования:
─ формализованность, которая должна обеспечить однозначное описание структуры проблемной области (для описания моделей используются нотации различных формальных языков моделирования);
─ понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;
─ реализуемость, подразумевающая наличие средств физической реализации модели проблемной области, в частности программных средств для создания информационной системы;
─ обеспечение оценки эффективности при реализации модели проблемной области на основе определенных методов и вычисляемых показателей.
Для реализации перечисленных требований, как правило, строится система моделей, которая отражает структурный и оценочный аспекты функционирования проблемной области.
Для представления структурного аспекта моделей проблемных областей в основном используются графические методы, которые должны в наглядной форме представлять информацию о компонентах системы и их взаимодействии. Главный критерий адекватности структурной модели проблемной области заключается в функциональной полноте разрабатываемой системы.
Оценочные аспекты моделирования проблемной области связаны с разрабатываемыми показателями эффективности системы, к которым относятся:
─ время выполнения процессов;
─ стоимостные затраты;
─ надежность процессов;
─ косвенные показатели эффективности, такие как объемы производства, производительность труда, оборачиваемость капитала, рентабельность т.д.
Для расчета показателей эффективности системы, реализующей модель проблемной области, используются статические методы стоимостного анализа процессов и динамические методы имитационного моделирования.
Набор средств моделирования проблемной области в настоящее время поддерживается с помощью CASE (Computer Aided Software Engineering) – средств или средств моделирования компонентных технологий.
Обычно модели строятся на трех уровнях: предпроектного анализа, технического (логического) и рабочего (физического) проектирования. На уровне предпроектного анализа (определения требований) модель отображает состав основных компонентов системы и характер их взаимодействия. На уровне технического проектирования (определения спецификаций) модель отвечает на вопрос, с помощью каких средств должны быть выражены построенные на предыдущем уровне компоненты: программных модулей, баз данных, интерфейсов. На уровне рабочего проектирования (реализации) модель устанавливает привязку программно-технической среды для реализации специфицированных компонентов.
3.2. Матрица согласованных моделей в архитектурах.
Рассматриваемый и конструируемый объект – это не только программы, данные и коммуникации. Сюда входят и люди, выступающие как заказчики, пользователи, аналитики, конструкторы и разработчики системы; организационные структуры; графики работы предприятия, а также, конечно, цели и стимулы предприятия и т.д. Все эти сущности должны быть соединены в единую систему понятным и непротиворечивым образом. Поэтому даже вопросов «простого» согласования компонентов системы достаточно для того, чтобы прилагать специальные усилия на уровне формирования архитектуры.
Идея такого согласования состоит в том, что его надо начинать с самых главных характеристик предприятия, рассматривая важнейшие содержательные аспекты. В идеальном случае согласование начинают с конструирования системы управления предприятием, а именно с создания сбалансированной системы целей и планов. В эту сбалансированную систему целей и планов входят: миссия предприятия, стратегические цели, индикаторы достижения целей и их целевые значения; мероприятия по достижению целей, включая архитектуру информационной системы и информационно-технологическую платформу, а также обновленные бизнес – процессы и оргструктуры; система мотивации работников и планы их профессионального обучения и т.д. Согласование проводят на явно изложенных описаниях всех сторон предприятия, которые позволяют видеть все существенные взаимосвязи, т.е. на его моделях.
Заметим, что привычные нотации формальных моделей (функционально-ориентированных и объектно-ориентированных) подчас слишком рано ведут к неоправданно низкому уровню моделирования.
Модели предметной (проблемной) области рассматривают с позиции категорий участников процесса проектирования систем, к которым относятся пользователи (заказчики), проектировщики (консультанты), участвующие в процессе получения и формирования знаний о проблемной области и формулирующие требования к информационной системе; разработчики и эксплуатационщики информационной системы (ИС). Проектировщики совместно с заказчиками должны формировать модели проблемной области, отражающие содержательную сторону функционирования системы, при этом проектировщики закладывают технологические требования к реализации системы, скрытые от взгляда пользователей. На основе моделей требований разработчики ИС проводят технологическую детализацию проекта и его последующую реализацию. На основе сформированной рабочей документации и полученного конечного продукта системы пользователи - эксплуатационщики осуществляют поддержку функционирования системы в новых условиях. Данный подход нашел воплощение в архитектурах предложенных Д.А. Захманом [7]. В соответствии с этим подходом совокупность моделей определяет одну из архитектур системы (раздел обеспечения системы). В процессе осуществления проекта каждая точка зрения проходит определенное развитие в соответствии с выполняемым этапом проектирования.
Схема (матрица) согласованных архитектур служит простым, но достаточно мощным инструментом по применению системного подхода для планирования работ по созданию и использованию автоматизированных систем, информационных систем и стыковки этих работ.
3.2.1. Основные аспекты построения архитектур
Архитектуры представляют систему с позиции одних и тех же аспектов, но под разными углами зрения. В качестве основных аспектов построения архитектур предлагается рассматривать следующие аспекты:
─ цели, бизнес-правила (мотивация того, почему функционирует система);
─ участники процесса (кто осуществляет процесс);
─ функции (как осуществляется преобразование в системе);
─ объекты – данные (что проходит процесс преобразования);
─ место (где осуществляется процесс);
─ время (графики событий, временные требования к выполнению процесса).
Виды моделей и их отображение в различных архитектурах показаны в таблице
3.1.
Столбцы таблицы фактически отражают разделы обеспечения системы: информационное обеспечение (данные), функциональное обеспечение (функции), коммуникационное обеспечение (сеть), организационное обеспечение и т.д.
Строки таблицы отражают уровни представления системы, к ним относятся уровни моделирования, уровни решения проектных задач. Более детально это следующие представления:
· бизнес среда системы,
· концептуальная модель,
· логическая модель,
· технологическая, «физическая модель»,
· детальная реализация (часто поблочная),
· представление пользователя (эксплуатация).
Таблица 3.1. Матрица согласованных моделей в архитектурах.
| Виды моделей и их реализация
|
Цели (почему?)
Дерево целей
|
Люди
(кто?)
Архитек-тура орган-изации
|
Функции
(как?)
Архитек-тура прило-жений
|
Объекты--данные (что?)
Архитек-
тура
данных
|
Коммуникации (где?)
Архитек-
тура
техноло-гическая
|
Время
(когда?)
|
|
| 1 |
Укрупненная модель организации (планировщик, пользователь) |
Список целей и задач |
Список организа-ций (подразде-лений) |
Список процессов |
Список сущностей |
Список узлов |
Список основных событий |
| 2 |
Корпоративная модель организации (пользователь) |
Стратеги-ческая модель: цель – стратегия. |
Структур-ные модели: подразде-ления – работа |
Функци-ональные модели: процесс – ресурс. |
e="text-align:center;">Информаци-онно-логические модели:
ER-диаг-раммы |
Модель топологии узлов |
Модель корпора-тивных событий |
| 3 |
Системная модель ИС (консультант-проекти-ровщик) |
Критерии достиже-ния целей |
Роли персонала |
Диаграм-мы потоков данных |
Логическая модель данных |
Логическая модель сетей организации |
Модель системных событий |
| 4 |
Технологическая модель (разработчик ИС) |
Модель «состояние-действие» |
Модель интер-фейса |
Модель приложе- ний |
Модель внутреннего представ- ления |
Физическая модель комму-никаций |
Модель технических событий |
| 5 |
Компоненты (разработчик ИС, субподрядчик) |
Шаг/задача |
Пользо-ватель – транзакция |
Програм- мные модули |
Базы данных |
Протоколы |
Компонент-ные события |
| 6 |
Функциони-рующая система (эксплуата-ционщики) |
Варианты исполнения |
Сеансы работы |
Проце- дуры |
Ограниче- ния целост- ности |
Клиент – сервер |
Операцион-ные события |
Описанные разделы и уровни схемы Захмана являются классификацией сущностей предприятия и его информационной системы.
3.2.2. Участники проекта.
Организация работ по проектированию определяется порядком взаимодействия между всеми сторонами-участниками. Так при проектировании информационной системы (ИС) участниками процесса являются: инициатор проекта, пользователи, заказчики и разработчики.
Инициатором проекта
может быть, в принципе, любой из будущих участников проекта. Инициатор проекта выдвигает главную идею, предварительное обоснование и предложения по реализации проекта. Однако, в конечном счёте, деловая инициатива принадлежит заказчику. Так как он может финансировать проект, осуществлять конкурсный отбор альтернативных предложений по проектам и т.п.
Пользователь
-
это административно-управленческий аппарат, для которого создаётся эта система.
Заказчик
- это ответственное лицо (организация, подразделение), которое выполняет функции:
─ формулирует требования к системе и её частям;
─ выдает (утверждает) техническое задание;
─ финансирует разработку информационной системы;
─ обеспечивает проведение комплекса мероприятий по её созданию;
─ проводит приём проекта ИС и внедрение.
Разработчик
– это ответственное лицо (организация, подразделение), которое выполняет следующие функции:
─ разрабатывает ИС по техническому заданию заказчика;
─ принимает участие во внедрении;
─ осуществляет сдачу проекта заказчику;
─ осуществляет авторское сопровождение проекта.
С одной стороны, заказчик несёт ответственность перед пользователем за соответствие состава и характеристик решаемых задач, режима функционирования ИС исходным данным пользователя, за сроки создания системы, за правильность использования ресурсов в процессе проектирования.
С другой стороны, заказчик отслеживает, контролирует - осуществляет мониторинг:
─ правильности реализации требований технического задания на ИС;
─ научно - технического уровня разработок;
─ сроков проведения работ;
─ качества проектной документации;
─ правильности расхода денежных ресурсов - выполняемых разработчиком.
Таким образом, представляются отдельные роли участников процесса проектирования.
В реальных условиях некоторые участники процесса проектирования могут выполнять несколько ролей. Мы уже отмечали, что, в конечном счете, инициатором проекта является заказчик. Заказчик, кроме того, может еще выступать и в роли пользователя. Информация необходимая для мониторинга черпается из системы управления проектами.
В двух первых строках матрицы согласованных архитектур (см. таблицу 3.1.) показаны модели, относящиеся к точке зрения будущих пользователей системы, третья строка соответствует точке зрения консультанта – проектировщика, четвертая и пятая строки – точке зрения разработчика информационной системы, шестая строка соответствует точке зрения эксплуатационных служб пользователя.
Дипломник
при выполнении квалификационной работы по информационным системам должен уметь выполнять несколько ролей, соответствующих работам, расположенным со 2-й по 6-ю строки матрицы согласованных моделей. Однако объем работ должен быть ограничен, конечно, в рамках локальной подсистемы (отдельной задачи).
Этот подход не определяет собственно методы построения моделей проблемной области, однако методологии моделирования проблемных областей предполагают реализацию принципов последовательной детализации
абстрактных категорий: целей, объектов, функций, организационных единиц, и т.д. на уровнях определения требований к системе, их спецификации и реализации.
3.3. Процессный подход.
Основой разработки методологии для обоснования конфигурации предприятия является применение процессного подхода
, который нацелен на управление сквозными цепочками выполняемых функций, как единым целым.
При процессном подходе акценты смещаются с управления отдельными ресурсами и центрами затрат предприятия на управление бизнес-процессами, связывающими воедино деятельность взаимодействующих подразделений предприятия.
Концепция управления бизнес-процессами в различной степени реализована в следующих подходах: MRP (Manufacturing Resource Planning) – планирование ресурсов производства; TQM (Total Quality Management) - всеобщее управление качеством; BPR (Business Process Reengineering) – реинжиниринг бизнес-процессов.
Под бизнес-процессом будем понимать всю совокупность взаимосвязанных функций (действий, операций, работ), выполняемых для удовлетворения потребностей клиентов в продукции и услугах различными подразделениями предприятия и управляемых организационно из одного процессного подразделения.
В качестве клиентов могут выступать как внешние потребители товаров и услуг, так и внутренние подразделения предприятия. При этом в ходе управления бизнес-процессами все материальные, финансовые и информационные потоки рассматриваются неразрывно и во взаимодействии.
Система управления бизнес – процессом предприятия включает действия по преобразованию входов в выходы, систему сбора информации о показателях процесса, систему анализа полученной информации и принятия управленческих решений лицом, ответственным за эффективность процесса, систему непрерывного улучшения показателей процесса и корректирующих действий по устранению причин отклонений в ходе бизнес-процесса. Как и любая система управления, система процессного управления предприятием состоит из компонентов: «Процесс» - объект управления, «Владелец процесса» - субъект управления рис.3.3.
Рис.3.3. Концептуальная схема управления процессом.
Владелец процесса
– это должностное лицо, наделённое правами и полномочиями, а также ресурсами, необходимыми для выполнения процесса, и несущее ответственность за результат процесса.
Ресурс
– это материальный или информационный объект, постоянно используемый для выполнения бизнес – процесса, но не являющийся его входом. К ресурсам относят информацию, персонал, оборудование, программное обеспечение, инфраструктуру, транспорт, связь и др.
Ресурсы находятся под управлением владельца, и их объём планируется на большое количество циклов, т.е. на длительный период работы.
Выход бизнес – процесса
всегда имеет потребителя. Причём в качестве потребителя может выступать другой бизнес – процесс. В этом случае, выход одного бизнес – процесса является входом бизнес – процесса потребителя. Кроме того, выход (продукт) бизнес – процесса может использоваться также в качестве ресурса для выполнения другого бизнес-процесса.
Примерами выходов бизнес – процессов являются такие объекты как: готовая продукция, документация, информация (в частности отчётная), услуги и т.п.
Таким образом, выход (продукт) – материальный или информационный объект или услуга, являющийся результатом выполнения бизнес – процесса и потребляемый внешними по отношению к процессу клиентами.
Вход бизнес–процесса
– продукт, который при выполнении бизнес – процесса преобразуется в выход и должен иметь своего поставщика. К входам бизнес – процесса могут относиться такие составляющие как сырьё и материалы, полуфабрикаты и комплектующие изделия, документация и информация, персонал (в системе «Кадры»), услуги и т.п.
Выходы, входы и ресурсы – являются материальными объектами.
Бизнес – процесс не может существовать вне организации. Руководство организации должно определить назначение бизнес – процесса, поставить цели и утвердить плановые значения показателей эффективности процесса. Владелец процесса в свою очередь принимает решения на основании поступившей информации и установленных планов.
На рис.4.1 представлена схема бизнес-процесса учитывающая взаимосвязь материальных потоков и информационных потоков, в том числе и управленческих взаимодействий.
Если рассматривать деятельность предприятия или организации в целом, то для описания используются укрупненные процессы. Примером процесса верхнего уровня может быть процесс закупок сырья и материалов для производства, который включает такие функции, как: планирование закупок, заключение договоров, оформление заказов, получение товарно-материальных ценностей (ТМЦ), оплату ТМЦ, отпуск ТМЦ в производство. Число уровней декомпозиции процессов определяется задачами проекта, и не должно быть слишком большим - более 7 уровней. При определении бизнес – процессов, существующих на предприятии, целесообразно начинать описание с верхнего уровня. Одним из важнейших вопросов, возникающих при моделировании бизнес – процессов, является определение необходимой глубины описания. При проведении декомпозиции моделей количество объектов на диаграмме растет в геометрической прогрессии. Важно изначально определить практически целесообразную степень детализации описания.
Верхний уровень описания бизнес – процессов соответствует процессам, которыми управляют заместители генерального директора. Второй уровень процессов, как правило, рассматривается на уровне крупных функциональных подразделений предприятия. Третий уровень – уровень функций подразделений и отделов. Четвертый уровень – функции, выполняемые на рабочих местах, и т.д.
3.4. Методологии моделирования проблемных (предметных) областей.
В настоящее время существует большое число методологий моделирования проблемных (предметных)
областей, некоторые из которых получили статус официального стандарта, например IDEF (Integrated Definitions), UML (Unified Modeling Language) [3, 6, 8, 9, 10, 11, 13, 14], а другие являются стандартами де-факто, например ARIS (Architecture of Integrated Information Systems) [12, ,13, 14]. Во многом перечисленные стандарты отражают одни и те же абстрактные категории, но делают это на основе различных подходов: структурного (функционально-ориентированного), объектно–ориентированного и комплексного.
В функционально- ориентированных моделях (Data Flow Diagram - DFD-диаграммах потоков данных, Structured Analysis and Design Technique - SADT-диаграммах) главными структурными компонентами являются функции (действия, операции, работы, бизнес-процессы), которые на диаграммах представляются вершинами графа и связываются дугами, которые представляют потоки объектов рис.3.4.
Рис. 3.4. Фрагмент диаграммы потоков данных.
Достоинством функциональных моделей является реализация структурного подхода к проектированию системы по принципу «сверху-вниз», когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д., осуществляя тем самым модульное проектирование системы. Для функциональных моделей характерны процедурная строгость декомпозиции и наглядность представления. Поэтому такие модели в основном используются при реорганизации и автоматизации бизнес – процессов и на начальных этапах проектирования. В функциональном подходе объектные модели данных в виде ER–диаграмм «объект-свойство-связь» разрабатываются отдельно после исследования потоков данных. Для проверки корректности моделирования проблемной области между функциональными и объектными моделями устанавливаются взаимнооднозначные связи.
Основной недостаток функциональных моделей связан с отображением разветвлений в процессах обработки информации. При большом числе разветвлений модель становится плохо понимаемой и управляемой. Кроме того, возможна повторяемость использования одинаковых функций в разных бизнес-процессах, а, следовательно, и программных модулей. В последнем случае одни и те же функции в различных иерархиях могут быть либо спроектированы несколько раз, либо общее определение может содержать не все необходимые детали.
Перечисленные недостатки функциональных моделей снимаются в объектно-ориентированных моделях, в которых главным структурообразующим элементом выступает класс объектов с набором функций. Функции могут обращаться к атрибутам этого класса (скрытие данных). Для классов объектов характерна иерархия обобщения, позволяющая осуществить наследование не только атрибутов (свойств) объектов от вышестоящего класса объектов к нижестоящему классу, но и функций (методов).
В случае наследования функций можно абстрагироваться от конкретных реализаций процедур (абстрактные типы данных), которые отличаются для определенных подклассов ситуаций. Это дает возможность обращаться к подобным программным модулям по общим именам (полиморфизм) и осуществлять повторное использование программного кода при модификации программного обеспечения. Таким образом, адаптивность объектно-ориентированных систем к изменению проблемной области по сравнению с функциональным подходом значительно выше.
В объектно-ориентированном подходе изменяется и принцип проектирования системы. Сначала выделяются классы объектов, а затем в зависимости от возможных состояний его объектов определяются методы обработки (функциональные процедуры), что обеспечивает лучшую реализацию динамического поведения информационной системы (рис. 3.5).
Для объектно-ориентированного подхода разработаны графические методы моделирования проблемной области, обобщенные в языке моделирования Unified Modeling Language – UML. Однако с точки зрения наглядности представления модели пользователю – заказчику объектно-ориентированные модели явно уступают функционально – ориентированным моделям и поэтому наиболее эффективны в применении на стадии разработки программной реализации системы.
Отображаемые в моделях проблемной области бизнес – процессы предприятия имеют неодинаковый характер. Так, можно выделить относительно рутинные бизнес-процессы, которые выполняются на строго регламентированной основе, например процессы складского и бухгалтерского учета, оформления приема на работу и т.д. С другой стороны, существуют бизнес-процессы с высокой динамикой принятия решений по ходу выполнения бизнес-процесса, например управление закупками или продажами. Кроме того, могут иметь место бизнес-процессы, выполняемые в условиях неопределенности внешней среды и требующие применения неструктурированного знания, например процессы маркетинга, инжиниринга, бизнес – планирования.
Рис.3.5. Фрагмент диаграммы взаимодействия объектов.
Для каждого из перечисленных видов бизнес – процессов могут потребоваться свои стандарты моделирования проблемной области. Так, например, функционально-ориентированные методологии в большей степени используются для формализации рутинных бизнес-процессов, в то время как объектно-ориентированные методологии - для формализации динамических бизнес-процессов. Кроме того, на различных этапах проектирования систем также могут применяться разные методологии.
Комплексный характер реинжиниринга бизнес–процессов, затрагивающий все виды бизнес–процессов и приводящий к созданию корпоративной ИС, обусловливает необходимость интеграции различных методологий моделирования бизнес–процессов и возможности отображения представлений моделей в соответствующих стандартах. Проведенный анализ методологий структурного моделирования проблемной области показал, что ни одна из методологий в полной мере не удовлетворяет требованиям комплексного реинжиниринга бизнес–процессов, принадлежащих к различным классам.
На инструментальном уровне эта задача частично решена в технологии ARIS (Architecture of Integrated Information Systems) [12, 17], в которой поддерживается общий репозиторий однотипных объектов различных методологий.
Сложность отображения моделей проблемной области, представленных в различных стандартах, обусловлена сильной привязкой в существующих подходах содержания модели к формализму. В разрабатываемых в последнее время системах управления знаниями акцент делается как раз не на форму, а на суть отображаемых явлений или концептуализацию знаний о проблемной области в онтологиях [15, 16, 17]. В связи с этим разработка подхода к моделированию проблемной области на основе метаонтологий, в которой стандартизуется метамодель мира, т.е. такие понятия, как объект, функция, событие, ресурс и их взаимодействие, представляется основой для решения поставленной задачи интеграции применения различных методологий в моделировании проблемной области.
Вопросы для самопроверки
1. Дайте определения понятиям «проект», «управление проектом».
2. По каким признакам классифицируются проекты.
3. Перечислите этапы жизненного цикла проекта.
4. Перечислите проблемные области управления проектами.
5. Каких участников проекта вы знаете?
6. Охарактеризуйте функции участников проекта.
7. Дайте определение понятию «Проблемная область».
8. Перечислите требования, предъявляемые к модели проблемной области.
9. Перечислите основные аспекты (столбцы) при построении матрицы согласованных архитектур.
10. Что представляют собой строки матрицы согласованных архитектур?
11. Какова суть процессного подхода?
12. Перечислите основные компоненты, входящие в описание концептуальной модели бизнес-процесса.
13. В чем состоит сущность функционально-ориентированного подхода при построении моделей проблемных областей?
14. В чем состоит сущность объектно-ориентированного подхода при построении моделей проблемных областей?
15. При каких условиях применяются функционально-ориентированные и объектно-ориентированные модели.
4. Требования стандартов и технология
создания автоматизированных информационных систем.
Создание А
втоматизированных И
нформационных С
истем (АИС) регламентируется «Комплексом стандартов и руководящих документов на автоматизированные системы» (ГОСТ 34.201-89, ГОСТ 34.602-89, РД 50-682, РД 50-680-88, ГОСТ 34.601-90, ГОСТ 34.401-90, РД 50-34.698-90, ГОСТ 34.003-90, РД 50-34.119-90).
4.1.
Состав стадий и этапов
канонического
проектирования АИС.
Каноническое проектирование АИС
отражает особенности ручной технологии индивидуального (оригинального) проектирования, осуществляемого на уровне исполнителей без использования каких-либо инструментальных средств, позволяющих интегрировать выполнение элементарных операций. Как правило, каноническое проектирование применяется для небольших локальных АИС или их частей. В основе канонического проектирования лежит каскадная модель жизненного цикла АИС. Процесс каскадного проектирования в жизненном цикле АИС в соответствии с применяемым стандартом в нашей стране - ГОСТ 34601-90 «Автоматизированные системы. Стадии создания» делится на следующие семь стадий рис.4.1.
В целях изучения взаимосвязанных приемов и методов канонического проектирования АИС перечисленные семь стадий можно сгруппировать в часто используемые на практике четыре фазы проекта и представить в виде технологической сети проектирования (ТСП) процесса разработки АИС (рис. 4.2).
Д 1.1 – предметная область; Д 1.2 – материалы обследования; Д 1.3 – ТЭО, ТЗ на проектирование; Д 1.4 – эскизный проект; Д 2.1 – Техно-рабочий проект (ТРП); Д3.1 – исправленный ТРП, переданный в эксплуатацию; Д 3.2 – акт о приемке проекта в промышленную эксплуатацию; Д 4.1 – модернизированный ТРП.
Рис. 4.2. Технологическая сеть проектирования (ТСП) АИС.
По своей сути эти четыре фазы совпадают с жизненным циклом проекта, который был описан в разделе 1 и разнятся в основном терминологически.
Фаза «Концепция проекта» по сути, здесь «Предпроектная стадия».
Фаза разработки соответствует стадии проектирования.
Фаза реализации соответствует стадии внедрения и т.д. (см. таблицу 4.1).
Таблица 4.1. Соответствие фаз проекта, стадий канонического проектирования и стандарта.
| Фазы проекта.
|
Стадии канонического проектирования.
|
Стадии создания АИС
по стандарту.
|
| Фаза концепции проекта. |
Предпроектная стадия |
1.Исследование и обоснование создания системы. 2.Разработка технического задания. 3.Создание эскизного проекта. |
| Фаза разработки. |
Стадия проектирования. |
4.Техническое проектирование. 5.Рабочее проектирование. |
| Фаза реализации. |
Стадия внедрения. |
6.Ввод в действие. |
| Фаза завершения. |
Стадия эксплуатации и сопровождения. |
7.Функционирование. Сопровождение. Модернизация. |
Традиционно этапы исследования предметной области – предприятия, обоснование проекта АИС для него и разработки технического задания объединяют термином «Предпроектная стадия» («Предпроектное обследование»), поскольку результаты выполнения работ на данных этапах не являются законченным проектным решением. Основное назначение «Предпроектной стадии» заключается в обосновании экономической целесообразности создания АИС и формулировании требований к ней.
На первой «Предпроектной стадии
» принято выделять два основных этапа:
1. сбор материалов обследования;
2. анализ материалов обследования и разработка технико-экономического обоснования (ТЭО) и технического задания (ТЗ).
В результате выполнения первого этапа проектировщики получают материалы обследования (Д 1.2), которые должны содержать полную и достоверную информацию, описывающую изучаемую предметную область – предприятие, в том числе: цель функционирования; организационную структуру системы и объекта управления, т.е. его управленческие отделы, цехи, склады и хозяйственные службы; функции управления, выполняемые в этих подразделениях, протекающие в них технологические процессы обработки управленческой и экономической информации, а также материальные потоки и процессы их обработки, ресурсные ограничения.
После выполнения второго этапа проектировщики получают количественные и качественные характеристики информационных потоков, описание их структуры и мест обработки, объемов выполняемых операций и трудоемкости их обработки. На основе этих материалов разрабатываются два документа:
1).«Технико-экономическое обоснование проектных решений» (ТЭО), содержащее расчеты и обоснование необходимости разработки АИС для предприятия, а также выбираемых технологических и проектных решений (Д 1.3);
2).«Техническое задание» (ТЗ), в состав которого входят требования к создаваемой системе и ее отдельным компонентам: программному, техническому и информационному обеспечению и целевая установка на проектирование новой системы (Д 1.4).
Эти документы являются основными для последующего проектирования АИС в соответствии с заданными требованиями.
Для сложных АИС иногда на этой стадии включают третий этап – разработку «Эскизного проекта». На этапе «Эскизного проекта» сформулированные ранее требования служат основой для разработки предварительных решений по АИС в целом и отдельным видам обеспечения. Эти решения прорабатываются на логическом уровне, включая алгоритмы обработки информации, описание информационных потребностей пользователей на уровне названий документов и показателей.
Вторая стадия «Техно - рабочее проектирование»
выполняется в два этапа: техническое проектирование и рабочее проектирование.
На этапе «Техническое проектирование» выполняются работы по логической разработке и выбору наилучших вариантов проектных решений, в результате чего создается «Технический проект». Этап «Рабочее проектирование» связан с физической реализацией выбранного варианта проекта и получением документации «Рабочего проекта». При наличии опыта проектирования эти этапы иногда объединяются в один, в результате выполнения которого получают «Техно - рабочий проект» (ТРП) – Д 2.1.
Третья стадия «Внедрение проекта»
включает в себя три этапа: подготовка объекта к внедрению проекта; опытное внедрение проекта и сдача его в промышленную эксплуатацию.
На этапе «Подготовка объекта к внедрению проекта»
осуществляется комплекс работ по подготовке предприятия к внедрению разработанного проекта АИС. На этапе «Опытное внедре
ние»
осуществляют проверку правильности работы некоторых частей проекта и получают исправленную проектную документацию и «Акт о проведении опытного внедрения». На этапе «Сда
ча проекта в промышленную эксплуатацию»
осуществляют комплексную системную проверку всех частей проекта, в результате которой получают доработанный «Техно - рабочий проект» (Д 3.1) и «Акт приемки проекта в промышленную эксплуатацию» (Д 3.2).
Четвертая стадия – «Эксплуатация и сопровождение проекта»
включает этапы: эксплуатация проекта; сопровождение и модернизация проекта.
На этапе «Эксплуатация проекта»
получают информацию о работе всей системы в целом и отдельных ее компонентов и собирают статистику о сбоях системы в виде рекламаций и замечаний, которые накапливаются для выполнения следующего этапа. На этапе «Сопровождение проекта»
выполняются два вида работ: ликвидируются последствия сбоев в работе системы и исправляются ошибки, не выявленные при внедрении проекта, а также осуществляется модернизация проекта.
В процессе модернизации проект либо дорабатывается, т.е. расширяется по составу подсистем и задач, либо производится перенос системы на другую программную или техническую платформу с целью адаптации ее к изменяющимся внешним и внутренним условиям функционирования, в результате чего получают документы модернизированного «Техно - рабочего проекта» (Д 4.1).
4.2.
Состав и содержание работ на предпроектной стадии создания АИС.
При анализе существующей системы (организации, предприятия) разработчики должны уточнить границы изучения системы, определить круг пользователей будущей АИС различных уровней и выделить классы и типы объектов, подлежащих обследованию и последующей автоматизации.
Важнейшими объектами обследования могут являться:
· структурно-организационные звенья предприятия (например, отделы управления, цехи, участки, рабочие места);
· функциональная структура, состав хозяйственных процессов и процедур;
· стадии (техническая подготовка, снабжение, производство, сбыт);
· элементы хозяйственного процесса (средства труда, предметы труда, ресурсы, продукция, финансы).
При каноническом проектировании основной единицей обработки данных является задача. Поэтому функциональная структура проблемной области на стадии предпроектного обследования изучается в разрезе решаемых задач и комплексов задач. При этом задача в содержательном аспекте рассматривается как совокупность операций преобразования некоторого набора исходных данных для получения результатной информации, необходимой для выполнения функции управления или принятия управленческого решения. В большинстве случаев исходные данные и результаты их преобразований представляются в форме экономических документов. Поэтому к числу объектов обследования относятся компоненты потоков информации (документы, показатели, файлы, сообщения). Кроме того, объектами обследования служат: технологии, методы и технические средства преобразования информации; материальные потоки и процессы их обработки.
4.2.1. Сбор материалов обследования.
Основной целью выполнения первого этапа предпроектного обследования «Сбор материалов» является:
─ выявление основных параметров предметной области (например, организации, предприятия или его части);
─ установление условий, в которых будет функционировать проект АИС;
─ выявление стоимостных и временных ограничений на процесс проектирования.
На этом этапе проектировщиками выполняется ряд технологических операций, и решаются следующие задачи: предварительное изучение предметной области; выбор технологии проектирования; выбор метода проведения обследования; выбор метода сбора материалов обследования; разработка программы обследования; разработка плана-графика сбора материалов обследования; сбор и формализация материалов обследования. Технологическая сеть проектирования представлена на рис. 4.3.
Выполнение операции «Предварительное изучение предметной области»
(П. 1) имеет своей целью на основе общих сведений об объекте (Д 1.1) выявить предварительные размеры объемов работ по проектированию и состав стоимостных и временных ограничений на процессы проектирования, а также найти примеры разработок проектов АИС для аналогичных систем (Д 1.2).
Важной операцией, определяющей все последующие работы по обследованию объекта и проектированию АИС, является «Выбор технологии проектирования»
(П.2). В настоящее время в универсум (U 2.1) входит несколько типов технологий проектирования: технология оригинального, типового, автоматизированного и смешанного вариантов проектирования.
Для технологии оригинального проектирования характерно создание уникального проектного решения для экономической системы. При этом могут создаваться не только индивидуальные специальные проекты, но и соответствующие методики проведения проектных работ. Поэтому технологию оригинального проектирования используют в том случае, если хотят, чтобы получаемый в результате проектирования индивидуальный специальный проект в полной мере отображал все особенности соответствующего объекта управления при невысокой стоимости разработки, понятности и доступности получаемого решения заказчику.
Д 1.1 – общие сведения об объекте; Д 1.2 – примеры разработок проектов ЭИС для аналогичных систем; U 2.1 – универсум технологий проектирования; Д 2.1 – ресурсы; Д 2.2 – описание выбранной технологии, методов и средств проектирования; U 3.1 – универсум методов проведения обследования; Д 3.1 – описание выбранного метода; U 4.1 – универсум методов сбора материалов обследования; Д 4.1 – описание выбранного метода; Д 5.1 – программа обследования; Д 6.1 – план-график выполнения работ на предпроектной стадии; U 7.1 – универсум методов формализации; Д 7.1 – общие параметры (характеристики) экономической системы; Д 7.2 – методы и методики управления (алгоритм расчета экономических показателей); Д 7.3 – организационная структура экономической системы; Д 7.4 – параметры информационных потоков; Д 7.5 – параметры материальных потоков.
Рис 4.3. ТСП работ, выполняемых на этапе «Сбор материалов обследования».
К числу ограничений по использованию оригинального проектирования можно отнести низкую степень автоматизации проектных работ, длительные сроки разработки, низкое качество документирования, отсутствие преемственности в проектных решениях.
Основными ограничениями при выборе технологии из некоторого универсума технологий (U2.1) могут служить: наличие денежных средств на приобретение и поддержку выбранной технологии, ограничения по времени проектирования, доступность соответствующих инструментальных средств и возможность обеспечения поддержки их эксплуатации собственными силами, наличие специалистов соответствующей квалификации (Д 2.1). Результатом выполнения этой операции служит получение описания выбранной технологии, методов и инструментов проектирования (Д 2.2). Перед началом работ по проведению обследования необходимо выбрать метод проведения обследования (П. З). Все методы (U 3.1) можно объединить в группы по следующим признакам (рис. 4.4):
─ по цели обследования выделяют метод организации локального проведения обследования, используемый для разработки проекта отдельной задачи или для комплекса задач, и метод системного обследования объекта, применяемый для изучения всего объекта с целью разработки для него проекта АИС в целом;
─ по числу исполнителей, проводящих обследование, применяется индивидуальное обследование, осуществляемое одним проектировщиком, и бригадное с выделением ряда бригад исполнителей, изучающих все подразделения предприятия, и одной координирующей бригады;
─ по степени охвата предметной области применяют метод сплошного обследования, охватывающего все подразделения экономической системы, и выборочное, применяемое при наличии типовых по структуре подразделений (например, цехов или складов);
─ по степени одновременности выполнения работ первого и второго этапов предпроектной стадии. Выделяют метод последовательного проведения работ, при котором проектировщики сначала собирают данные о предметной области, а затем их изучают и метод параллельного выполнения работ, когда одновременно со сбором осуществляют изучение полученных материалов обследования, что значительно сокращает время на проведение работ.
Рис. 4.4. Схема классификации методов проведения обследования.
Выполнение работ по обследованию предметной области в каком-либо подразделении и сбору материалов можно проводить на основе предварительного проведения выбора методов для сбора материалов обследования (П.4), универсум которых (U4.1) можно разделить на две группы (рис. 4.5):
─ методы сбора, выполняемого силами проектировщиков-исполнителей, включающие методы проведения бесед и опросов, анализа материалов обследования, личных наблюдений, фотографии рабочего дня и хронометража рабочего времени специалиста при выполнении им той или иной работы;
─ методы сбора, выполняемого силами специалистов предметной области, которым предлагается либо заполнять тетрадь-дневник на выполняемые ими работы, либо провести документную инвентаризацию рабочего места, либо использовать метод самофотографии рабочего дня, позволяющий выявить состав операций и получаемые при этом документы.
Метод бесед и консультаций с руководителями
чаще всего проводится в форме обычной беседы с руководителями предприятий и подразделений или в форме деловой консультации со специалистами по вопросам, носящим глобальный характер и относящимся к определению проблем и стратегий развития и управления предприятием.
Рис. 4.5. Схема классификации методов для сбора материалов обследования.
Метод опроса исполнителей на рабочих местах
используется в процессе сбора сведений непосредственно у специалистов путем бесед, которые требуют тщательной подготовки. Заранее составляют список сотрудников, с которыми
намереваются беседовать, разрабатывают перечень вопросов о роли и назначении работ в деятельности объекта, порядке их выполнения.
Метод анализа операций
заключается в расчленении рассматриваемого делового процесса, работы на ее составные части, задачи, расчеты, операции и даже их элементы. После этого анализируется каждая часть в отдельности, выявляются повторяемость отдельных операций, многократное обращение к одной и той же операции, их степень зависимости друг от друга.
Meтoд анализа предоставленного материала
применим в основном при выяснении таких вопросов, на которые нельзя получить ответ от исполнителей.
Метод фотографии рабочего дня исполнителя работ
предполагает непосредственное участие проектировщиков и применение рассчитанного для регистрации данных наблюдения специального листа фотографий рабочего дня и распределения его между работами.
Метод выборочного хронометража отдельных работ
требует предварительной подготовки, известных навыков и наличия специального секундомера. Данные хронометража позволяют установить нормативы на выполнение отдельных операций и собрать подробный материал о технике осуществления некоторых работ.
Метод личного наблюдения
применим, если изучаемый вопрос понятен по существу и необходимо лишь уточнение деталей без существенного отрыва исполнителей от работы.
Метод документальной инвентаризации управленческих работ
заключается в том, что на каждую работу в отдельности открывается специальная карта обследования, в которой приводятся все основные данные о регистрируемой работе или составляемых документах.
Метод ведения индивидуальных тетрадей-дневников
. Записи в дневнике производятся исполнителем в течение месяца ежедневно, сразу же после выполнения очередной работы.
Метод фотографии рабочего дня
исполнителя работ заключается в том, что наблюдение носит более детальный характер и происходит в короткий срок. Этот метод дает сведения о наиболее трудоемких или типичных отдельных работах, которые используются для определения общей трудоемкости выполнения всех работ.
Расчетный метод
применяемся для определения трудоемкости и стоимости работ, подлежащих переводу на выполнение с помощью ЭВМ, а также для установления объемов работ по отдельным операциям.
Метод аналогии
основан на отказе от детального обследования какого-либо подразделения или какой-либо работы. Использование метода требует наличия тождественности и не исключает общего обследования и выяснения таких аспектов, на которые аналогия не распространяется.
При выборе метода следует учитывать следующие критерии:
─ степень личного участия проектировщика в сборе материала;
─ временные, трудовые и стоимостные затраты на получение сведений в подразделениях.
Проектировщику необходимо знать и в каждом конкретном случае применять наиболее экономичный, обеспечивающий нужную полноту сведений метод сбора материалов обследования.
Обследование проводится по заранее разработанной программе (Д 5.1), составляемой во время выполнения операции П. 5, по форме, представленной в таблице 4.2. Эта форма содержит перечень вопросов, ответы на которые дадут полное представление о деятельности изучаемого объекта и должны быть учтены при создании проекта АИС. Вопросы можно систематизировать по трем основным направлениям исследования объекта.
Первое направление
предусматривает получение представления об объекте изучения, т.е. экономической системе (например, предприятии) в целом, включая выяснение целей функционирования этой системы
, выявление значений основных параметров деятельности предприятия и т. д.
Второе направление
предусматривает изучение и описание организационно-функциональной структуры
объекта (как правило, относится к аппарату управления). При этом изучаются функции, выполняемые в структурных подразделениях, хозяйственные процессы и процедуры, выявляются комплексы задач, обусловленные выполняемыми функциями, процессами и процедурами, определяется состав входной и выходной информации по каждой задаче. В таблице 4.2 приведен фрагмент составления программы.
Таблица 4.2. Программа обследования.
| № п/п |
Наименование вопроса |
Источник информации |
Получатель информации |
| 1 |
Цель функциониро- вания объекта |
Руководитель предприятия |
Руководитель проекта |
| 2 |
Основные параметры объекта |
Руководитель предприятия |
Руководитель проекта |
| 3 |
Организационная структура объекта |
Секретарь руководителя |
Зам. Руководитель пректа |
| ……..
|
Третье направление
предусматривает изучение и описание структуры информационных и (или) материальных потоков
: состава и структуры компонентов потоков, частоты их возникновения, объемов за определенный период, направления движения потоков, процедур обработки, в которых участвуют эти компоненты. Источником сведений являются получаемые от специалистов предметной области интервью, экономическая документация и результаты расчетов. Описание информационной структуры выполняется на уровне экономических документов и показателей.
Для организации труда проектировщиков во время выполнения сбора материалов обследования и его последующего анализа необходимо выполнение операции П. 6 - разработка «Плана-графика выполнения работ на предпроектной стадии» (Д 6.1), фрагмент которого представлен в таблице 4.3.
«План-график» служит инструментом для планирования и оперативного управления выполнением работ на предпроектной стадии.
Последней операцией (П. 7), выполняемой проектировщиками на этом этапе, является «Проведение сбора и формализации материалов обследования».
В процессе выполнения этой операции члены бригад должны проинтервьюировать, специалистов подразделений изучаемой предметной области. Собрать сведения обо всех объектах обследования, в том числе о предприятии в целом, функциях управления, методах и алгоритмах реализации функций, составе обрабатываемых и рассчитываемых показателей. Собрать формы документов, отражающих хозяйственные процессы и используемые классификаторы, макеты файлов, сведения об используемых технических средствах и технологиях обработки данных. Проконтролировать вместе с пользователем их правильность, сформировать «Отчет об обследовании» и выполнить другие работы.
Таблица 4.3. План-график выполнения работ на стадии сбора материалов.
| № п/п |
Наименование работы |
Код работы |
Исполни-тель |
Дата начала |
Длитель-ность |
Дата оконча-ния |
| 1 |
Определение целей и параметров предприятия |
001 |
Руководи-тель проекта Серов М.Р. |
01.03.99 |
2 |
02.03.99 |
| 2 |
Определение организационной структуры предприятия |
002 |
Заместитель руководителя проекта Иванов И.П. |
03.03.99 |
1 |
03.03.99 |
| ….
|
Сбор материалов обследования следует проводить с помощью стандартных форм и таблиц, которые удобно читать и обрабатывать (рис. 4.6).
Вся получаемая документация разбивается на три группы. В первую группу входят документы, содержащие описание общих параметров экономической системы (Д 7.1), ее организационной структуры, матричной модели распределения функций реализуемых каждым структурным подразделением. В частности, общие параметры должны содержать:
─ наименование объекта и его принадлежность (например, принадлежность предприятия министерству, объединению, корпорации и т.п.);
─ тип объекта (например, тип предприятия, вид производства, режимы работы);
─ виды и номенклатуру продукции или услуг; виды и количество оборудования и материальных ресурсов;
─ категории и численность работающих сотрудников и т.д.
В эту группу входит также форма описания общих характеристик функций управления экономической системой, хозяйственных процессов и процедур, реализующих эти функции (Д 7.2). Эта форма включает отражение следующих параметров: наименование каждой функции, процесса и процедуры, описание экономической сущности задач, решаемых при выполнении процедуры, связанной с обработкой информации; состав процедур обработки информации, реализуемых каждой задачей; взаимосвязь задач, стоимостные затраты, связанные с реализацией каждой задачи.
Описание организационной структуры (Д 7.3) должно включать состав и взаимосвязь подразделений и лиц, реализующих функции и задачи управления. Описание производственной структуры объекта должно отражать состав и взаимосвязь подразделений, реализующих производство товаров или услуг. Описание функциональной структуры призвано отображать распределение функций, хозяйственных процессов и процедур управления между составляющими организационной структуры и должно предполагать проведение классификации процедур, связанных с обработкой данных, коммуникацией между сотрудниками или принятием управленческих решений.
Описание материальных потоков (Д 7.5) предполагает отображение маршрутов движения средств, предметов и продуктов труда, рабочей силы между подразделениями производственной структуры и будет включать: описание видов продукции или услуг, ресурсов; описание технологических операций, их частоту и длительность выполнения; объемы перемещаемых ресурсов, продукции или услуг, используемые средства транспортировки.
Далее следует вторая группа форм, формализующих материалы обследования по каждому структурному подразделению, имеющая в своем составе, помимо форм, аналогичных тем, которые входят в первую группу, формы описания информационных потоков по подразделениям (Д 7.4), которые осуществляют связь задач внутри каждого подразделения между собой, а также связи между подразделениями.
Форма описания документопотоков включает следующие характеристики: наименование входных документов, количество их экземпляров; объемные данные по каждому документопотоку; перечень информационных файлов, где используются эти документы; носитель, на котором хранятся данные; время создания; время использования; перечень полей файлов; выходные документы, получаемые на основе информации файлов.
Третья группа документов содержит описание компонентов каждого информационного потока, включая документы, информационные файлы, процедуры обработки и характеристики этих компонентов.
Формы характеристик документов включают: наименование подразделения, тип документа (первичный, промежуточный или результатный), назначение документа, наименование документа, периодичность создания или время использования. Форма описания документов содержит: перечень показателей; описание структуры документов; перечень реквизитов; распределение реквизитов по разделам документа; типы реквизитов.
Форма характеристик процедур обработки данных включает: наименование подразделения, где используется процедура, задачу, в которую входит данная процедура; входную информацию, ее объемы; используемые файлы и их объемы; частоту обращения процедуры к файлу; блок-схему процедуры; выходные данные процедуры. Форма описания процедур обработки содержит: наименование задачи; операции процедуры; количество операций; используемую технику; стоимостные и временные затраты.
Полученное в результате проведенной формализации описание объекта содержит исходные данные для проектирования АИС и определяет параметры будущей системы. Так, материальные потоки обусловливают объемы обрабатываемой информации, состав первичных данных, периодичность и сроки сбора, их источники, необходимые для разработки информационной базы. Функциональная структура объекта определяет комплексы автоматизируемых задач управления, для каждого из которых указывают: состав входных и выходных показателей; периодичность и сроки их формирования; процедуры использования данных показателей; распределение функций и процедур между персоналом и техническими средствами. Организационная структура объекта служит основанием для выделения лиц, определяющих условие решения задач обработки информации, а также получателей выходных показателей и документов.
4.2.2. Анализ материалов обследования.
На основе формализованного описания предметной области выполняется этап «Анализ материалов обследования»,
целью которого являются:
─ сопоставление всей собранной об объекте информации с теми требованиями, которые предъявляются к объекту, определение недостатков функционирования объекта обследования;
─ выработка основных направлений по совершенствованию работы объекта обследования на базе внедрения проекта АИС, выбор направлений проектирования (выбор инструментария) и оценка эффективности применения выбранного инструментария;
─ обоснование выбора решений по основным компонентам проекта АИС и определение общесистемных, функциональных и локальных требований к будущему проекту и его частям.
Рассмотрим технологическую сеть анализа материалов обследования (рис. 4.7.), в которой в каждой из технологических операций используются документы обследования (Д 1.1 – Д 1.5).
Анализ материалов обследования позволяет проектировщикам выделить и
составить список автоматизируемых подразделений
(П. 1). На выбор объектов автоматизации оказывает влияние ряд факторов (U 1.1), например, таких, как:
─ количество формализуемых функций в каждом конкретном подразделении;
─ количество связей этого подразделения с другими подразделениями;
─ важность этого подразделения в процессах управления объектом;
─ степень подготовленности подразделения для внедрения ЭВМ и др.
Согласно этим факторам выделяют список наиболее важных подразделений (Д 1.6). Например, для предприятия такими подразделениями являются отделы технико-экономического планирования, оперативного управления основным производством, технической подготовки производства, материально-технического снабжения, реализации и сбыта готовой продукции, бухгалтерия.
На операции П. 2 при выявлении списка автоматизируемых задач
(Д 2.1), для которых необходимо разработать проекты, проектировщики принимают к сведению следующие факторы, представленные универсумом (U 2.1):
─ важность решения задачи для выполнения основных функций управления, деловых процессов и процедур в данном подразделении;
─ трудоемкость и стоимость расчета основных показателей данной задачи за год;
─ сильная информационная связь рассматриваемой задачи с другими задачами;
─ недостаточная оперативность расчета показателей;
─ низкая достоверность получаемых данных;
─ недостаточное количество аналитических показателей,- получаемых на базе первичных документов;
─ неэквивалентный метод расчета показателей и др.
Кроме того, на этой операции осуществляется выявление очередей проектирования решаемых задач. К задачам первой очереди относят самые трудоемкие задачи и задачи, обеспечивающие информацией все остальные задачи комплексов и подсистем (например, задачи планирования и бухгалтерского учета). Общим требованием к первоочередным задачам является получение нормативного коэффициента окупаемости капитальных затрат.
Далее выполняется операция, связанная с анализом всех полученных ранее результатов, исходных универсумов и предвари
тельным выбором комплекса
технических средств
(Д3.1) на операции ПЗ. На выбор типа ЭВМ из универсума U3.1 оказывает влияние большое число факторов, которые принято объединять в следующие группы (U 3.2):
1. Факторы, связанные с параметрами входных информационных потоков, поступающих на обработку ЭВМ: объем информации, тип носителя информации, характер представления информации.
2. Факторы, зависящие от характера задач, которые должны решаться на ЭВМ, и их алгоритмов: срочность решения, возможность разделения задачи на подзадачи, выполняемые на другой ЭВМ, количество файлов с условно-постоянной информацией.
3. Факторы, определяемые техническими характеристиками ЭВМ: производительность процессора, емкость оперативной памяти, поддерживаемая операционная система, возможность подключения различных устройств используемых для ввода-вывода.
Д 1.1 - общие параметры (характеристики) экономической системы; Д 1.2 - методы и методики управления (алгоритм расчета экономических показателей); Д 1.3 - организационная структура экономической системы; Д 1.4 - параметры информационных потоков; Д 1.5 – параметры материальных потоков; U 1.1 - универсум факторов выбора; Д 1.6 - обоснование и список объектов автоматизации; U 2.1 -
универсум факторов выбора задач; Д 2.1 - обоснование списка задач по каждому подразделению (объекту автоматизации); U 3.1 - универсум технических средств; U 3.2 - факторы отбора КТС; Д 3.1 - обоснование выбора КТС; U 4.1 - универсум операционных систем; U 4.2 - факторы выбора ОС; Д 4.1 - обоснование выбора ОС и алгоязыков; U 5.1 - универсум способов организации ИБ; U 5.2 - универсум программных средств ведения ИБ; U 5.3 - факторы выбора; Д 5.1 - обоснование выбора и описание организации ИБ и программного средства; U 6.1 - универсум методов и программных средств разработки; Д 6.1 - обоснование выбора метода проектирования и инструментального средства; Д 7.1 - ТЭО; Д 7.2 – ТЗ.
Рис. 4.7. Технологическая сеть «Анализ материалов обследования».
4. Факторы, относящиеся к эксплуатационным характеристикам ЭВМ: требуемые условия эксплуатации, необходимый штат обслуживающего персонала и его квалификация.
5. Факторы, учитывающие стоимостные оценки затрат на приобретение, на содержание обслуживающего персонала, на проведение ремонтных работ.
Далее следует выполнение операции П. 4 - «Выбор типа опера
ционных
систем»
(Д 4.1). Операционные системы осуществляют управление работой ПЭВМ, ее ресурсами, запускают на выполнение различные прикладные программы, выполняют всевозможные вспомогательные действия по запросу пользователя. Различают однопользовательские, многопользовательские и сетевые
OC (U 4.1).
К факторам, определяющим выбор конкретного класса ОС (U 4.2) и его версии, относятся:
─ необходимое число поддерживаемых программных продуктов;
─ требования к аппаратным средствам;
─ возможность использования различных устройств ввода - вывода;
─ требование поддержки сетевой технологии;
─ наличие справочной службы для пользователя;
─ наличие дружественного интерфейса и простота использования;
─ возможность переконфигурации и быстрой настройки на новые аппаратные средства;
─ быстродействие;
─ совместимость с другими ОС;
─ • поддержка новых информационных технологий и др.
Следующей операцией (П5) является операция «Выбор спосо
ба организации информационной базы (ИБ) и программного средства ведения ИБ»
(Д5.1). Информационная база имеет несколько способов организации (U5.1) как совокупность локальных файлов и интегрированную организацию в виде баз данных. Локальная (файловая) организация подразумевает под собой хранение данных в виде совокупности локальных файлов, не зависимых между собой, создаваемых для документа, задачи или комплекса задач. Интегрированная база данных представляет собой совокупность взаимосвязанных, хранящихся вместе данных, используемых для одного или нескольких приложений. Данные, организованные в виде базы данных (БД), могут быть организованы как централизованные базы данных, т.е. размещенные на одной ЭВМ, и в виде распределенных БД (размещенных на нескольких ЭВМ).
Программные средства ведения ИБ выбираются исходя из класса систем хранения данных: системы управления файлами либо системы управления базами данных (СУБД). К основным факторам, определяющим выбор типа СУБД, относятся следующие факторы (U5.3):
─ масштаб применения СУБД - по этому признаку выбираются персональные - настольные СУБД (например, FoxPro или Access) или промышленные - сетевые СУБД (например, Oracle, Sybase, Informix, MS SQL, ADABAS, Inter Base и др.);
─ язык общения: выбирают СУБД с открытыми языками, замкнутыми или смешанными;
─ число уровней в архитектуре: одноуровневые; двухуровневые; трехуровневые;
─ выполняемые СУБД функции: информационные - организация хранения информации и доступа к ней и операционные функции, связанные с обработкой информации;
─ сфера возможного применения СУБД: универсальное использование и специализированное.
При выполнении следующей операции (П. 6) осуществляется «Выбор методов и
средств проектирования программного обеспечения системы»,
который напрямую зависит от выбранной технологии проектирования. В универсум методов проектирования (U 6.1), используемых при каноническом подходе, входят такие, как метод структурного проектирования, модульного проектирования и другие. Основными факторами, оказывающими влияние на выбор методов, являются их совместимость, сокращение времени и стоимостных затрат на проектирование, получение качественного продукта, который был бы удобен для последующей его эксплуатации и сопровождения.
4.2.3. Составление ТЭО и формирование ТЗ.
Выполнение всех этих операций завершается составлением ТЭО
(Д 7.1) и формированием ТЗ (Д 7.2)
на операции П. 7 (см. выше рис. 4.7.). Целью разработки «Технико-экономического обоснования» проекта АИС являются оценка основных параметров, ограничивающих проект АИС, обоснование выбора и оценка основных проектных решений по отдельным компонентам проекта. При этом различают организационные параметры, характеризующие способы организации процессов преобразования информации в системе, информационные и экономические параметры, характеризующие затраты на создание и эксплуатацию системы, экономию от ее эксплуатации. Основными объектами параметризации в системе являются задачи, комплексы задач, экономические показатели, процессы обработки информации.
Организационные параметры
АИС дифференцируют по технологическим операциям процесса обработки информации: сбора, регистрации, передачи, хранения, обработки и выдачи информации. Для подготовительного этапа технологии обработки информации параметрами могут быть: вид связи между источником информации и ЭВМ, территориальное размещение технических средств, наличие промежуточного носителя информации, способ обеспечения достоверности информации и т.п. Для основного этапа технологии обработки информации в качестве параметров выступают: способ организации информационной базы, тип организации файлов, тип запоминающих устройств, режим обработки информации, тип ЭВМ, тип организации использования ЭВМ и т.п. Для заключительного этапа - способ организации связи пользователя с ЭВМ, наличие промежуточного носителя, организация размножения результатной информации и т.п.
К информационным параметрам
относятся такие, как достоверность, периодичность сбора, форма представления, периодичность обработки информации и т.д.
К экономическим параметрам
АИС относятся: показатели годового экономического эффекта, коэффициента эффективности затрат и т.п.
Параметризация позволяет определить требования к системе, оценить существующую информационную систему, определить пригодность типовых решений в проекте АИС, выбрать проектные решения в соответствии с предъявляемыми требованиями к АИС. К основным компонентам ТЭО относятся:
─ характеристика исходных данных о предметной области;
─ обоснование цели создания АИС;
─ обоснование автоматизируемых подразделений, комплекса автоматизируемых задач, выбора комплекса технических средств, программного и информационного обеспечения;
─ разработка перечня организационно-технических мероприятий по проектированию системы;
─ расчет и обоснование эффективности выбранного проекта;
─ выводы о техническом, уровне проекта и возможности дальнейших разработок.
На основе ТЭО разрабатываются основные требования к будущему проекту АИС, и составляется «Техническое задание» согласно ГОСТ 34.602 - 89 «Техническое задание на создание автоматизированной системы», в состав которого входят следующие основные разделы.
1. В разделе «Общие сведения о проекте»
указывают: полное наименование системы, код системы, код договора, наименование предприятия-разработчика и предприятия-заказчика, перечень документов, на основе которых создается система, плановые сроки начала и окончания работ по созданию системы, сведения об источниках финансирования, порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей).
2. Раздел описания «Назначение, цели создания системы»
состоит из подразделов:
─ в подразделе «Назначение системы» даются вид автоматизируемой деятельности и перечень объектов автоматизации, на которых предполагается ее использовать;
─ в подразделе «Цели создания системы» указываются наименования и требуемые значения технических, технологических, производственно-экономических и других показателей объекта автоматизации, которые будут достигнуты в результате внедрения АИС.
3. В разделе «Характеристика объекта автоматизации»
приводятся: краткие сведения об объекте автоматизации; сведения об условиях эксплуатации объекта и характеристиках окружающей среды.
4. Раздел «Требования к системе»
состоит из следующих подразделов: требования к системе в целом; требования к функциям (задачам), выполняемым системой; требования к видам обеспечения.
В подразделе «Требования к системе в целом»
указывают: требования к структуре и функционированию системы; к численности квалифицированных работников; к надежности и безопасности работы системы; к эргономике и технической эстетике, эксплуатации, техническому обслуживанию, ремонту системы; к защите информации от несанкционированного доступа; требования по сохранности информации при авариях; к защите от внешней среды; к патентной чистоте проектных решений; требования по унификации и стандартизации.
В подразделе «Требования к функциям (задачам), выполняемым
системой»,
комплексам задач и отдельным задачам приводят по каждой подсистеме перечень функций, задач или их комплексов, подлежащих автоматизации; распределение их по очередям создания; временной регламент реализации каждой функции, задачи или комплекса; требования к качеству реализации каждой функции, задачи, комплекса, к форме представления выходной информации; характеристики необходимой точности и времени выполнения, достоверности выдачи результата.
В подразделе «Требования к видам обеспечения»
содержатся требования к математическому, программному, техническому, лингвистическому, информационному и методическому обеспечению АИС.
5. Раздел «Состав и содержание работ по созданию системы»
должен содержать: перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 34.601 - 90; сроки выполнения; перечень организаций-исполнителей; перечень документов по ГОСТ 34.201 - 89 «Виды, комплектность и обозначение документов при создании автоматизированных систем», предъявляемых по окончании работ; вид и порядок проведения экспертизы технической документации и др.
6. В разделе «Порядок контроля приемки системы»
указывают: виды, состав, методы испытания системы и ее частей; общие требования к приемке работ по стадиям; порядок утверждения приемных документов; статус приемочной комиссии.
7. В разделе «Требования к составу и содержанию работ по
подготовке
объекта автоматизации к вводу системы в действие»
необходимо привести перечень необходимых мероприятий и их исполнителей, которые следует выполнять при подготовке объекта к вводу АИС в действие: приведение информации, поступающей в систему, к виду, пригодному для ввода в ЭВМ; создание условий функционирования объекта, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ; создание необходимых для функционирования системы подразделений и служб; сроки и порядок комплектования штатов и обучения персонала.
8. В разделе «Требования к документированию»
приводят: перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 - 89 и научно-технической документации отрасли заказчика.
9. В разделе «Источники разработки»
должны быть перечислены документы и информационные материалы (ТЭО, отчеты о законченных научно-исследовательских разработках, информационные материалы на отечественные, зарубежные системы-аналоги и др.).
10. В состав ТЗ при наличии утвержденных методик включают приложения, содержащие расчеты экономической эффективности системы; оценку научно-технического уровня системы.
4.3. Состав и содержание работ на стадии «Техно - рабочего проектирования».
Работы на стадии «Техно - рабочего проектирования»
выполняются на основе утвержденного «Технического задания». Разрабатываются основные положения проектируемой системы, принципы ее функционирования и взаимодействия с другими системами; определяется структура системы; разрабатываются проектные решения по обеспечивающим частям системы.
На стадии «Техно - рабочего проектирования» выполняются два этапа работ: техническое и рабочее проектирование,
технологическая сеть которых приведена на рис. 4.8 и 4.10.
4.3.1. Техническое проектирование.
На первом из них «Техническое проектирование» осуществляется логическая проработка функциональной и системной архитектуры АИС, в процессе которой строится несколько вариантов всех компонентов системы; проводится оценка вариантов по показателям: стоимости, трудоемкости, достоверности получаемых результатов, и составляется «Технический проект» системы.
Все работы первого этапа можно разбить на две группы. К первой группе относится разработка общесистемных проектных решений, в том числе:
─ разработка общесистемных положений по АИС (П.1);
─ изменение организационной структуры (П.2);
─ определение функциональной структуры (П.3);
─ разработка проектно-сметной документации и расчет экономической эффективности системы (П. 13), (П. 14);
─ разработка плана мероприятий по внедрению АИС (П. 15).
При разработке основных положений по системе
(П. 1) уточняются цели создания АИС и выполняемые ею функции; устанавливается ее взаимосвязь с другими системами и формируется документ Д 1.2 «Основные положения». Далее уточняется и изменя
ется организационная структура
(П. 2) и получается описание организационной структуры (Д 2.1).
Наиболее принципиальной в данном комплексе работ является разработка функциональной архитектуры
АИС (П. 3) Д3.1 на базе универсума U3.1 принципов выделения функциональных подсистем (модулей, контуров): предметного, функционального, смешанного (предметно-функционального) и проблемного.
Ко второй группе работ, выполняемых на этапе технического проектирования, относятся разработки локальных проектных решений, к числу которых относят следующие операции:
─ разработка «Постановки задачи» для задач, входящих в состав каждой функциональной подсистемы (П5), включающей основные
─ компоненты описания задачи и служащей основанием для разработки проектных решений по задаче;
─ проектирование форм входных и выходных документов, системы ведения документов и макетов экранных форм документов (П. 6, П. 9);
─ проектирование классификаторов экономической информации и системы ведения классификаторов (П. 7);
─ разработка структуры входных и выходных сообщений (П. 8);
─ проектирование состава и структур файлов информационной базы (П. 4);
─ проектирование внемашинной и внутримашинной технологии
─ решения каждой задачи (П. 10);
─ уточнение состава технических средств (П. 11), (П. 12).
Основным компонентом локальных проектных решений, являющимся базой для разработки информационного, программного и технологического обеспечения для каждой задачи, является «Постановка задачи»
.
Этот документ содержит три составные части (рис. 4.9.):
─ характеристику задачи;
─ описание выходной информации;
─ описание входной информации.
В состав раздела «Характеристика задачи» входят следующие компоненты:
─ описание цели;
─ назначение решения конкретной задачи;
─ перечень функций и процессов, реализуемых решаемой задачей;
─ характеристика организационной и технико-экономической сущности задачи;
─ обоснование целесообразности автоматизации решения задачи;
─ указание перечня объектов, для которых решается задача;
─ описание процедур решения задачи; указание периодичности решения задачи и требований к организации сбора первичных данных;
─ описание связей с другими задачами.
Д 1.1 – Т.З.; Д 1.2 – основные положения по АИС; Д 2.1 – описание организационной структуры; Д 3.1 – описание функциональной структуры; Д 4.1 – принципы организации информационного обеспечения; Д 5.1 – постановка задачи; Д 6.1 – формы первичных и результатных документов; Д 6.2 – система ведения документов; Д 7.1 – классификаторы; Д 8.1 – структуры сообщений; Д 9.1 – описание макетов и структур файлов; Д 10.1 – системы технологических процессов обработки данных; Д11.1 – ТЭО; Д 11.2 – описание состава и характеристика периферийной техники; Д 12.1 – АП; Д 13.1 – проектно-сметная документация; Д14.1 – показатели экономической эффективности; Д 15.1 – план мероприятий по подготовке объекта к внедрению проекта АИС; Д 16.1 – технический проект.
Рис. 4.8. ТСП выполнения работ на этапе технического проектирования.
Под целью
автоматизации решения задачи подразумевается получение определенных значений экономического эффекта в сфере управления какими-
либо процессами системы или снижение стоимостных и трудовых затрат на обработку информации, улучшение качества и достоверности получаемой
Рис.4.9. Схема структуры «Постановка задачи».
информации, повышение оперативности ее обработки и т.д., т.е. получение косвенного и прямого эффекта от внедрения данной задачи.
Под экономической сущностью решаемой задачи
понимаются состав экономических показателей, рассчитываемых при ее решении, документы, в которые заносятся эти показатели, перечень исходных показателей, необходимых для получения результатных и наименования тех первичных документов, в которых они содержатся.
Организационная сущность задачи
-
это описание порядка решения задачи; организационной формы, применяемой для ее решения; режима решения; состава файлов с постоянной и переменной информацией; способа получения и ввода первичной информации в ЭВМ; формы выдачи результатной информации: на печать, на экран, на магнитный носитель или передача по каналам связи.
Описание алгоритма решения задачи
включает формализованное описание входных и результатных показателей и перечень формул расчета результатных показателей в случае решения задачи прямым методом счета или описание математической модели, экономико-математического метода, применяемого для ее реализации, и перечня последовательных шагов выполнения расчетов.
Далее указываются периодичность
решения задачи и регламент выдачи результатных документов, требования к организации сбо
ра исходных данных,
т.е. к способу и техническим средствам съема, регистрации, сбора и передачи данных для обработки. Большое значение имеет описание связи задачи с другими
задачами
функциональной подсистемы, в которую она входит, а также с задачами других подсистем или с внешней средой.
Описание выходной информации
включает в себя: перечень и описание выходных сообщений, документов; перечень структурных единиц информации; периодичность возникновения и сроки получения информации; наименование; идентификатор по каждой форме документа.
Описание входной информации
состоит из перечня входных сообщений; перечня структурных единиц информации; описания периодичности возникновения и сроков получения информации; наименования и идентификатора по каждой форме документа.
Далее для каждой задачи разрабатываются все компоненты информационного, технического, математического и лингвистического обеспечения, а также некоторые компоненты программного обеспечения.
Результатом работ на данной стадии является утвержденный «Технический проект», состав и содержание которого регламентируются стандартом (ГОСТ 34.201 - 89).
4.3.2. Рабочее проектирование.
На втором этапе – «Рабочее проектирование»
осуществляется техническая реализация выбранных наилучших вариантов и разрабатывается документация «Рабочий проект» (рис. 4.10.). Наиболее ответственной работой, выполняемой на этом этапе, являются «Кодирование и составление программной документации» (П. 1)
, содержание которой хорошо отражено в ряде источников, например в [18, 19, 20]. В ее состав входят следующие компоненты (Д 1.2):
─ описание программ;
─ спецификация программ;
─ тексты программ;
─ контрольные примеры;
─ инструкции для системного программиста, оператора и пользователя.
Д 1.1 - технический проект; Д 1.2 - документы программного обеспечения; Д 2.1 - технические документы и инструкции; Д 3.1 -правовые инструкции; Д 4.1 - рабочий проект.
Рис. 4.10. ТСП работ, выполняемых на этапе рабочего проектирования.
Большую роль в деле эффективного использования разработанного проекта АИС играет качественная технологическая документация,
входящая в состав «Рабочего проекта». Эта часть проекта разрабатывается на операции П. 2 и предназначена для использования специалистами в своей деятельности на каждом автоматизированном рабочем месте.
В состав технологической документации (Д 2.1) входят: технологические карты, разрабатываемые на процессы обработки информации при решении задач каждого класса, и инструкционные карты; составляемые на каждую технологическую операцию.
Технологическая документация разрабатывается в соответствии с требованиями ГОСТ 3.11.09-82 «Система технологической документации. Термины и определения основных понятий», и составляет содержание технологического обеспечения АИС, которое можно разделить на ряд типов в соответствии с выделением следующих классов задач, решаемых в АИС:
─ системы обработки данных (СОД);
─ системы поддержки принятия решений (СППР);
─ системы автоматизированного проектирования новой продукции (САПР) и т.д.
К числу работ, выполняемых на этом этапе, относится «Разработка правовых инструкций»
(Д 1.2) (П. 1), определяющих права и обязанности специалистов, работающих в условиях функционирования на предприятии компонентов АИС.
Заключительной операцией служит «Оформление документации Рабочего проекта»
(Д 4.2) согласно ГОСТам (Д 4.1) на операции П. 4.
4.4. Состав и содержание работ на стадиях внедрения, эксплуатации и сопровождения проекта.
На стадии «Внедрение проекта»
проводятся подготовка и постепенное освоение разработанной проектной документации АИС заказчиками системы. В процессе выполнения работ на этой стадии осуществляется выявление частных и системных принципиальных недоработок в предлагаемом для внедрения проектном решении.
Внедрение может осуществляться с использованием следующих методов:
─ последовательный метод, когда последовательно внедряется одна подсистема за другой и одна задача следует за другой задачей;
─ параллельный метод, при котором все задачи внедряются во всех подсистемах одновременно;
смешанный подход, согласно которому проектировщики, внедрив несколько подсистем первым методом и накопив опыт, приступают к параллельному внедрению остальных.
Недостатком первого подхода является увеличение длительности внедрения, что ведет за собой рост стоимости проекта. При использовании второго подхода сокращается время внедрения, но возникает возможность пропуска ошибок в проектной документации, поэтому чаще всего используют смешанный метод внедрения проекта АИС.
Внедрение проекта осуществляется в течение трех этапов:
1. подготовка объекта к внедрению;
2. опытное внедрение;
3. сдача проекта в промышленную эксплуатацию.
Первый этап - «Подготовка объекта к внедрению»
. На этом этапе осуществляются следующие операции:
─ изменяется организационная структура объекта (предприятия);
─ набираются кадры соответствующей квалификации в области обработки информации и эксплуатации системы и сопровождения проектной документации;
─ оборудуется здание под установку вычислительной техники;
─ выполняются закупка и установка вычислительной техники с периферией;
─ в цехах, отделах устанавливаются средства сбора, регистрации первичной информации и передачи по каналам связи;
─ осуществляется установка каналов связи; проводится разработка новых документов и классификаторов;
─ осуществляется создание файлов информационной базы с нормативно-справочной информацией.
На вход этого этапа поступают компоненты «Технического проекта» в части «Плана мероприятий по внедрению», решения по техническому и информационному обеспечению, технологические и инструкционные материалы «Рабочего проекта». В результате выполнения этапа составляется «Акт готовности объекта к внедрению» проекта АИС. Затем формируется состав приемной комиссии, разрабатывается «Программа проведения опытного внедрения» и издается «Приказ о начале опытного внедрения».
Второй этап - «Опытное внедрение»
.
На этом этапе внедряются проекты нескольких задач в нескольких подсистемах. В процессе опытного внедрения выполняются следующие работы:
─ подготовка исходных оперативных данных для задач, которые проходят опытную эксплуатацию;
─ ввод исходных данных в ЭВМ и выполнение запланированного числа реализаций;
─ анализ результатных данных на предмет наличия ошибок.
В случае обнаружения ошибок осуществляются поиск причин и источников ошибок, внесение коррективов в программы, в технологию обработки информации, в работу технических средств, в исходные оперативные данные и в файлы с условно-постоянной информацией. Кроме того, выявляется неквалифицированная работа операторов, что служит основанием для проведения комплекса мер по улучшению подготовки кадров.
После устранения ошибок получают «Акт о проведении опытного внедрения», который служит сигналом для начала выполнения следующего этапа.
На третьем этапе «Сдача проекта в промышленную эксплуатацию»
используют следующую совокупность документов:
─ договорная документация;
─ «Приказ на разработку АИС»;
─ ТЭО и ТЗ;
─ исправленный «Техно-рабочий проект»;
─ «Приказ о начале промышленного внедрения»;
─ «Программа проведения испытаний»;
─ «Требования к научно-техническому уровню проекта системы».
В процессе сдачи проекта в промышленную эксплуатацию осуществляются следующие работы:
─ проверка соответствия выполненной работы договорной документации по времени выполнения, объему проделанной работы и затратам денежных средств;
─ проверка соответствия проектных решений по АИС требованиям ТЗ;
─ проверка соответствия проектной документации ГОСТ и ОСТ;
─ проверка технологических процессов обработки данных по всем задачам и подсистемам;
─ проверка качества функционирования информационной базы, оперативности и полноты ответов на запросы;
─ выявление локальных и системных ошибок и их исправление.
Кроме того, приемная комиссия определяет научно-технический уровень проекта и возможности расширения проектных решений за счет включения новых компонентов. В результате выполнения работ на данном этапе осуществляется доработка «Техно-рабочего проекта» за счет выявления системных и локальных ошибок и составляется «Акт сдачи проекта в промышленную эксплуатацию».
На четвертой стадии «Эксплуатация и сопровождение проекта»
выполняются следующие этапы:
─ эксплуатация проекта;
─ сопровождение и модернизация проекта.
На этой стадии решается вопрос о том, чьими силами (персоналом объекта-заказчика или организации-разработчика) будут осуществляться эксплуатация и сопровождение проекта, и в случае выбора второго варианта заключается «Договор о сопровождении проекта».
В процессе выполнения этапа «Эксплуатация проекта»
осуществляются исправления в работе всех частей системы при возникновении сбоев, регистрация этих случаев в журналах, отслеживание технико-экономических характеристик работы системы и накопление статистики о качестве работы всех компонентов системы.
На этапе «Сопровождение и модернизация проекта»
выполняется анализ собранного статистического материала, а также анализ соответствия параметров работы системы требованиям окружающей среды. Анализ осуществляет создаваемая для этих целей комиссия. Результаты анализа позволяют:
─ сделать заключение о необходимости модернизации всего проекта или его частей;
─ определить объемы доработок, сроки и стоимость выполнения этих работ с целью получения «Техно-рабочего проекта», прошедшего модернизацию.
В случае выявления факта морального старения проекта комиссией принимается решение о целесообразности проведения его утилизации или разработки нового проекта для данного объекта.
Вопросы для самопроверки
1
. Что такое каноническое проектирование АИС и каковы особенности его содержания?
2. Какова цель этапа «Сбор материалов обследования»?
3. Что может служить для проектировщика объектом обследования?
4. Каковы состав и содержание методов организации проведения обследования?
5. Какие методы для сбора материалов обследования используются, и для каких целей?
6. Перечислите состав вопросов в программе обследования при системном и локальном подходах к проектированию ЭИС.
7. Что такое план-график проведения работ, и каково его назначение?
8. Каково назначение этапа «Анализ материалов обследования»?
9. Каков состав методов формализации материалов обследования?
10. Каков состав документов, предназначенных для формализованного описания материалов обследования?
11. Каков состав факторов отбора объектов для проведения автоматизации работ и выбора состава автоматизируемых задач?
12. Каков состав факторов выбора типов вычислительной техники и операционных систем?
13. Каковы факторы выбора способов организации хранения данных в информационной базе и типов СУБД?
14. Каково назначение и каков состав разделов «Технико-экономического обоснования»?
15. Каково назначение и содержание «Технического задания»?
16. Каковы назначение и состав операций стадии «Техно - рабочее проектирование»?
17. Какие работы «Техно - рабочего проектирования» относятся к разработке общесистемных проектных решений, и каково их содержание?
18. Какой состав работ относится к разработке локальных решений проекта ЭИС?
19. Что такое «Постановка задачи» и каков состав компонентов этого документа?
20. Каков состав разделов «Технического проекта АИС»?
21. Какие работы относятся к этапу «Рабочего проектирования»?
22. Какие разделы выделяются в документации «Рабочего проекта»?
23. Каковы состав, последовательность выполнения работ на стадии «Внедрение проекта», состав получаемой документации?
24. Каков состав работ по подготовке объекта к внедрению проекта АИС?
25. Каковы методы организации внедрения проекта АИС и их особенности?
5.
Структурный подход к проектированию информационных систем.
Данный раздел посвящён структурному подходу к проектированию ИС. Здесь будут рассмотрены наиболее распространенные формализованные методы структурного анализа и проектирования: моделирование потоков данных и моделирование данных (подход «сущность – связь»).
Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе. С их помощью эти требования представляются в виде иерархии функциональных компонентов (процессов), связанных потоками данных. Такое представление позволяет продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также установить отношения между этими процессами. Для построения диаграмм потоков данных традиционно используются две различные нотации, соответствующие методам Йордана и Гейна - Сэрсона. Эти нотации незначительно отличаются друг от друга графическим представлением символов. Далее при построении примеров будет использоваться нотация Гейна - Сэрсона.
5.1. Моделирование потоков данных (процессов).
5.1.1. Общие сведения.
В структурном анализе в основном используется две группы средств:
─ модели, иллюстрирующие функции, выполняемые системой,
─ модели, иллюстрирующие отношения между данными.
Поэтому часто этот подход называют ещё функциональным.
Распространенными видами моделей (диаграмм) являются:
─ Data Flow Diagrams – DFD – диаграммы потоков данных;
─ Structured Analysis and Design Technique – SADT – модели и соответствующие функциональные диаграммы;
─ Entity – Relationship Diagrams – ERD – диаграммы «сущность - связь».
Наиболее часто используемые виды моделей – это диаграммы потоков данных (DFD) и диаграммы «сущность - связь» (ERD).
На стадии проектирования программного обеспечения ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения (ПО):
─ архитектуру программного обеспечения;
─ структурные схемы программ;
─ диаграммы экранных форм.
Перечисленные модели в совокупности дают полное описание ИС и её программного обеспечения.
Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.
Диаграммы потоков данных (
Data Flow Diagrams – DFD)
являются основным средством моделирования функциональных требований к проектируемой системе. С помощью диаграмм потоков данных предъявляемые требования представляются в виде иерархии функциональных компонентов (процессов), связанных потоками данных. Главная цель такого представления состоит в том, чтобы показать, как каждый процесс преобразует входные данные в выходные, а также выявить отношения между этими процессами.
В данном подходе модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю.
Диаграммы верхних уровней иерархии контекстные диаграммы
определяют основные бизнес-процессы или подсистемы ИС с внешними входами и выходами. Термин «контекст» происходит от латинского слова «contextus» и дословно означает соединение. В применении к нашему изложению оно означает процесс, характеризующийся определенным общим смыслом и предназначением. Однако описание процесса в таком виде слишком абстрактно, чтобы было возможно использовать его как рабочую модель.
Поэтому процесс разбивают на подпроцессы, упрощая задачу и уточняя его описание. Причём эта декомпозиция процесса продолжается до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором решение задачи становиться ясным, и не представляет затруднений. При этом дальнейшая детализация уже не имеет смысла.
Декомпозиция осуществляется при помощи диаграмм нижнего уровня
. Таким образом, получаем многоуровневую иерархию диаграмм. Источники информации (внешние сущности, действующие лица) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации.
5.1.2. Состав диаграмм потоков данных.
Основными компонентами диаграмм потоков данных являются:
─ внешние сущности;
─ системы и подсистемы;
─ процессы;
─ накопители данных;
─ потоки данных.
Внешняя сущность
. Это материальный объект или действующее физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад.
Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что они находятся за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается прямоугольником (рис. 5.1) расположенным как бы над диаграммой и бросающим на нее тень для того, что бы можно было выделить этот символ среди других обозначений.
Рис. 5.1. Графическое изображение внешней сущности.
При построении модели сложной ИС она может быть представлена в самом общем виде на конкретной диаграмме в виде одной системы как одного целого, либо может быть декомпозирована на ряд подсистем.
Подсистема (система)
на контекстной диаграмме изображается так, как это показано на рисунке 5.2.
Рис. 5.2. Подсистема по работе с физическими лицами.
Номер подсистемы, служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим, определениями и дополнениями.
Процесс
. Это преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это могут быть подразделения организации (отдел), выполняющие обработку входных документов и выпуск отчетов; программа; аппаратно реализованное логическое устройство и т. д.
На диаграмме потоков данных процесс изображается, как это показано на рис. 5.3.
Рис. 5.3. Графическое изображение процесса.
Номер процесса, служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например: «Ввести сведения о налогоплательщиках», «Выдать информацию о текущих расходах», «Проверить поступление денег».
Использование таких глаголов, как «обработать», «модернизировать» или «отредактировать», означает недостаточно глубокое понимание данного процесса и требует дальнейшего анализа.
Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.
Накопитель данных - э
то абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Накопитель данных может быть физически реализован в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т. д. Накопитель данных на диаграмме потоков данных изображается, как показано на рис. 5.4.
Рис. 5.4. Графическое изображение накопителя данных.
Накопитель данных идентифицируется буквой «D» и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика. Накопитель данных, в общем случае, является прообразом будущей базы данных.
Описание хранящихся в нем данных должно быть увязано с информационной моделью (ERD).
Поток данных
определяет информацию, передаваемую через некоторое соединение, канал передачи от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами; письмами, пересылаемыми по почте; магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т. д.
На диаграмме поток данных изображается линией, оканчивающейся стрелкой, которая указывает направление потока (рис. 5.5.).
Каждый поток данных имеет имя, отражающее его содержание.
(ГНИ - Государственная налоговая инспекция)
Рис. 5.5. Поток данных.
5.1.3. Построение иерархии диаграмм потоков данных.
Главная цель построения иерархии для диаграммы потоков данных заключается в том, чтобы сделать требования к системе ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определёнными отношениями между ними. Для достижения этого целесообразно пользоваться следующими рекомендациями:
─ на каждой диаграмме рекомендуется размещать от 3 до 7, но не более процессов, поскольку верхняя граница соответствует ограниченным возможностям человека воспринимать и понимать структуру сложной системы с множеством внутренних связей. Нижняя граница выбрана по соображениям здравого смысла (нет смысла детализировать процесс диаграммой, содержащей один - два процесса);
─ не загромождать диаграммы не существенными деталями;
─ осуществлять декомпозицию потоков параллельно с декомпозицией процессов;
─ выбирать ясные, отражающие суть дела имена процессов и потоков, стараясь не использовать аббревиатуры.
Первым шагом при построении иерархии является построение контекстных диаграмм. Обычно при проектировании простых ИС строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Перед построением контекстной диаграммы необходимо проанализировать внешние события (внешние сущности), оказывающие влияние на функционирование системы. Количество потоков на контекстной диаграмме должно быть по возможности небольшим, поскольку каждый из них в дальнейшем может быть ещё разбит на потоки в последующих уровнях диаграммы.
Для проверки контекстной диаграммы можно составить список событий. Список событий должен состоять из описаний действий внешних сущностей (событий) и соответствующих реакций системы на события. Каждое событие должно соответствовать одному (или более) потоку данных: входные потоки интерпретируются как воздействия, а выходные потоки - как реакции системы на входные потоки.
Если для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги нормального формата, и, кроме того, главный единственный процесс не раскрывает структуры такой системы. Признаками сложности (в смысле контекста) могут быть: наличие большого количества внешних сущностей (десять и более), распределённая природа системы, многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы.
Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не главный единственный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.
Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой информационной системы, как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует ИС.
Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры ИС на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем, в создании которых участвуют разные организации и коллективы разработчиков.
После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами).
Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи диаграмм потоков данных. Это можно сделать путем построения диаграммы для каждого события. Каждое событие представляется в виде процесса с соответствующими входными и выходными потоками, накопителями данных, внешними сущностями и ссылки на другие процессы для описания связей между этим процессом и его окружением. Затем все построенные диаграммы сводятся в одну диаграмму нулевого уровня
.
Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFD или (если процесс элементарный) спецификации. При этом должны выполняться следующие правила:
─ правило балансировки – при детализации подсистемы, или процесса детализирующая диаграмма в качестве внешних источников или приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеют информационную связь детализируемые подсистема или процесс на родительской диаграмме;
─ правило нумерации – при детализации процессов должна поддерживаться их иерархическая нумерация. Так, например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12,2, и т.д.
Спецификация
процесса
(описание логики) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу.
Спецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании спецификации принимается аналитиком исходя из следующих критериев:
─ наличие у процесса небольшого количества входных данных и выходных потоков данных (2-3 потока);
─ возможности описания преобразования данных процессом в виде последовательного алгоритма;
─ выполнения процессом единственной логической функции преобразования входной информации в выходную информацию;
─ возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк).
Спецификации должны удовлетворять следующим требованиям:
─ для каждого процесса нижнего уровня должна существовать только одна спецификация;
─ спецификация должна определять способ преобразования входных потоков в выходные;
─ на стадии формирования требований нет необходимости определять метод реализации этого преобразования;
─ в спецификации не должно быть избыточности, не следует переопределять то, что уже было определено на диаграмме;
─ набор конструкций для построения спецификации должен быть простым и понятным.
Фактически спецификации представляют собой описания алгоритмов задач, выполняемых процессами.
Спецификации содержат номер и/или имя процесса, списки входных и выходных данных и тело (описание) процесса. Соответствующие этим методам языки могут варьироваться от структурированного естественного языка или псевдокода до визуальных языков проектирования.
Структурированный естественный язык применяется для читабельного, достаточно строгого описания спецификаций процессов. Он представляет собой разумное сочетание строгости языка программирования и читабельности естественного языка и состоит из подмножества слов, организованных в определённые логические структуры, арифметических выражений и диаграмм.
В состав языка входят следующие основные символы:
─ глаголы, ориентированные на действие и применяемые к объектам;
─ термины, определенные на любой стадии проекта ПО (например, задачи, процедуры, символы данных и т.п.);
─ предлоги и союзы, используемые в логических отношениях;
─ общеупотребительные математические, физические и технические термины;
─ арифметические уравнения;
─ таблицы, диаграммы, графы и т.п.;
─ комментарии.
К управляющим структурам языка относятся последовательная конструкция, конструкция выбора и итерация (цикл). При использовании структурированного естественного языка приняты следующие соглашения:
─ логика процесса выражается в виде комбинации последовательных конструкций, конструкций выбора и итераций;
─ глаголы должны быть активными, недвусмысленными и ориентированными на целевое действие (заполнить, вычислить, извлечь, а не модернизировать, обработать);
─ логика процесса должна быть выражена четко и недвусмысленно.
При построении иерархии ДПД переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных. Содержание всех потоков и накопителей данных описывается при помощи структур данных. Для каждого потока данных формируется список всех его элементов данных, затем элементы данных объединяются в структуры данных, соответствующие более крупным объектам данных (например, строкам документов или объектам предметной области). Каждый объект должен состоять из элементов, являющихся его атрибутами. Структуры данных могут содержать альтернативы, условные вхождения и итерации.
Условное вхождение
показывает, что данный компонент может отсутствовать в структуре (например, структура «данные о страховании» для объекта «служащий»).
Альтернатива
означает, что в структуру может входить один из перечисленных элементов.
Итерация
предусматривает вхождение любого числа элементов в указанном диапазоне (например, элемент «имя ребенка» для объекта «служащий»).
Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных
могут указываться единица измерения (кг, см, и т. п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных
может указываться таблица допустимых значений.
После построения законченной модели системы ее необходимо проверить на полноту и согласованность – верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы,
В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации. Все данные, поступающие куда либо, должны быть считаны, а все считываемые данные должны быть записаны.
5.1.4. Функциональные модели, используемые на стадии проектирования.
Как было сказано, функциональные модели, используемые на стадии проектирования
ПО, предназначены для описания функциональной структуры проектируемой системы. Построенные ранее диаграммы потоков DFD могут уточняться, расширяться и дополняться новыми конструкциями. Помимо диаграмм потоков DFD используются и другие диаграммы, отражающие системную архитектуру ПО, иерархию экранных форм и меню, структурные схемы программ и т.д. Состав диаграмм и степень их детализации определяются необходимой полнотой описания системы для непосредственного перехода к ее последующей реализации (программированию).
Так, например, для диаграммы потоков DFD переход от
модели бизнес-процессов организации к модели системных процессов
может происходить следующим образом:
─ внешние сущности на контекстной диаграмме заменяются или дополняются техническими устройствами (например, рабочими станциями, принтерами и т.д.);
─ для каждого потока данных определяется, посредством каких технических устройств информация производится или передается;
─ процессы на контекстной диаграмме нулевого уровня заменяются соответствующими процессорами - обрабатывающими устройствами (процессорами могут быть как технические устройства - персональные компьютеры конечных пользователей, рабочие станции, серверы баз данных, так и служащие - исполнители);
─ определяется и изображается на диаграмме тип связи между процессорами (например, локальная сеть – Local Area Network - LAN);
─ определяются задачи для каждого процессора (приложения, необходимые для работы системы), для них строятся соответствующие диаграммы и определяется тип связи между задачами;
─ устанавливаются ссылки между задачами и процессами диаграмм потоков данных следующих уровней.
Иерархия экранных форм моделируется с помощью диаграмм последовательностей экранных форм.
Совокупность таких диаграмм представляет собой абстрактную модель пользовательского интерфейса системы, отражающую собой последовательность появления экранных форм в приложении. Построение диаграмм последовательностей экранных форм выполняется следующим образом:
─ на диаграмме потоков DFD выбираются интерактивные процессы нижнего уровня. Интерактивные процессы нуждаются в пользовательском интерфейсе, поэтому можно определить экранную форму для каждого такого процесса;
─ форма диаграммы изображается в виде прямоугольника для каждого интерактивного процесса на нижнем уровне диаграммы;
─ определяется структура меню. Для этого интерактивные процессы группируются в меню (либо также как в модели процессов, либо другим способом - по функциональным признакам или в зависимости от принадлежности к определенным объектам);
─ формы с меню изображаются над формами, соответствующими интерактивным процессам, и соединяются с ними переходами в виде стрелок, направленных от меню к формам;
─ определяется верхняя форма (главная форма приложения), связывающая все формы с меню.
Вопросы для самопроверки
1. Перечислите, какие модели в совокупности дают полное описание ИС и её программного обеспечения в структурном подходе?
2. Назовите основные компоненты диаграмм потоков данных.
3. Опишите основные компоненты диаграмм потоков данных.
4. В чем состоит основная цель построения иерархии для диаграммы потоков данных?
5. Что представляет собой контекстная диаграмма?
6. Каким требованиям должны удовлетворять спецификации?
7. Каким образом осуществляется переход от модели бизнес-процессов организации к модели системных процессов?
8. Каким образом выполняется построение диаграмм последовательностей экранных форм?
5.2. Пример использования структурного подхода в нотации
CASE-средства
Vantage
Team
Builder.
5.2.1. Описание предметной области.
В этом примере используется нотация метода реализованного в CASE-средстве Vantage Team Builder [2].
Описание предметной области.
В качестве бизнес-процесса рассматривается функционирование видеобиблиотеки. Видеобиблиотека предоставляет услуги клиентам, получая от них запросы на аренду фильмов и лент. Клиенты после использования фильмов и лент возвращают их в видеобиблиотеку.
Запросы на аренду рассматриваются администрацией с использованием информации о клиентах, фильмах и лентах. При этом проверяется и обновляется список арендованных лент, а так же записи о том является ли клиент зарегистрированным членом библиотеки.
Администрация контролирует так же возвраты лент, используя информацию о фильмах, лентах и список арендованных лент, который обновляется.
Обработка запросов на фильмы и возврат лент включает следующие действия. Вначале выясняется, является ли клиент членом библиотеки (если нет, то он не имеет права на аренду). Если затребованный фильм имеется в наличии, администрация информирует клиента об арендной плате. При этом, если клиент просрочил срок возврата находящихся у него лент, ему не разрешается брать новые фильмы. Когда лента возвращается, администрация рассчитывает арендную плату плюс пени за несвоевременный возврат.
Информация о членстве в библиотеке содержится отдельно от записей об аренде лент.
Видеобиблиотека получает новые ленты от своих поставщиков. Когда новые ленты поступают в библиотеку, необходимая информация о них фиксируется.
Администрация библиотеки регулярно готовит отчеты за определенный период времени о членах библиотеки, поставщиках лент, выдачи лент и приобретении лент библиотекой.
5.2.2. Жизненный цикл и технология выполнения проекта.
Жизненный цикл проекта разделяется на четыре фазы как это показано на рис 5.6.
I.
Анализ системы.
На этой фазе строится модель среды (Environmental Model). Построение модели среды включает анализ поведения системы и анализ данных.
Анализ поведения системы включает:
─ определение цели, предназначения ИС;
─ построение начальной контекстной диаграммы потоков данных (Data Flow Diagram-DFD);
─ формирование матрицы списка событий (Event List Matrix-ELM);
─ построение полных контекстных диаграмм.
В процессе анализа данных осуществляют:
─ определение состава потоков данных и построение диаграмм структур данных (Data Structure Diagram-DSD);
─ конструирование концептуальной, глобальной модели данных в виде ER-диаграммы (Entity-Relationship Diagram - ERD).
Цель создания ИС
определяет соглашение между проектировщиками и заказчиками относительно предназначения будущей ИС, общее описание ИС для самих проектировщиков и границы ИС. Назначение фиксируется как текстовый комментарий в «нулевом» процессе контекстной диаграммы.
Например, в данном случае назначение ИС формулируется следующим образом: ведение базы данных о членах библиотеки, фильмах, аренде и поставщиках. При этом руководство библиотеки должно иметь возможность получать различные виды отчетов для выполнения своих задач.
Рис. 5.6. Четыре фазы проекта.
Перед построением контекстной диаграммы потоков данных – DFD необходимо проанализировать внешние события (внешние объекты), оказывающие влияние на функционирование библиотеки. Внешние объекты взаимодействуют с ИС путем информационного обмена с ней. Из описания предметной области следует, что в процессе работы библиотеки участвуют следующие группы людей: клиенты, поставщики и руководство. Эти группы являются внешними объектами. Они не только взаимодействуют с системой, но так же определяют ее границы и изображаются на начальной контекстной диаграмме потоков данных DFD как терминаторы (внешние сущности).
Начальная контекстная диаграмма потоков данных
изображена на рис. 5.7. В используемой нотации внешние сущности обозначаются прямоугольниками, а процессы - окружностями.
Список событий строится в виде матрицы списка событий (
Event List Matrix-ELM)
и описывает различные действия внешних сущностей и реакцию ИС на них.
Эти действия представляют собой внешние события
, воздействующие на библиотеку. Различают следующие типы событий:
- NC (Normal Control)-нормальное управление;
- ND (Normal Data)-нормальные данные;
- NCD (Normal Control/Data)-нормальное управление/данные;
- TC (Temporary Control)-временное управление;
- TD (Temporary Data)-временные данные;
- TCD (Temporary Control/Data)-временное управление/данные.
Все действия помечаются как нормальные данные. Эти данные являются событиями, которые ИС воспринимает непосредственно, например, изменение адреса клиента, которое должно быть сразу зарегистрировано. Они появляются в диаграмме потоков данных DFD в качестве содержимого потока данных.
Рис. 5.7. Начальная контекстная диаграмма потоков данных (DFD).
Матрица списка событий (ELM) имеет вид представленный в таблице 5.1.
Анализ функционального аспекта
поведения системы завершается построением полной контекстной диаграммы
, и представляет диаграмму нулевого уровня. При этом процесс
«библиотека» декомпозируется на 4 процесса, отражающих основные виды административной деятельности библиотеки. Существующие «абстрактные» потоки данных между терминаторами и процессами трансформируются в потоки, представляющие обмен данными на более конкретном уровне (таблица 5.2).
Таблица 5.1. Матрица списка событий (ELM).
| Описание события |
Тип |
Реакция системы |
| -Клиент желает стать членом библиотеки. -Клиент сообщает об изменении адреса. -Клиент запрашивает аренду фильма. -Клиент возвращает фильм. -Руководство дает полномочия новому поставщику. -Поставщик сообщает об изменении адреса. -Поставщик направляет фильм в библиотеку. -Руководство запрашивает новый отчет. |
ND ND ND ND ND ND ND ND |
Регистрация клиента как члена библиотеки. Регистрация измененного адреса. Рассмотрение запроса. Регистрация возврата. Регистрация поставщика. Регистрация измененного адреса. Получение нового фильма. Формирование требуемого отчета для руководства. |
Матрица списка событий показывает, какие потоки существуют на этом уровне: каждое событие из списка должно формировать некоторый поток (событие формирует входной поток, реакция - выходной поток). Один «абстрактный» поток может быть разделен на более чем один «конкретный» поток.
Полная контекстная диаграмма потоков данных приведена на рис. 5.8. Здесь накопитель данных «библиотека» является абстрактным представлением хранилища данных
.
Анализ функционального аспекта поведения системы дает представление об облике и преобразовании данных в системе. Взаимосвязь между «абстрактными» и «конкретными» потоками данных на диаграмме нулевого уровня выражается в диаграммах структур данных (рис. 5.9).
Таблица 5.2. Соответствие потоков данных на диаграммах различных уровней.
| Потоки на диаграмме верхнего уровня (абстрактные) |
Потоки на диаграмме нулевого уровня (конкретные) |
| Информация от клиента. Информация для клиента. Информация от руководства. Информация для руководства. Информация от поставщика. |
Данные о клиенте, запрос об аренде. Членская карточка, ответ на запрос об аренде. Запрос отчета о новых членах, новый поставщик, запрос отчета о поставщиках, запрос отчета об аренде, запрос отчета о фильмах. Отчет о новых членах, отчет о поставщиках, отчет об аренде, отчет о фильмах. Данные о поставщике, новые фильмы. |
Рис. 5.8. Полная контекстная диаграмма потоков данных.
Рис. 5.9. Диаграмма структур данных.
На фазе анализа строится концептуальная, глобальная модель данных
, представляемая в виде диаграммы «сущность-связь» (рис. 5.10).
Между различными типами диаграмм существуют следующие взаимосвязи:
- ELM-DFD: события - входные потоки, реакции – выходные потоки;
- DFD-DSD: потоки данных – структуры данных верхнего уровня;
- DFD-ERD: накопители данных – ER-диаграммы;
- DSD-ERD: структура данных нижнего уровня - атрибуты сущностей.
Рис. 5.10. Диаграмма «сущность – связь».
II. Проектирование архитектуры системы.
На этой фазе строится предметная модель. Процесс построения предметной модели включает в себя последовательность действий:
-детальное описание функционирования системы;
-дальнейший анализ использованных данных и построение логической модели данных для последующего проектирования базы данных;
-определение структуры пользовательского интерфейса;
-уточнение диаграмм потоков данных и списка событий, выделение среди процессов нижнего уровня интерактивных и не интерактивных, определение для них спецификаций. Возможная детализация процесса «Администрирование членов библиотеки», находящегося на контекстной диаграмме (см. рис. 5.8), приведена на рис. 5.11.
Рис.5.11. Детализация контекстной диаграммы.
Результатами проектирования архитектуры являются:
─ модель процессов (диаграмма архитектуры системы- System Architecture Diagram- SAD и спецификации на структурированном языке);
─ модель данных (ERD и подсхемы ERD);
─ модель пользовательского интерфейса (классификация процессов на интерактивные и не интерактивные функции, диаграмма последовательности форм (Form Sequence Diagram- FSD), показывающая, какие формы появляются в приложении, и в каком порядке).
На диаграмме последовательности форм FSD фиксируются набор и структура вызовов экранных форм. Диаграммы FSD образуют иерархию, на вершине которой находится главная форма приложения, реализующего подсистему. На втором уровне находятся формы, реализующие процессы нижнего уровня функциональной структуры, зафиксированной на диаграммах архитектуры системы (SAD).
III. Детальное проектирование.
На фазе детального проектирования строится модульная модель. Под модульной моделью понимается реальная модель проектируемой прикладной системы. Процесс и построение включает в себя:
─ уточнение модели базы данных для последующей генерации предложений на структурированном языке запросов (Structured Query Language - SQL), SQL-предложений, определяющих структуру целевой БД;
─ уточнение структуры пользовательского интерфейса;
─ построение структурных схем, отражающих логику работы пользовательского интерфейса и модель бизнес – логики, т.е. структурную схему программы Structure Charts Diagram-SCD, и привязка их к формам.
Результатами детального проектирования являются:
─ модель процессов (структурные схемы интерактивных и не интерактивных функций);
─ модель данных (определение в ERD всех необходимых параметров для приложений);
─ модель пользовательского интерфейса (диаграмма последовательности форм (FSD), показывающая, какие формы появляются в приложении, и в каком порядке, взаимосвязь между каждой формой и определенной структурной схемой, между каждой формой и одной или более сущностью в (ERD)).
IV. Реализация
. Здесь строится реализационная модель. Процесс ее создания включает в себя:
─ генерацию предложений на структурированном языке запросов (SQL-предложений), определяющих структуру целевой БД (таблицы, индексы, ограничения целостности данных - ограничения непротиворечивости данных).
─ уточнение структурных схем программ (SCD) и диаграмм последовательности форм (FSD) с последующей генерацией кода приложений.
На основе анализа потоков данных и взаимодействия процессов с хранилищами данных осуществляется окончательное выделение подсистем (предварительное выделение должно быть сделано и зафиксировано на этапе формирования требований в техническом задании). При выделении подсистем необходимо руководствоваться принципами функциональной связанности и минимизации информационной зависимости. Необходимо учитывать, что на основании таких элементов подсистемы, как процессы и данные, на этапе разработки должно быть создано приложение, способное функционировать самостоятельно. С другой стороны, при группировке процессов и данных в подсистемы необходимо учитывать требования к конфигурированию продукта, если они были сформулированы на этапе анализа.
Библиографический список.
1. Абутидзе З.С., Александровская Л.Н., Бас В.Н., Круглов В.И., Червяков Л.М., Шолом А.М. Управление качеством и реинжиниринг организаций: Учебное пособие.- М.: Логос, 2003-328 с.: ил.
2. Вендров А.М. CASE- технологии. Современные методы и средства проектирования информационных систем. – М.: Финансы и статистика, 1998.-176 с.: ил.
3. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2000. – 352 с.: ил.
4. Гайдамакин Н.А. Автоматизированные информационные системы, базы и банки данных. Вводный курс: Учебное пособие. - М.: Гелиос АРВ, 2002.-368с.: ил.
5. Елиферов В.Г., Репин В.В. Бизнес-процессы. Регламентация и управление:
Учебник. - М.: ИНФРА-М, 2004.-319 с. - (Учебники для программы МВА
).
6. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем: Учебник. / Под ред. Ю.Ф. Тельнова. - М.: Финансы и статистика, 2003. – 512 с.: ил.
7. Тельнов Ю.Ф. Реинжиниринг бизнес – процессов. – М.: Финансы и статистика, 2003. – 256 с.: ил.
8 Калянов Г.Н. Консалтинг при автоматизации предприятий: Научно-практическое издание. - М.: СИНТЕГ, 1997.-316 с.: ил.
9. Маклаков С.В. BPWin и ERWin. CASE - средства разработки информационных систем. - М.: ДИАЛОГ-МИФИ, 2000.-256 с.
10. Марка Д.А., Мак Гоун К. Методология структурного системного анализа и проектирования SADT: Пер. с англ. - М.: Метатехнология, 1993.-240 с.
11.Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. - М.: Мир, 1999.- 191 с.
12. Ивлев В.А., Попова Т.В. Реорганизация деятельности предприятий: от структурной к процессной организации.- М.: Научтехлитиздат, 2000.-271 с.
13. Шеер А.В. Бизнес – процессы. Основные понятия. Теория. Методы.: Пер. с англ.; Под ред. М.С. Каменновой – М.: Весть - Метатехнология, 1999.-152 с.
14. Шеер А.В. Моделирование Бизнес – процессов.- Пер. с англ.; Под ред. М.С. Каменновой – М.: Весть - Метатехнология, 2000.-205 с.
15. Гаврилова Т.А., Хорошевский В.Ф. Базы знаний интеллектуальных систем: Учебник.-М.: Питер, 2000.-382 с.
16. Тельнов Ю.Ф. Интеллектуальные информационные системы в экономике: Учеб. пособие. – 3-изд.-М.: СИНТЕГ, 2002.-306 с.
17. Тельнов Ю.Ф. Использование стандартов (методологий) моделирования (IDEF, UML, ARIS) на различных стадиях реинжиниринга бизнес – процессов и проектирования информационной системы. // Сб.тр. II-й Всероссийской практической конференции «Стандарты в проектах современных информационных систем». – М.: Открытые системы, 2002.-с. 82-87.
18. Благодатских В.А., Енгибарян М.А., Ковалевская Е.В. и др. Экономика, разработка и использование программного обеспечения ЭВМ. – М.: Финансы и статистика, 1995.
19. ГОСТ 19.101-77. Единая система программной документации: Виды программ и программных документов.- М.: Изд. стандартов,1994.
20. ГОСТ 19.105-78. Единая система программной документации: Общие требования к программным документам.- М.: Изд. стандартов,1994.