Материал: 288

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

(ТПР), тиражируется и пригодно к многократному использованию. Каноническое проектирование отличает отражение ручной

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

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

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

1.2. Типовое проектирование информационных систем. Автоматизированное проектирование информационных систем (CASE-технологии)

Вопросы для рассмотрения: Понятие типового элемента. Технологии параметрически – ориентированного и модельноориентированного проектирования. Автоматизированное проектирование ИС с использованием CASE-технологии. Функциональноориентированный и объектно-ориентированный подходы.

Рекомендуемая литература: 1.

Перечень дополнительных ресурсов: 1, 2, 3, перечень ресурсов в сети Интернет.

Наименование вида самостоятельной работы: изучение ли-

тературы

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

Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию) проектное решение.

Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:

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

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

объектные ТПР — типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих

подсистем ИС.

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

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

Аббревиатура CASE (Computer-Aided Software Engineering –

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

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

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

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

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

1.3. Управление проектированием ИС. Состав и содержание работ по этапам жизненного цикла ПО. Содержание документации на программные средства. Организация документирования программных средств.

Вопросы для рассмотрения: Жизненный цикл управления проектом. Выбор системы управления проектами. Техническое задание, структура и содержание технического задания на разработку автоматизированной информационной системы по ГОСТ 34.602-89 и 19.201-78. Технологическая документация. Требования к документам. Процессы создания документов. Обязанности и ответственность специалистов за качество документов. Ресурсы для обеспечения создания документов высокого качества. Требования к качеству конкретных документов и способы его контроля.

Рекомендуемая литература: 1.

Перечень дополнительных ресурсов: 1, 2, перечень ресурсов в сети Интернет.

Наименование вида самостоятельной работы: изучение литературы, выполнение контрольной работы.

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

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

Процесс разработки включает следующие действия:

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

анализ требований к системе - определение ее функциональных возможностей, пользовательских требований, требований к надежности и безопасности, требований к внешним интерфейсам и т. д.;

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

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

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

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

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

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