Составляющие технологии
CASE-технология состоит из трех групп частных стандартов, называемых, как уже говорилось выше, моделями. Каждая из моделей обзорно представлена ниже.
Модель команды
Разработка программного обеспечения, кроме сложного технического аспекта, имеет сложный организационный или даже психологический аспект, особенно при разработке больших систем. Известно, например, что потребности заказчика всегда сложно определить полностью в начальные моменты разработки и даже после обследования. Это влечет за собой большое количество незапланированных работ и отрицательно сказывается на качестве продукта. Проблема в людях, в том, как построить отношения с учетом интересов обеих сторон и без потери качества.
Модель команды позволяет эффективно организовать работу команды разработчиков. Она четко определяет роли участников команды. Каждый участник знает, что, когда и как ему необходимо делать.
Стандарт на проектную команду включает в себя методическое обеспечение — набор описаний на каждую роль, включая инструкции, описания обязанностей, описания требований к роли, взаимосвязей ролевых участников в рамках проекта по стандарту процесса и т. п.
Не вдаваясь в детали, заострим внимание на том, что команда определяется тремя независимыми сторонами (людьми или группами людей):
стороной заказчика;
стороной разработчика;
стороной качества.
Сторона заказчика следит за интересами заказчика, сюда включаются и представители заказчика. Сторона разработчика состоит из представителей разработчика и работает на его интересы. Сторона качества тоже выделяется из специалистов разработчика, но из тех, кто непосредственно не участвует в прикладном проекте. Сторона качества следит за правильностью применения технологии, за адекватностью моделей, контролирует соблюдение требований к ИС.
Модель процесса
Модель процесса позволяет эффективно организовать процесс создания ИС. Модель процесса — это совокупность стандартов уровня предприятия, которые зафиксированы в методическом обеспечении технологии. Методическое обеспечение представляет собой комплекс методик, определяющих выполняемые процессы на всех этапах жизненного цикла. Данная модель на методическом уровне тесно связана с моделью команды. Инструментально процесс поддержан промышленной CASE-средой, используемой практически на всех этапах в качестве единой рабочей среды проектной команды для фиксации всех анализируемых бизнес-процессов и проектных решений, генерации кода и документации, сборки дистрибутива и развертывания приложений ИС.
Процесс разработки определяется как спиральный (внесение изменений только через модель) и сквозной (обеспечивается единство и соответствие друг другу модели, структуры базы данных и исходного кода системы, осуществляется также контроль за внесением изменений в исходный код).
Процесс включает следующие этапы:
анализ системы «как есть»;
анализ системы «как требуется»;
объектный дизайн (создаются формальные модели, с которых осуществляется генерация исходного кода);
генерация исходного кода системы (по прошествии этого этапа систему уже можно запустить и даже установить заказчику для обучения или использовать для прототипирования или дальнейшей экспертной оценки);
реализация бизнес-логики системы;
тестирование системы;
сборка дистрибутива системы;
развертывание.
Основное внимание уделяется этапу анализа. Это очевидно: поскольку система должна автоматизировать предмет, ее необходимо предметно спроектировать. Аналитик создает модель системы в терминах предметной области. Используется язык UML, методология OMT и промышленная CASE-среда Telelogic Tau UML Suite.
На этапе объектного дизайна модель уточняется, дорабатывается и приводится к формальному виду. После этого модель готова к генерации кода. Обратим внимание, что объектный дизайн выполняется по предметной области, а технологическая проработка системы не выполняется, так как реализационная архитектура системы задана изначально благодаря наличию стандарта на приложение и мощному инструментальному ядру.
Этапы анализа и объектного дизайна — самые продолжительные по времени. Генерация кода является самым коротким этапом. Экспериментально установлено, что на реальной системе (например, управление торговлей) методом генерации можно получить примерно 85% всего кода. Хотя это не определяет полностью реальную сложность и трудоемкость доработки системы, но характеризует, сколько времени разработчика экономит технология за счет стандарта на приложение. Генерируется код COM-компонентов для Microsoft Visual Basic и сценарии создания БД для СУБД Microsoft SQL Server или Oracle. Отметим, что генерируется код для всех уровней приложений ИС. Архитектура приложений задается моделью приложения, о которой речь пойдет ниже.
В рамках процесса доработки исходного кода осуществляется контроль внесения изменений в исходные тексты системы, при этом кодирование, проводимое разработчиками, также стандартизовано, что ведет к качественному исходному коду.
Последними идут этапы сборки дистрибутива системы и ее развертывание у заказчика, обучение пользователей и обслуживающего персонала системы. Все перечисленные этапы достаточно определены и стандартизованы.
Следует заметить, что между этапами «Анализ системы ‘как есть’» и «Анализ системы ‘как требуется’» можно провести реинжиниринг бизнес-процессов, поручив этот этап консалтинговой компании и передав ей модель ИС в виде документов, содержащих текстовые описания, диаграммы UML, прототип системы.
Разумеется, наличие модели процесса повышает качество ИС.