Проектирование информационной системы (ИС). Понятия и структура проекта ис icon

Проектирование информационной системы (ИС). Понятия и структура проекта ис


Скачать 102.87 Kb.
НазваниеПроектирование информационной системы (ИС). Понятия и структура проекта ис
Размер102.87 Kb.
ТипДокументы
1330_2005940666">Краткая характеристика применяемых технологий проектирования. 7




  1. Проектирование информационной системы (ИС). Понятия и структура проекта ИС

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

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

  • требуемую пропускную способность системы;

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

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

  • простоту эксплуатации и поддержки системы;

  • необходимую безопасность.

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

Проектирование информационных систем охватывает три основные области:

  • проектирование объектов данных, которые будут реализованы в базе данных;

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

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

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

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

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

^ Объектами проектирования могут быть как отдельные элементы, так и комплексы, относящиеся к функциональной части ИС.

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

· По сферам деятельности(снабжение, производство, сбыт)

· По ресурсам ( трудовые, финансовые, информационные, материальные и т.д).

· По бизнес процессам

· По функциям управления (планирование, учет, контроль, регулирование и т.д.)

· Смешанная декомпозиция

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

^ Организационное обеспечение регламентирует структуру управления объектом в условиях применения ИС и распределение должностных обязанностей между пользователями системы.

^ Информационное обеспечение состоит из внемашинного и внутримашинного.

К внемашинному ИО относятся системы классификации и кодирования инф-ции, а также система документации.

К внутримашинному ИО относят БД, базы знаний, пользовательский интерфейс и т.д.

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

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

В состав проектной документации по созданию ИС входят следующие основные док-ты:

1. «технико –экономическое обоснование»(ТЭО). Целью разработки данного проекта является :

  • Обоснование состава функциональных задач

  • Требования к обеспечивающим подсистемам

  • Технологии проектирования

  • Ориентировочный расчет экономической эффективности




  1. Классификация ИС. Понятие ЖЦ.
^

Классификация по архитектуре


По степени распределённости отличают:

  • настольные (desktop), или локальные ИС, в которых все компоненты (БД, СУБД, клиентские приложения) находятся на одном компьютере;

  • распределённые (distributed) ИС, в которых компоненты распределены по нескольким компьютерам.

Распределённые ИС, в свою очередь, разделяют на:

В файл-серверных ИС база данных находится на файловом сервере, а СУБД и клиентские приложения находятся на рабочих станциях.

В клиент-серверных ИС база данных и СУБД находятся на сервере, а на рабочих станциях находятся клиентские приложения.

В свою очередь, клиент-серверные ИС разделяют на двухзвенные и многозвенные.

В двухзвенных (англ. two-tier) ИС всего два типа «звеньев»: сервер баз данных, на котором находятся БД и СУБД (back-end), и рабочие станции, на которых находятся клиентские приложения (front-end). Клиентские приложения обращаются к СУБД напрямую.

В многозвенных (англ. multi-tier) ИС добавляются промежуточные «звенья»: серверы приложений (application servers). Пользовательские клиентские приложения не обращаются к СУБД напрямую, они взаимодействуют с промежуточными звеньями. Типичный пример применения многозвенности — современные веб-приложения, использующие базы данных. В таких приложениях помимо звена СУБД и клиентского звена, выполняющегося в веб-браузере, имеется как минимум одно промежуточное звено — веб-сервер с соответствующим серверным программным обеспечением.
^

Классификация по степени автоматизации


По степени автоматизации ИС делятся на:

  • автоматизированные: информационные системы, в которых автоматизация может быть неполной (то есть требуется постоянное вмешательство персонала);

  • автоматические: информационные системы, в которых автоматизация является полной, то есть вмешательство персонала не требуется или требуется только эпизодически.
^

Классификация по характеру обработки данных


По характеру обработки данных ИС делятся на:

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

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

Классификация по сфере применения


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

Классификация по охвату задач (масштабности)


  • Персональная ИС предназначена для решения некоторого круга задач одного человека.

  • Групповая ИС ориентирована на коллективное использование информации членами рабочей группы или подразделения.

Корпоративная ИС в идеале охватывает все информационные процессы целого предприятия, достигая их полной согласованности, безызбыточности и прозрачности. Такие системы иногда называют системами комплексной автоматизации предприятия.


ЖЦПО - непрерывный процесс, который начинается с момента принятия решения о создании ПО и заканчивается полным изъятием его из эксплуатации

ЖЦ разделяется на этапы. Все этапы ЖЦ разделяются на 3 группы:

  • Основные процессы ЖЦ (приобретение, поставка, разработка, эксплуатация, сопровождение)

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

  • Организационные процессы (управление проектами, создание инфраструктуры проекта, улучшение самого ЖЦ, обучение).

Под моделью ЖЦ понимается структура определяющая последовательность выполнения этапов ЖЦ


^ Жизненный цикл информационной системы - это непрерывный процесс от ее «рождения» до «смерти». Включает в себя анализ (обследование объекта управления и/или существующей ИС), проектирование, реализация, испытания (тестирование), внедрение, сопровождение и утилизация.

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

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

Среди известных моделей жизненного цикла можно выделить следующие модели:

каскадная модель (до 70-х годов) - последовательный переход на следующий этап после завершения предыдущего:

итерационная модель (70 - 80-е годы) - с итерационными возвратами на предыдущие этапы после выполнения очередного этапа:

спиральная модель (80 - 90-е годы) - прототипная модель, предполагающая постепенное расширение прототипа ЭИС.

^ Каскадная модель жизненного цикла ИС.

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

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

^ Спиральная модель жизненного цикла ИС.

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

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

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


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

  • Каскадная модель. Переход на следующий этап означает полное завершение работ на предыдущем этапе.

  • Поэтапная модель с промежуточным контролем. Разработка ПО ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют уменьшить трудоемкость процесса разработки по сравнению с каскадной моделью; время жизни каждого из этапов растягивается на весь период разработки.

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

^ Каскадная модель

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

Этапы проекта в соответствии с каскадной моделью:

  • Формирование требований;

  • Проектирование;

  • Реализация;

  • Тестирование;

  • Внедрение;

  • Эксплуатация и сопровождение.

Преимущества:

  • Полная и согласованная документация на каждом этапе;

  • Легко определить сроки и затраты на проект.

Недостатки:

  • Большая длительность выполнения проекта

  • Трудоемкость

  • Запаздывание получения результатов

Спиральная модель

При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

  • риск превышения сроков и стоимости проекта;

  • необходимость выполнения ещё одной итерации;

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

  • целесообразность прекращения проекта.

Достоинства:

  • Макс. Удовлетворение требований заказчика

  • Возможность модифицирования проекта в процессе ЖЦ

Недостатки:

  • Сложность определения окончательных сроков выполнения

  • Определение момента перехода на новый этап




  1. Технологии проектирования ИС. Методы и средства проектирования ИС. Краткая характеристика применяемых технологий проектирования.

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

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

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

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

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

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

• технология должна способствовать росту производительности труда проектировщика;

• технология должна обеспечивать надежность процесса проектирования и эксплуатации проекта;

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

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


Технология проектирования ИС - это совокупность методологии и средств проектирования ИС, а также методов и средств организации проектирования (управление процессом создания и модернизации проекта ИС) - рис. 2.1.



Рис. 2.1. Состав компонентов технологии проектирования

технология проектирования задается регламентированной последовательностью технологических операций, выполняемых в процессе создания проекта на основе того или иного метода, в результате чего стало бы ясно, не только ЧТО должно быть сделано для создания проекта, но и КАК, КОМУ и в КАКОЙ ПОСЛЕДОВАТЕЛЬНОСТИ это должно быть сделано.

^ Методы и средства проектирования ИС

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

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


Методы проектирования ЭИС можно классифицировать по степени использования средств автоматизации, типовых проектных решений, адаптивности к предполагаемым изменениям.


Так, по степени автоматизации методы проектирования разделяются на методы:

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

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

^ По степени использования типовых проектных решений различают следующие методы проектирования:

• оригинального (индивидуального) проектирования, когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к ИС;

• типового проектирования, предполагающего конфигурацию ИС из готовых типовых проектных решений (программных модулей).

^ По степени адаптивности проектных решений методы проектирования классифицируются на методы:

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

• параметризации, когда проектные решения настраиваются (перегенерируются) в соответствии с изменяемыми параметрами;

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

Краткая характеристика применяемых технологий проектирования.


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

Индустриальная технология проектирования, в свою очередь, разбивается на два подкласса: автоматизированное (использование CASE-технологий) и типовое (параметрически-ориентированное или модельно-ориентированное) проектирование.

Использование индустриальных технологий проектирования не исключает использования в отдельных случаях канонической технологии.


Характеристики классов технологий проектирования


Класс технологии проектирования

Степень автоматизации

Степень типизации

Описание

Каноническое проектирование

Ручное проектирование

Оригинальное проектирование

Разработка ИС с нуля (ГОСТ 34.601-90)

Индустриальное автоматизированное проектирование

Компьютерное проектирование

Оригинальное проектирование

С использование CASE-средств.

Индустриальное типовое

проектирование

Компьютерное проектирование

Типовое сборочное проектирование

Адаптация некоторого стандартного решения в этой Предм. Обл. (шаблонное)


Средства проектирования должны быть:

• в своем классе инвариантными к объекту проектирования;

• охватывать в совокупности все этапы жизненного цикла ИС;

• технически, программно и информационно совместимыми;

• простыми в освоении и применении;

• экономически целесообразными

Средства проектирования ИС можно разделить на два класса:

без использования ЭВМ

с использованием ЭВМ

Все множество средств проектирования с использованием ЭВМ делят на четыре подкласса

  • К первому подклассу относятся операционные средства.

  • Ко второму подклассу относят средства, поддерживающие проектирование отдельных компонентов проекта ИС

  • К третьему подклассу относятся средства, поддерживающие проектирование разделов проекта ИС.

К четвертому подклассу средств проектирования ИС относятся средства, поддерживающие разработку проекта на стадиях и этапах процесса проектирования.

  • Современные CASE-средства, в свою очередь, классифицируются в основном по двум признакам:

  • 1) по охватываемым этапам процесса разработки ИС;

  • 2) по степени интегрированности: отдельные локальные средства (tools), набор не интегрированных средств, охватывающих большинство этапов разработки ИС (toolkit) и полностью интегрированные средства, связанные общей базой проектных данных - репозиторием (workbench).

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

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

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

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

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

  • • технология должна способствовать росту производительности труда проектировщика;

  • • технология должна обеспечивать надежность процесса проектирования и эксплуатации проекта;

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

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

Выбор технологии проектирования

В настоящее время имеется несколько типов технологий проектирования

  1. оригинальный

  2. типовой

  3. автоматизированный

  4. смешенный

Основными ограничениями при выборе технологии могут служить:

- наличие денежных средств на приобретение поддержку выбранной технологии

- ограничение во времени проектирования

- наличие специалистов соответствующей квалификации.

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

  1. ^ Каноническое проектирование ИС. Стадии и этапы процесса проектирования ИС. Понятие ТЗ.

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

В основе канонического проектирования лежит каскадная модель жизненного цикла ЭИС. Стадии создания» делится на следующие семь стадий: 1. исследование и обоснование создания системы: 2. разработка технического задания; 3. создание эскизного проекта; 4. техническое проектирование; 5. рабочее проектирование; 6. ввод в действие; 7. функционирование, сопровождение, модернизация.

На первой «Предпроектной стадии» принято выделять два основных этапа: сбор материалов обследования; анализ материалов обследования и разработка технико-экономического обоснования (ТЭО) и технического задания (ТЗ).

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

^ Вторая стадия «Технорабочее проектирование» выполняется в два этапа: техническое проектирование и рабочее проектирование. На этапе «Техническое проектирование» выполняются работы по логической разработке и выбору наилучших вариантов проектных решений, в результате чего создается «Технический проект». Этап «Рабочее проектирование» связан с физической реализацией выбранного варианта проекта и получением документации «Рабочего проекта». При наличии опыта проектирования эти этапы иногда объединяются в один, в результате выполнения которого получают «Технорабочий проект».

^ Третья стадия «Внедрение проекта» включает в себя три этапа: подготовка объекта к внедрению проекта; опытное внедрение проекта и сдача его в промышленную эксплуатацию. На этапе «Подготовка объекта к внедрению проекта» осуществляется комплекс работ по подготовке предприятия к внедрению разработанного проекта ЭИС. На этапе «Опытное внедрение» осуществляют проверку правильности работы некоторых частей проекта и получают исправленную проектную документацию и «Акт о проведении опытного внедрения». На этапе «Сдача проекта в промышленную эксплуатацию» осуществляют комплексную системную проверку всех частей проекта, в результате которой получают доработанный «Техно-рабочий проект» (Д3.1) и «Акт приемки проекта в промышленную эксплуатацию»

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


Стадии и этапы создания АС (ГОСТ 34.601-90)

  1. Формирование требований к АС

    1. Обследование объекта и обоснование необходимости создания АС

    2. Формирование требований пользователя к АС

    3. Оформление отчета о выполнении работ и заявки на разработку АС

  2. Разработка концепции АС

    1. Изучение объекта

    2. Проведение необходимых научно-исследовательских работ

    3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей

    4. Оформление отчета о проделанной работе

  3. Техническое задание

    1. Разработка и утверждение технического задания на создание АС

  4. Эскизный проект

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

    2. Разработка документации на АС и ее части

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

    1. Разработка проектных решений по системе и ее частям

    2. Разработка документации на АС и ее части

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

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

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

    1. Разработка рабочей документации на АС и ее части

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

  7. Ввод в действие

    1. Подготовка объекта автоматизации

    2. Подготовка персонала

    3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)

    4. Строительно-монтажные работы

    5. Пусконаладочные работы

    6. Проведение предварительных испытаний

    7. Проведение опытной эксплуатации

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

  8. Сопровождение АС.

    1. Выполнение работ в соответствии с гарантийными обязательствами

    2. Послегарантийное обслуживание


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

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

^ Техническое задание (ТЗ) определяет цели требования и основные исходные данные.

Задачи необходимые решить перед ТЗ:

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

- определить общие требования к проектируемой системе

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

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

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


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


^ Техническое задание (ГОСТ 34.602-89)

1. Общие положения.

ТЗ на АС является основным документом, определяющим требования и порядок создания АС.

ТЗ на АС разрабатывают на систему в целом, предназначенную для работы самостоятельно или в составе другой системы.

2. Состав и содержание.

2.1. ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

1) общие сведения;

2) назначение и цели создания (развития) системы;

3) характеристика объектов автоматизации;

4) требования к системе;

5) состав и содержание работ по созданию системы;

6) порядок контроля и приемки системы;

7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8) требования к документированию;

9) источники разработки.

^ 2.3. В разделе «Общие сведения» указывают:

1) полное наименование системы и ее условное обозначение;

2) шифр темы или шифр (номер) договора;

3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

5) плановые сроки начала и окончания работы по созданию системы;

6) сведения об источниках и порядке финансирования работ;

2.4. Раздел «Назначение и цели создания (развития) системы» состоит из подразделов:

2.4.1. В подразделе «Назначение системы» указывают перечень объектов автоматизации на которых предполагается ее использовать.

2.4.2. В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.

^ 2.5. В разделе «Характеристики объекта автоматизации» приводят:

1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

2) сведения об условиях эксплуатации объекта автоматизация и характеристиках окружающей среды.

^ 2.6. Раздел «Требования к системе» состоит из следующих подразделов:

1) требования к системе в целом;

2) требования к функциям (задачам), выполняемым системой;

3) требования к видам обеспечения.

2.7. Раздел «Состав и содержание работ по созданию (развитию) системы» должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 24.601, сроки их выполнения, перечень организаций — исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ.

^ 2.8. В разделе «Порядок контроля и приемки системы» указывают:

1) виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);

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

3) статус приемочной комиссии (государственная, межведомственная, ведомственная).

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

^ 2.10. В разделе «Требования к документированию» приводят:

1) согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и НТД отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации;

2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;

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

^ 2.11. В разделе «Источники разработки» должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

^ 2.12. В состав ТЗ на АС при наличии утвержденных методик включают приложения, содержащие:

а) расчет ожидаемой эффективности системы;

б) оценку научно-технического уровня системы.

Приложения включают в состав ТЗ на АС по согласованию между разработчиком и заказчиком системы.


  1. ^ Типовое проектирование ИС. Понятие типового элемента. Технологии параметрически-ориентированного и модельно-ориентированного проектирования.


Методы типового проектирования ЭИС предполагают создание системы из готовых типовых элементов (типовых проектных решений). Для реализации составных компонентов системы выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия.

Выделяют следующие классы ТПР:

· элементные ТПР – типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);

· подсистемные ТПР – в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;

· объектные ТПР – типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.

Каждое типовое решение предполагает наличие помимо функциональных решений еще и документации с детальным описанием типового проектного решения и процедур настройки. Достоинства и недостатки ТПР

Методы типового проектирования ИС предполагают создание системы из готовых покупных типовых элементов (типовых проектных решений).

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

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

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

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

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

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

Критерии оценки ППП делятся на следующие группы:

• назначение и возможности пакета;

• отличительные признаки и свойства пакета;

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

• документация пакета;

• факторы финансового порядка;

• особенности установки пакета;

^ Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации.

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

Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench).

Реализация типового проекта предусматривает выполнение следующих операций:

• установку глобальных параметров системы;

• задание структуры объекта автоматизации;

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

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

• описание интерфейсов;

• описание отчетов;

• настройку авторизации доступа;

• настройку системы архивирования.



  1. ^ Автоматизированное проектирование ИС с использованием CASE-технологии. Достоинства и недостатки.

Термин CASE (Computer Aided System/Software Engineering) используется в довольно широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. CASE – технологии применяются не только для автоматизации проектирования ИС, но и для разработки моделей бизнес-процессов при проведении бизнес-анализа. CASE – технологии применяются в ситуациях, когда проблематика предметной области отличается большой сложностью.

Можно выделить следующие основные принципы создания ИС на основе CASE – технологий:

1. принцип всесторонней компьютерной поддержки проектирования.

2. принцип модельного подхода. CASE – система может поддерживать методологию функционально –ориентированного или объектно-ориентированного подхода

3. принцип иерархического представления модели предметной области. Данный принцип выражается в возможности последовательной детализации (декомпозиции) описания системы в соответствии с нисходящим подходом проектирования.

4. принцип наглядности представления модели –означает наличие в составе CASE –технологий визуальных средств проектирования. Система графических изображения и правила, предназначенные для описания структуры системы, элементов данных и т.д., называются нотацией Case – средства.

5. принцип декомпозиции процесса ПИС с применением CASE –технологий на стадии и этапы.

Стадия 1. Анализ.

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

1.2 Разработка CASE-модели AS IS (как есть)

1.3 Разработка вариантов CASE -модели TO BE (как должно быть)

Стадия 2. Проектирование.

2.1Детализация иерархической модели ИС на основе функционально – ориентированного или объектно –ориентированного подхода

2.2 Разработка детализирующих моделей и диаграмм

Стадия 3. Программирование

Стадия 4. Внедрение.

6. принцип перенесение трудоемкости разработки на стадии анализа и проектирования

7. принцип независимости CASE -модели предметной области от средств реализации программирования. Благодаря соблюдению данного принципа имеется возможность переносить проектные решения с одной программы технической платформы на другую.

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

9. Наличие центрального компонента CASE -средства – репозитория, представляющего собой хранилище данных.


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

  • Методология определяет шаги и этапность реализации проекта, а также правила использования методов, с помощью которых разрабатывается проект.

  • Метод - это процедура или техника генерации описаний компонентов ИС (например, проектирование потоков и структур данных).

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

  • Инструментальные средства CASE - специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС.



^ Преимущества CASE-технологии по сравнению с традиционной технологией оригинального проектирования сводятся к следующему:

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

  • • возможность повторного использования компонентов разработки;

  • • поддержание адаптивности и сопровождения ИС;

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

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

  • • возможность коллективной разработки ЭИС в режиме реального времени.



  1. Функционально-ориентированный подход к созданию ИС. Стандарты проектирования.

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

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


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

Методология IDEF0 (второе название SADT – техника структурного анализа и проектирования) – это технология анализа системы в целом как набора связанных между собой действий или функций. (Основной блок Activity – действие, активность). Данная модель описывается вне рамок времени, т.е. это модель статического моделирования.

Можно моделировать состояние системы как оно есть (As-Is, т.е. можно сделать «снимок» системы и составить модель этого состояния) или составить модель системы с учетом того, как должно быть (To-Be).

Основные требования стандарта IDEF0

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

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

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

^ Методология IDEF3

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

Используя данную технологию можно строить диаграммы, которые называются Work Flow Diagraming – диаграммы потока работ.

Данный стандарт применяется:

  1. для улучшения понимания результатов моделирования;

  2. для сбора информации о схеме работы (компании).

^ Методология DFD

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

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

Графический язык диаграмм DFD.

Графический язык диаграмм DFD содержит следующие элементы:

  • внешние сущности

  • хранилища данных

  • процессы или работы

  • потоки данных

  • ссылка на другую страницу




  1. Объектно-ориентированный подход к созданию ИС. Стандарты проектирования

При объектно-ориентированном подходе система рассматривается как совокупность объектов, посылающих друг другу сообщения. Структура разрабатываемой системы представляется в терминах проблемной области. Разрабатываемая система легко модернизируется. Спроектированные и реализованные объекты могут использоваться в других системах, модифицироваться независимо от системы, для которой они были реализованы. Поэтому ООМ признана как одна из наиболее перспективных при разработке информационных систем на основе CASE-средств.

Объектно-ориентированный подход основан на объектной декомпозиции с описанием поведения системы в терминах взаимодействия объектов.

Преимущества объектно-ориентированного подхода:
^

  В отличие от структурного подхода объектно-ориентированный имеет ряд преимуществ:

· описание системы в виде объектов больше соответствует содержательному смыслу предметной области.

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

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


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

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

Стандарты IDEF1X – Информационное моделирование, IDEF4 – Объектно-ориентированное проектирование, UML, ARIS

. В настоящее время для объектно-ориентированного моделирования проблемной области широко используется унифицированный язык моделирования UML

UML— язык графического описания для объектного моделирования в области разработки программного обеспечения. UML использует графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем.

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

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

Структурные диаграммы:

Диаграмма классов, Диаграмма компонентов, Композитной/составной структуры, Диаграмма кооперации, Диаграмма развёртывания, Диаграмма объектов, Диаграмма пакетов, Диаграмма профилей (UML2.2)

Диаграммы поведения:

Диаграмма деятельности, Диаграмма состояний, Диаграмма прецедентов

Диаграммы взаимодействия:

Диаграмма коммуникации / Диаграмма кооперации, Диаграмма обзора взаимодействия, Диаграмма последовательности, Диаграмма синхронизации.

Похожие:

Проектирование информационной системы (ИС). Понятия и структура проекта ис iconПроектирование информационной системы (ИС). Понятия и структура проекта ис
Проектирование информационных систем всегда начинается с определения цели проекта. Основная задача любого успешного проекта заключается...
Проектирование информационной системы (ИС). Понятия и структура проекта ис iconВопросы для проведения зачета по дисциплине «Информационные технологии в менеджменте» Менеджмент – Финансовый менеджмент одо 2 курс (3 семестр)
Понятия корпорации, информационной системы, корпоративной информационной системы (кис)
Проектирование информационной системы (ИС). Понятия и структура проекта ис iconДисциплина «Проектирование информационных систем»
Приведите структуру автоматизированной экономической информационной системы (аэис)
Проектирование информационной системы (ИС). Понятия и структура проекта ис icon1. Социальная структура и ее исторические типы
«структура» прежде всего объединяются два таких термина, как элементы и взаимосвязь между этими элементами. Таким образом, можно...
Проектирование информационной системы (ИС). Понятия и структура проекта ис iconТехническое задание на проектирование системы: «Автоматизированная система управления инженерными системами» на объекте
Обеспечить контроль параметров системы электроснабжения объекта (параметры потребления)
Проектирование информационной системы (ИС). Понятия и структура проекта ис iconЛекция по дисциплине: «Социология» Тема Социальная структура общества и ее компоненты
Термин «структура» в переводе с лат означает строение, расположение, порядок. Социальная структура представляет собой совокупность...
Проектирование информационной системы (ИС). Понятия и структура проекта ис icon1. Понятие политики Структура и функции политики Границы политики в обществе
Ключевые понятия: политическая надстройка и экономический базис, стратификация, теория заинтересованных групп, субстанция, система,...
Проектирование информационной системы (ИС). Понятия и структура проекта ис iconЛекция Сопровождение информационной системе Группы задач сопровождения информационной системе
Ис может достигать 80% всех затрат жизненного цикла ис. В то же время задачи этапа сопровождения ис до настоящего времени остаются...
Проектирование информационной системы (ИС). Понятия и структура проекта ис iconМетодические указания для подготовки к экзамену и по выполнению курсового проекта «Проектирование и конструкция самолетов»
Задачей курсового проекта является разработка компоновки пассажирского самолета, определение его основных параметров и расчет летно-технических...
Проектирование информационной системы (ИС). Понятия и структура проекта ис iconАвтоматизированные системы стадии создания. Гост 34. 601-90
Настоящий стандарт распространяется на автоматизированные системы (АС), используемые в различных видах деятельности (исследование,...
Проектирование информационной системы (ИС). Понятия и структура проекта ис iconМетодические указания подготовлены на кафедре «Вычислительные машины и системы» ипредназначены для студентов специальности 230101 «Вычислительные машины, комплексы, системы и сети»
Даны варианты заданий на проектирование, рекомендации по выполнению курсовой работы. Рассматриваются вопросы обработки динамических...
Вы можете разместить ссылку на наш сайт:
Документы


При копировании материала укажите ссылку ©ignorik.ru 2015

контакты
Документы