Файл: PRIS.doc

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

• разработать и обосновать требования, предъявляемые к подсистемам;

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

• установить общие требования к проектируемой системе;

• определить перечень задач создания системы и исполнителей;

• определить этапы создания системы и сроки их выполнения;

• провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.

Стадия 4. Эскизный проект

• разработка предварительных проектных решений по системе и ее частям;

• разработка эскизной документации на ИС и ее части.

Комментарии:

На этапе разработка предварительных проектных решений по системе и ее частям определяются функции АС; функции подсистем, их цели и эффекты; состав комплексов задач и отдельных задач; концепции информационной базы, ее укрупненная структура; функции системы управления базой данных; состав вычислительной системы; функции и параметры основных программных средств

Эскизный проект предусматривает разработку предварительных проектных решений по системе и ее частям. Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эскизного проектирования определяются:

• функции ИС;

• функции подсистем, их цели и ожидаемый эффект от внедрения;

• состав комплексов задач и отдельных задач;

• концепция информационной базы и ее укрупненная структура;

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

• состав вычислительной системы и других технических средств;

• функции и параметры основных программных средств.

По результатам проделанной работы оформляется, согласовывается и утверждается документация в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию системы. В соответствии с РД 50.34.698-90 документация стадии эскизного проектирования оформляется по ГОСТ 2.106

Выполнение стадии эскизного проектирования не является строго обязательной. Если основные проектные решения определены ранее или достаточно очевидны для конкретной ИС и объекта автоматизации, то эта стадия может быть исключена из общей последовательности работ.

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

Стадия 5. Технический проект

• разработка проектных решений по системе и ее частям;

• разработка документации на ИС и ее части;

• разработка и оформление документации на поставку комплектующих изделий;

• разработка заданий на проектирование в смежных частях проекта.

Комментарии:

Если техническое задание регламентирует взаимодействие между Заказчиком системы и Исполнителем, то технический проект – это документ определяющий порядок взаимодействия между участниками проекта: проектировщиками и программистами.

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

Стадия 6. Рабочая документация

• разработка рабочей документации на ИС и ее части;

• разработка и адаптация программ.

Комментарии:

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

Стадия 7. Ввод в действие

• подготовка объекта автоматизации;

• подготовка персонала;

• комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

• строительно-монтажные работы;

• пусконаладочные работы;

• проведение предварительных испытаний;

• проведение опытной эксплуатации;

• проведение приемочных испытаний.

4. Структурный подход к проектированию ИС. [8]

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

1. Целей проекта.

2. Требований к информации необходимой для анализа и принятия решений в рамках конкретного проекта.

3. Возможностей подхода с учетом требований п. 2.

4. Особенностей разрабатываемой/внедряемой информационной системы.

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

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

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

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

1. «разделяй и властвуй» – решение сложных проблем производится путем их разбиения на множество меньших независимых задач, легких для понимания и решения;

2. иерархического упорядочивания – организация составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

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

• абстрагирования – выделение существенных аспектов системы и отвлечения от несущественных;

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

• непротиворечивости – обоснованность и согласованность элементов;

• структурирования данных – данные должны быть структурированы и иерархически организованы.

Далее необходимо выделить основные положительные и отрицательные моменты структурного подхода к проектированию ИС.

К достоинствам данного подхода относятся, прежде всего:

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

• применение универсальных графических языков моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов;

• проверенность временем и широкое распространение среди аналитиков и разработчиков.

В качестве недостатков можно выделить такие:

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

• сложность восприятия иерархически упорядоченной информации;

• необходимость следования жесткой (не всегда необходимой) структуре.

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

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

Наиболее распространенными являются следующие виды диаграмм:

• SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы. Для новых систем SADT (IDEF0) применяется для определения требований (функций) для разработки системы, реализующей выделенные функции. Для уже существующих методология IDEF0 может быть использована для анализа функций, выполняемых системой. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Вершина этой древовидной структуры, представляющая собой самое общее описание системы. После описания системы в целом проводится разбиение ее на крупные фрагменты (функциональная декомпозиция).

• DFD (Data Flow Diagrams) диаграммы потоков данных. Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Как правило, диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0;

• IDEF3. Методология моделирования IDEF3 позволяет описать процессы, фокусируя внимание на течении этих процессов, позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций;

• ERD (Entity-Relationship Diagrams) диаграммы «сущность-связь» Методология описания данных (IDEF1X).

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

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

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

5. Методология SADT (IDEF0). Синтаксис IDEF0. Правила построения IDEF0-диаграмм. Стадии создания IDEF0-модели (РД IDEF0 - 2000) [8]

Интерфейсная стрелка

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

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

Выходы одной функции могут быть Входами, Управлением или Механизмами для другой. В зависимости от того, с какой стороной блока связан поток, его называют соответственно “входным”, “выходным”, “управляющим”.

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

2. Интерфейсная стрелка «управление» (Control) определяет как, когда и в каком случае выполняется функция, и какой результат от нее ожидается. Каждая функция (IDEF0-блока) должна иметь как минимум один вход управления. Управление часто представляется в виде правил, норм, процедур, стандартов. Они оказывают влияние на выполнение функции, не изменяясь при этом сами. Управление – это особый тип входных данных функции. Часто даже возникает вопрос, какого типа должна быть стрелка: вход или управление.

3. Интерфейсная стрелка «ресурс» или «механизм» (Mechanism) обозначает те ресурсы, при помощи которых выполняется функция. В качестве механизма выступают люди, машины, оборудование, которые обеспечивают все необходимое для реализации функции. IDEF0-блок может не содержать стрелок механизма. Это объясняется тем, что знание механизма, осуществляющего функцию, зачастую не является целью моделирования системы.

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

5. Интерфейсные стрелки ссылки (Call Arrow) используются для указания на другие модели или диаграммы внутри модели, которые помогают лучше понять модель. Интерфейсная стрелка ссылки может ссылаться на другую диаграмму внутри самой модели или на специфическое дочернее действие другой модели. Данный вид стрелок в дипломной работе не использовался.