Основные понятия методологии проектирования информационных систем
Цели и содержание методологии проектирования
Методология проектирования — это набор стандартизированных, проверенных и апробированных действий, позволяющих достичь нужного результата при создании информационной системы. В реальных условиях это скорее искусство, позволяющее в рамках ограничений создать систему, действительно удовлетворяющую потребностям пользователя.
Можно выделить три ключевых компонента методологии:
• Системный подход: любая сложная система, включая ИС, разделяется на более простые элементы для их раздельного решения с последующим формированием общего решения.
• Метод проектирования: методология описания предметной области и проекта ИС. Сюда входят структурный анализ, объектный анализ и построение моделей в соответствующих нотациях (языках описания).
• Технология проектирования: программные и инструментальные средства, поддерживающие выбранную методологию.
Информационная система как комплекс подсистем
Распространенная ошибка — рассматривать ИС только как программное средство. На самом деле это сложный комплекс, включающий ряд подсистем. Их выделение позволяет не упустить важные детали при проектировании.
Подсистемы, разрабатываемые командой проекта:
• Информационное обеспечение: совокупность методов и средств для ввода, кодирования и обработки информации с использованием классификаторов. Состоит из внемашинного и внутримашинного компонентов.
• Техническое обеспечение: комплекс технических средств, на которых будет работать ИС.
• Программное обеспечение: комплекс программ, настроенных на поддержку конкретных бизнес-процессов компании, а не просто «похожей деятельности».
• Организационное обеспечение: инструктивные и методические материалы, регламентирующие работу пользователей с системой (инструкции по подготовке данных, работе на местах, контролю информации и т.д.). Это технологические, а не юридические документы.
Подсистемы, предопределенные методологией компании-разработчика:
• Математическое обеспечение: все встроенные в систему модели и методы обработки данных.
• Лингвистическое обеспечение: все средства общения с системой и описания предметной области (например, язык
UML — Unified Modeling Language).
Эти подсистемы обычно уже заложены в типовые решения (1С, SAP, Microsoft Dynamics AX) или принятую в компании методологию. Разработчику остается их использовать, понимать и настраивать, а не менять в рамках отдельного проекта.
Особое место занимает
правовое обеспечение. Это комплекс юридических документов (приказов, распоряжений), определяющих, кто отвечает за подготовку и ввод информации, кто имеет право на получение документов и как их использовать. Без назначения ответственных лиц система не заработает. Разработчик не может ввести эти документы в действие, но его роль — подсказать заказчику, какие документы необходимы, опираясь на свой опыт запуска подобных систем.
Эволюция методов проектирования
Процессы разработки ИС прошли несколько этапов.
1. Метод «снизу вверх» («лоскутная автоматизация»)
На предприятии по очереди автоматизируются отдельные насущные задачи (бухгалтерия, кадры) разными людьми и на разных платформах. В результате возникает проблема интеграции: системы не могут обмениваться данными. Попытка их объединить часто оказывается дороже и сложнее, чем разработка новой единой системы. Пример — компания, где бухгалтерия работает на «Бест», а зарплата — на 1С, и для передачи данных используется сложный и ненадежный файловый обмен. Хотя метод повсеместно критикуется, он до сих пор используется из-за финансовых или иных ограничений.
2. Метод «сверху вниз»
Попытка создать универсальный продукт, проанализировав обобщенные потребности разных организаций. Такие системы (например, универсальный кадровый учет) стали коммерческими, но оказались недостаточно гибкими: их жесткие рамки не подходят всем пользователям, вынуждая покупателей дорабатывать, переделывать или менять систему.
3. Метод многокомпонентности (современный подход)
Система строится вокруг
ядра и набора настраиваемых функциональных модулей. Модули можно подключать поэтапно, и они уже взаимоувязаны по информационным структурам и алгоритмам. Это позволяет избежать проблем «лоскутной автоматизации», постепенно автоматизируя разные участки в рамках единой платформы.
Существует два подхода к проектированию:
• Каноническое проектирование: полный цикл от написания требований до разработки приложений и базы данных «с нуля».
• Проектирование на основе типового решения: настройка готового продукта под конкретные бизнес-процессы заказчика. Именно этот подход наиболее характерен для выпускников профильных специальностей и является основным в курсе. Процесс анализа требований для обоих подходов идет одинаково и расходится только на этапе физической реализации.
Технологии проектирования
Рассматриваются две технологии, отличающиеся методологией моделирования.
Технология, ориентированная на структурное моделирование (на примере «Дельтаран»):
Последовательность проектирования такова:
1.
Моделирование бизнес-процессов: описание деятельности компании.
2.
Описание потоков данных: какие данные и как циркулируют между процессами.
3.
Концептуальное моделирование данных: детальное описание информации, циркулирующей в системе.
4.
Описание архитектуры системы: выделение подсистем, решаемых задач и технологии использования (без привязки к конкретной реализации).
5.
Описание интерфейсов: как система будет взаимодействовать с пользователями в рамках новых бизнес-процессов.
Технология, ориентированная на объектно-ориентированное моделирование (RUP — Rational Unified Process):
Последовательность действий аналогична:
1.
Бизнес-моделирование: описание автоматизируемой деятельности.
2.
Формулирование требований к системе на основе бизнес-моделей.
3.
Описание структуры данных.
4.
Описание работы системы.
Ключевое отличие RUP — гораздо большее количество выразительных средств, моделей и типов диаграмм, позволяющих описать более тонкие аспекты функционирования системы. Выбор между структурным и объектным моделированием делается разработчиком для каждого проекта.
Жизненный цикл информационной системы и его модели
Последовательность шагов при использовании любой технологии проектирования укладывается в модель процесса, которая называется моделью
жизненного цикла (ЖЦ) ИС.
Определение: Жизненный цикл ИС — это весь период от возникновения идеи о создании системы до полного вывода ее из эксплуатации.
Для формального описания ЖЦ используются понятия:
• Стадия: качественное состояние системы (например, «проектирование», «внедрение»), не привязанное ко времени.
• Этап: четко определенная во времени часть ЖЦ.
• Процесс: группа работ, которые необходимо выполнить в рамках этапа или стадии.
Выделяют три основные модели ЖЦ:
1. Каскадная модель
Каждый этап работ (разработка требований, проектирование, реализация, тестирование) полностью завершается перед началом следующего. Результаты фиксируются и утверждаются документально.
•
Достоинства: возможность четкого планирования стоимости и сроков; легкая смена исполнителя на любом этапе; прозрачность процесса.
•
Недостаток: невозможность создания действительно сложных систем. Требования, зафиксированные на старте, неизбежно уточняются в процессе работы, что требует возврата на предыдущие этапы.
•
Область применения: была популярна в 1970-80-е годы, когда создавались относительно простые системы под четкие требования известных заказчиков небольшими командами программистов на универсальных языках (Pascal, Cobol, Fortran).
2. Поэтапная модель с промежуточным контролем
Допускает возвраты на любые предыдущие этапы для пересмотра и корректировки их результатов. Эта модель более гибкая и приближена к реальности.
•
Недостаток: жестко фиксирует общие временные и ресурсные рамки проекта, позволяя вносить лишь «косметические» изменения без их пересмотра.
3. Спиральная модель
Предусматривает итеративное наращивание представления о системе. Проект развивается по спирали: начальные требования → проектирование → тестирование → внедрение → уточнение требований на основе полученного опыта → новый цикл проектирования.
•
Ключевое отличие: цель — создание системы, соответствующей не формальным требованиям заказчика, а его реальным бизнес-потребностям.
•
Характеристика: требует использования сложных технологий проектирования и работы проектных команд с четко распределенными ролями.
Почему каскадная модель используется до сих пор, несмотря на ее недостатки?
1.
Привычка: многие IT-специалисты обучались по старым стандартам, ориентированным на каскадную модель.
2.
Иллюзия снижения рисков:
o
Для заказчика: кажется, что жесткие требования гарантируют результат в заданных сроках и бюджете.
o
Для разработчика: кажется, что четко оговоренные ТЗ и стоимость проекта — залог успешной работы. На практике к середине проекта обе стороны понимают, что требования устарели, и начинаются конфликты. Гораздо эффективнее изначально закладывать в договор возможность уточнения требований и ресурсов.
3.
Объективная необходимость: в системах с критически высокой ценой ошибки (управление АЭС, военные системы) пошаговая доработка («уточнение на следующем витке») невозможна. Такие системы сразу должны работать в полном объеме, что вынуждает использовать каскадный подход.
Стандартизация процессов проектирования
В 1970-е годы от бесплодных попыток стандартизировать сами системы перешли к стандартизации процессов их создания. Это оказалось действительно полезным.
Ключевые стандарты:
• ГОСТ 34-й серии (Россия): четко определяет стадии и этапы работ по созданию ИС, а также требования к составу и содержанию проектной документации.
o
Ценность для разработчика: управляет деятельностью, задавая понятную структуру работы через шаблоны итоговых документов.
o
Ценность для заказчика: позволяет уже на старте понимать, что и в каком виде он может требовать от исполнителя.
• ISO/IEC 12207: международный стандарт на процессы жизненного цикла программного обеспечения. Изначально ориентирован на создание программных продуктов, а не систем, поэтому слабо учитывает вопросы модификации бизнес-процессов.
• ISO/IEC 15288: международный стандарт на процессы жизненного цикла систем. Разработан как дополнение к 12207, лучше прорабатывает процессы запуска и эксплуатации сложных систем.
• Корпоративные методики: разрабатываются производителями ПО. Примеры:
o
Методика Oracle (Oracle Method): ориентирована на использование продуктов Oracle.
o
Rational Unified Process (RUP): разработка IBM, методически жестко привязана к объектному моделированию, но достаточно универсальна по отношению к ПО.
o
Microsoft Solutions Framework (MSF): универсальная методология от Microsoft, не привязанная к конкретному ПО или методу моделирования.
На практике компании редко используют какой-либо стандарт в чистом виде. Обычно формируется собственная методика, которая вбирает в себя полезные элементы из разных документов, исходя из специфики задач, используемого ПО и оргштатной структуры.
Общая черта всех стандартов и методик: они выделяют схожие стадии жизненного цикла, но наполняют их разным набором процессов и работ. Например, ISO 12207 выделяет три группы процессов (основные, вспомогательные, организационные), которые не привязаны к этапам жестко, а даны общим списком.
Краткие итоги
Материал формирует целостную картину дисциплины проектирования информационных систем, представляя ее не как техническую процедуру программирования, а как управленческое искусство по созданию сложного организационно-технического комплекса. Ключевой идеей является взгляд на ИС через призму ее подсистем. Такая декомпозиция — это не просто аналитический прием, а фундаментальный принцип, позволяющий четко разграничить зоны ответственности в проекте. Разработчик, понимая различие между организационным и правовым обеспечением, не пытается подменить волю заказчика в юридических вопросах, но консультирует его, опираясь на свой опыт — в этом проявляется зрелость проектной культуры.
Эволюция методов от «лоскутной автоматизации» к многокомпонентным системам — это история борьбы с хаосом и попытка найти баланс между уникальностью бизнеса и универсальностью тиражного ПО. В этом контексте раскрывается прагматичная роль специалиста по внедрению: его основная задача не создавать код с нуля (каноническое проектирование), а грамотно адаптировать готовое мощное ядро (ERP-систему) под неповторимую логику бизнес-процессов конкретного заказчика, настраивая и связывая функциональные модули.
Центральное место в управлении такой разработкой занимает выбор модели жизненного цикла. Анализ каскадной и спиральной моделей — это урок принятия решений в условиях риска. Осознание того, что выбор жесткой каскадной модели для сложного бизнес-проекта создает лишь иллюзию контроля, которая неизбежно разрушится на этапе внедрения, является маркером профессиональной зрелости. Понимание того, что заказчик не всегда знает свои истинные потребности на старте, превращает спиральную модель с ее итеративным уточнением требований не в прихоть, а в единственно разумную стратегию снижения реальных, а не мнимых рисков.
Наконец, обзор стандартов и корпоративных методик (ГОСТ, ISO, RUP, MSF) демонстрирует, что профессиональная деятельность не существует в вакууме. Стандарт — это, с одной стороны, скелет и каркас для управления, а с другой — язык взаимодействия с заказчиком, особенно с неспециалистом в IT, позволяющий последнему понять, что и когда он вправе требовать. Практическая ценность всех этих знаний заключается в умении сформировать на их стыке собственную, рабочую методику под конкретный проект, а не следовать догмам одного документа.
1. Проектирование ИС — это не только программирование, а искусство создания организационно-технического комплекса в условиях ограничений.
2. Системный подход требует делить ИС на подсистемы (информационную, техническую, программную, организационную и др.) для детального анализа и проектирования.
3. Распространенная ошибка — сводить ИС к программному коду, игнорируя другие обеспечивающие подсистемы, что ведет к ее неработоспособности.
4. Задача разработчика в правовом обеспечении — консультировать заказчика о необходимых приказах и регламентах, но сами юридические документы вводит в действие заказчик.
5. Организационное обеспечение (инструкции, методики работы) — зона ответственности разработчика, в отличие от правового.
6. «Лоскутная автоматизация» методом «снизу вверх» решает локальные задачи, но создает катастрофические проблемы при последующей интеграции данных.
7. Современный многокомпонентный подход позволяет собирать систему из настраиваемых модулей вокруг единого ядра, избегая проблем интеграции.
8. Специфика прикладной специальности — преимущественная работа с настройкой типовых решений, а не с полным циклом проектирования «с нуля».
9. Каскадная модель жизненного цикла создает лишь иллюзию контроля сроков и бюджета, так как требования к сложным системам неизбежно уточняются в процессе работы.
10. Спиральная модель нацелена на создание системы, соответствующей реальным бизнес-потребностям заказчика, а не его первоначальным формальным требованиям.
11. Каскадная модель остается объективно необходимой для систем сверхвысокой критичности (АЭС, военные), где итеративная доработка недопустима.
12. Стандарты (ГОСТ 34, ISO 15288) и корпоративные методики (RUP, MSF) служат каркасом для формирования собственной методики проектирования, а не догмой.
1. В чем заключается принципиальная разница между информационной системой как целым и ее программной составляющей?
2. Перечислите подсистемы ИС, за разработку которых напрямую отвечает команда проекта.
3. Почему подсистемы математического и лингвистического обеспечения обычно не разрабатываются в рамках конкретного проекта по внедрению?
4. Каковы роли разработчика и заказчика в создании и вводе в действие документов по правовому и организационному обеспечению?
5. Что такое «лоскутная автоматизация», почему она возникает и к каким негативным последствиям приводит на этапе интеграции систем?
6. В чем ключевое отличие метода «снизу вверх» от многокомпонентного подхода к построению информационной системы?
7. Чем отличается каноническое проектирование от проектирования на основе типового решения и какой подход более характерен для прикладной специальности?
8. Опишите логическую последовательность действий в технологиях проектирования, независимо от используемой методологии моделирования.
9. Сравните каскадную и спиральную модели жизненного цикла: назовите главное преимущество и главный недостаток каждой из них с практической точки зрения.
10. Назовите основные причины, по которым каскадная модель до сих пор применяется в реальных IT-проектах.
11. Для каких категорий проектов использование каскадной модели является не просто привычкой, а объективной необходимостью?
12. Чем международный стандарт ISO/IEC 15288 принципиально отличается от ISO/IEC 12207 с точки зрения объекта стандартизации?
