|
1. Общая характеристика
работы
Актуальность данной темы заключается в
нехватке на отечественных предприятиях, в основном металлургических
комбинатах, систем контроля и отслеживания процессов нагревательных
процессов, протекающих в доменных печах. Существующие подобные зарубежные
системы очень дороги и они не полностью адаптированы под отечественное
производство в отличие от системы, которую я разрабатываю.
Тенденции развития современных информационных технологий
приводят к постоянному возрастанию сложности информационных систем (ИС),
создаваемых в различных областях экономики. Современные крупные проекты
ИС характеризуются, как правило, следующими особенностями:
сложность описания (достаточно большое количество функций, процессов,
элементов данных и сложные взаимосвязи между ними), требующая тщательного
моделирования и анализа данных и процессов;
наличие совокупности тесно взаимодействующих компонентов (подсистем),
имеющих свои локальные задачи и цели функционирования (например, традиционных
приложений, связанных с обработкой транзакций и решением регламентных
задач, и приложений аналитической обработки (поддержки принятия решений),
использующих нерегламентированные запросы к данным большого объема);
отсутствие прямых аналогов, ограничивающее возможность использования
каких-либо типовых проектных решений и прикладных систем;
необходимость интеграции существующих и вновь разрабатываемых приложений;
функционирование в неоднородной среде на нескольких аппаратных платформах;
разобщенность и разнородность отдельных групп разработчиков по уровню
квалификации и сложившимся традициям использования тех или иных инструментальных
средств;
существенная временная протяженность проекта, обусловленная, с одной
стороны, ограниченными возможностями коллектива разработчиков, и,
с другой стороны, масштабами организации-заказчика и различной степенью
готовности отдельных ее подразделений к внедрению ИС.
2. Содержание работы
Для успешной реализации проекта объект проектирования
(ИС) должен быть прежде всего адекватно описан, должны быть построены
полные и непротиворечивые функциональные и информационные модели ИС.
Накопленный к настоящему времени опыт проектирования ИС показывает,
что это логически сложная, трудоемкая и длительная по времени работа,
требующая высокой квалификации участвующих в ней специалистов. Однако
до недавнего времени проектирование ИС выполнялось в основном на интуитивном
уровне с применением неформализованных методов, основанных на искусстве,
практическом опыте, экспертных оценках и дорогостоящих экспериментальных
проверках качества функционирования ИС. Кроме того, в процессе создания
и функционирования ИС информационные потребности пользователей могут
изменяться или уточняться, что еще более усложняет разработку и сопровождение
таких систем. В 70-х и 80-х годах при разработке ИС достаточно широко
применялась структурная методология, предоставляющая в распоряжение
разработчиков строгие формализованные методы описания ИС и принимаемых
технических решений. Она основана на наглядной графической технике:
для описания различного рода моделей ИС используются схемы и диаграммы.
Наглядность и строгость средств структурного анализа позволяла разработчикам
и будущим пользователям системы с самого начала неформально участвовать
в ее создании, обсуждать и закреплять понимание основных технических
решений. Однако, широкое применение этой методологии и следование ее
рекомендациям при разработке конкретных ИС встречалось достаточно редко,
поскольку при неавтоматизированной (ручной) разработке это практически
невозможно. Действительно, вручную очень трудно разработать и графически
представить строгие формальные спецификации системы, проверить их на
полноту и непротиворечивость, и тем более изменить. Если все же удается
создать строгую систему проектных документов, то ее переработка при
появлении серьезных изменений практически неосуществима. Ручная разработка
обычно порождала следующие проблемы:
неадекватная спецификация требований;
неспособность обнаруживать ошибки в проектных решениях;
низкое качество документации, снижающее эксплуатационные качества;
затяжной цикл и неудовлетворительные результаты тестирования.
С другой стороны, разработчики ИС исторически всегда стояли последними
в ряду тех, кто использовал компьютерные технологии для повышения качества,
надежности и производительности в своей собственной работе.
Перечисленные факторы способствовали появлению программно-технологических
средств специального класса - CASE-средств, реализующих CASE-технологию
создания и сопровождения ИС.
Обзор технологии проектирования программного обеспечения. Технология
- CASE
Термин CASE (Computer Aided Software Engineering)
используется в настоящее время в весьма широком смысле. Первоначальное
значение термина CASE, ограниченное вопросами автоматизации разработки
только лишь программного обеспечения (ПО), в настоящее время приобрело
новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь
под термином CASE-средства понимаются программные средства, поддерживающие
процессы создания и сопровождения ИС, включая анализ и формулировку
требований, проектирование прикладного ПО (приложений) и баз данных,
генерацию кода, тестирование, документирование, обеспечение качества,
конфигурационное управление и управление проектом, а также другие процессы.
CASE-средства вместе с системным ПО и техническими средствами образуют
полную среду разработки ИС. Появлению CASE-технологии и CASE-средств
предшествовали исследования в области методологии программирования.
Программирование обрело черты системного подхода с разработкой и внедрением
языков высокого уровня, методов структурного и модульного программирования,
языков проектирования и средств их поддержки, формальных и неформальных
языков описаний системных требований и спецификаций и т.д. Кроме того,
появлению CASE-технологии способствовали и такие факторы, как:
подготовка аналитиков и программистов, восприимчивых к концепциям
модульного и структурного программирования;-
широкое внедрение и постоянный рост производительности компьютеров,
позволившие использовать эффективные графические средства и автоматизировать
большинство этапов проектирования;
внедрение сетевой технологии, предоставившей возможность объединения
усилий отдельных исполнителей в единый процесс проектирования путем
использования разделяемой базы данных, содержащей необходимую информацию
о проекте.
CASE-технология представляет собой методологию проектирования ИС, а
также набор инструментальных средств, позволяющих в наглядной форме
моделировать предметную область, анализировать эту модель на всех этапах
разработки и сопровождения ИС и разрабатывать приложения в соответствии
с информационными потребностями пользователей. Большинство существующих
CASE-средств основано на методологиях структурного (в основном) или
объектно-ориентированного анализа и проектирования, использующих спецификации
в виде диаграмм или текстов для описания внешних требований, связей
между моделями системы, динамики поведения системы и архитектуры программных
средств.
Согласно обзору передовых технологий (Survey of Advanced Technology),
составленному фирмой Systems Development Inc. в 1996 г. по результатам
анкетирования более 1000 американских фирм, CASE-технология в настоящее
время попала в разряд наиболее стабильных информационных технологий
(ее использовала половина всех опрошенных пользователей более чем в
трети своих проектов, из них 85% завершились успешно). Однако, несмотря
на все потенциальные возможности CASE-средств, существует множество
примеров их неудачного внедрения, в результате которых CASE-средства
становятся "полочным" ПО (shelfware). В связи с этим необходимо
отметить следующее: CASE-средства не обязательно дают немедленный эффект;
он может быть получен только спустя какое-то время; реальные затраты
на внедрение CASE-средств обычно намного превышают затраты на их приобретение;
CASE-средства обеспечивают возможности для получения существенной выгоды
только после успешного завершения процесса их внедрения. Ввиду разнообразной
природы CASE-средств было бы ошибочно делать какие-либо безоговорочные
утверждения относительно реального удовлетворения тех или иных ожиданий
от их внедрения. Можно перечислить следующие факторы, усложняющие определение
возможного эффекта от использования CASE-средств: широкое разнообразие
качества и возможностей CASE-средств; относительно небольшое время использования
CASE-средств в различных организациях и недостаток опыта их применения;
широкое разнообразие в практике внедрения различных организаций; отсутствие
детальных метрик и данных для уже выполненных и текущих проектов; широкий
диапазон предметных областей проектов; различная степень интеграции
CASE-средств в различных проектах. Вследствие этих сложностей доступная
информация о реальных внедрениях крайне ограничена и противоречива.
Она зависит от типа средств, характеристик проектов, уровня сопровождения
и опыта пользователей. Некоторые аналитики полагают, что реальная выгода
от использования некоторых типов CASE-средств может быть получена только
после одно- или двухлетнего опыта. Другие полагают, что воздействие
может реально проявиться в фазе эксплуатации жизненного цикла ИС, когда
технологические улучшения могут привести к снижению эксплуатационных
затрат.
Модели жизненного цикла ПО
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки
ПО (под моделью ЖЦ понимается структура, определяющая последовательность
выполнения и взаимосвязи процессов, действий и задач, выполняемых на
протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий,
в которых последняя создается и функционирует). Его регламенты являются
общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт
ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует
в деталях, как реализовать или выполнить действия и задачи, включенные
в эти процессы.
К настоящему времени наибольшее распространение получили следующие две
основные модели ЖЦ:
" каскадная модель (70-85 г.г.);
" спиральная модель (86-90 г.г.).
В изначально существовавших однородных ИС каждое приложение представляло
собой единое целое. Для разработки такого типа приложений применялся
каскадный способ. Его основной характеристикой является разбиение всей
разработки на этапы, причем переход с одного этапа на следующий происходит
только после того, как будет полностью завершена работа на текущем (рис.
1). Каждый этап завершается выпуском полного комплекта документации,
достаточной для того, чтобы разработка могла быть продолжена другой
командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем:
на каждом этапе формируется законченный набор проектной документации,
отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют планировать
сроки завершения всех работ и соответствующие затраты.
Рис. 1 Каскадная схема разработки ПО
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых
в самом начале разработки можно достаточно точно и полно сформулировать
все требования, с тем чтобы предоставить разработчикам свободу реализовать
их как можно лучше с технической точки зрения. В эту категорию попадают
сложные расчетные системы, системы реального времени и другие подобные
задачи. Однако, в процессе использования этого подхода обнаружился ряд
его недостатков, вызванных прежде всего тем, что реальный процесс создания
ПО никогда полностью не укладывался в такую жесткую схему. В процессе
создания ПО постоянно возникала потребность в возврате к предыдущим
этапам и уточнении или пересмотре ранее принятых решений. В результате
реальный процесс создания ПО принимал следующий вид (рис. 2):
Основным недостатком каскадного подхода является существенное запаздывание
с получением результатов. Согласование результатов с пользователями
производится только в точках, планируемых после завершения каждого этапа
работ, требования к ИС "заморожены" в виде технического задания
на все время ее создания. Таким образом, пользователи могут внести свои
замечания только после того, как работа над системой будет полностью
завершена. В случае неточного изложения требований или их изменения
в течение длительного периода создания ПО, пользователи получают систему,
не удовлетворяющую их потребностям. Модели (как функциональные, так
и информационные) автоматизируемого объекта могут устареть одновременно
с их утверждением.
Рис. 2. Реальный процесс разработки ПО по каскадной схеме
Для преодоления перечисленных проблем была предложена спиральная модель
ЖЦ [5] (рис. 3), делающая упор на начальные этапы ЖЦ: анализ и проектирование.
На этих этапах реализуемость технических решений проверяется путем создания
прототипов. Каждый виток спирали соответствует созданию фрагмента или
версии ПО, на нем уточняются цели и характеристики проекта, определяется
его качество и планируются работы следующего витка спирали. Таким образом
углубляются и последовательно конкретизируются детали проекта и в результате
выбирается обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл
создания системы. Неполное завершение работ на каждом этапе позволяет
переходить на следующий этап, не дожидаясь полного завершения работы
на текущем. При итеративном способе разработки недостающую работу можно
будет выполнить на следующей итерации. Главная же задача - как можно
быстрее показать пользователям системы работоспособный продукт, тем
самым активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла - определение момента перехода на
следующий этап. Для ее решения необходимо ввести временные ограничения
на каждый из этапов жизненного цикла. Переход осуществляется в соответствии
с планом, даже если не вся запланированная работа закончена. План составляется
на основе статистических данных, полученных в предыдущих проектах, и
личного опыта разработчиков.
Рис 3. Спиральная модель ЖЦ
3.
Основные результаты
Внедрение на предприятие разрабатываемой системы означает
то, что данные от средств промышленной автоматики могут быть собраны
без использования специальных драйверов. Информация затем может быть
распространена между неограниченным числом разных пользователей по всему
предприятию.
Преимущества для бизнеса состоит в том , что:
• может использоваться для быстрого создания, как неотъемлемой
части автоматизации критически важных процессов промышленного производства.
Improves the efficiency and productivity of manufacturing and automation
processes.
• дает возможность персоналу по всему предприятию получать
информацию, необходимую для принятия решений
• обеспечивает возможность предоставления объективной
информацией системам вышестоящего уровня управления: системе управления
производством - Manufacturing Execution Systems (MES), и системе планирование
ресурсов предприятия - Enterprise Resource Planning (ERP).
• уникальная масштабируемость к объему приложения и
архитектуре компьютера
4. Список литературы
1. Зиндер Е.З. "Бизнес-реинжиниринг
и технологии системного проектирования." Учебное пособие. М., Центр
Информационных Технологий, 1996
2. "Международные стандарты, поддерживающие жизненный цикл программных
средств". М., МП "Экономика", 1996
3. www.CitForum.ru А.М. Вендров, "CASE-технологии.
Современные методы и средства проектирования информационных систем".
4. Мазурин А. "CASE - средства для автоматизации инженерной деятельности."
"САПР и Графика" 2001 №2.
|