МОДЕЛИ ПРОЕКТИРОВАНИЯ ЖИЗНЕННОГО ЦИКЛА СИСТЕМЫ УПРАВЛЕНИЯ.

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

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

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

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

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

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

 

ОБЩИЕ ТРЕБОВАНИЯ К МЕТОДОЛОГИИ РАЗРАБОТКИ.

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

Технология проектирования определяется как совокупность трех составляющих:

· пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис. 1.4);

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

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

Рис. 1.4. Представление технологической операции проектирования

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованям:

· технология должна поддерживать полный ЖЦ ПО;

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

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

· технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;

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

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

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

· технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ. Общий подход к оценке и выбору CASE-средств описан в разделе 4, примеры комплексов CASE-средств - в подразделе 5.7.

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

· стандарт проектирования;

· стандарт оформления проектной документации;

· стандарт пользовательского интерфейса.

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

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

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

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

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

Стандарт оформления проектной документации должен устанавливать:

· комплектность, состав и структуру документации на каждой стадии проектирования;

· требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),

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

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

· требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

· правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

· правила использования клавиатуры и мыши;

· правила оформления текстов помощи;

· перечень стандартных сообщений;

· правила обработки реакции пользователя.

Анализ является первым этапом создания ИС, на котором требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта.

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

· внешние условия работы системы;

· функциональная структура системы;

· распределение функций между человеком и системой, интерфейсы;

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

· условия эксплуатации.

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

32. СТРУКТУРНЫЙ ПОХОД К ПРОЕКТИРОВАНИЮ СИСТЕМЫ УПРАВЛЕНИЯ.

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

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

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

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

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

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

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

⇐ Предыдущая10111213141516171819Следующая ⇒

Поделиться: