© Лысенко М.А., Осипов М.Г. (ЗАО "Кворум")
Статья была опубликована в журнале "Нефть и капитал"
(публикуется на сайте с согласия авторов)

Этап анализа и проектирования является определяющим при построении корпоративных информационных систем (КИС). В статье представлены современные методики анализа и проектирования при построении корпоративных информационных систем.

Введение в проблему

Еще в 70-е годы XX века были выделены этапы процесса разработки информационных систем - системный анализ и проектирование, разработка, кодирование, тестирование, внедрение. Если каждая последующая стадия вытекала из предыдущей, то говорили о каскадной модели (рис. 1).

Рис. 1. Каскадная модель разработки информационных систем.

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

Рис. 2. Итерационная модель разработки информационных систем.

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

В последовательности выработки требований заказчика по этапу системного анализа и проектирования выделяют три фазы [3]:

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

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

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

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

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

В [1] определены особенности, характерные для крупных проектов КИС. Это:

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

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

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

КИС как объект проектирования

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

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

Под бизнес-процессом будем понимать цепочку работ, которые заканчиваются значимым для клиента и/или организации результатом (рис. 3).

Рис. 3. Схематичное изображение бизнес-процесса.

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

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

Рис. 4. Группы бизнес-процессов организации.

В большинстве случаев основные бизнес-процессы в первом приближении идентичны для организаций, принадлежащих одной отрасли (например, нефтепереработка для НПЗ, продажи для торговых организаций), или вообще являются уникальными (например, трубопроводный транспорт нефти, транспорт газа). Для автоматизации таких процессов существуют отраслевые решения (например, SCADA системы диспетчерского управления, системы для химического производства, системы для транспортных организаций) или специально разработанные под заказ системы (например, система управления поставками газа).

Вспомогательные же бизнес-процессы практически идентичны на верхнем уровне абстракции во всех организациях (например, бухгалтерия, логистика, склад, кадры и т.п.), а существующие различия проявляются на нижних уровнях детализации. Такие бизнес-процессы очень хорошо изучены и формализованы. Существует большое количество систем для их автоматизации - от небольших узконаправленных систем (1С-бухгалтерия, БОСС-Кадровик и др.), до комплексных систем класса ERP (SAP/R3, Oracle Applications и др.).

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

Методы и средства проектирования КИС

Структурный метод

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

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

В структурном анализе используются такие методики, как:

Ё DFD (Data Flow Diagrams) - диаграммы потоков данных;
Ё IDEF0 (Icam DEFinition) - функциональные диаграммы.

Объектно-ориентированный метод

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

Объектно-ориентированный метод разработки программного обеспечения является преобладающим сейчас по той причине, что он продемонстрировал свою полезность при построении систем в самых разных предметных областях и для различных уровней сложности и масштаба. Кроме того, большинство современных языков программирования, инструментальных средств и операционных систем являются в той или иной мере объектно-ориентированными, а это дает веские основания судить о мире в терминах объектов [4].

Применение методов и средств проектирования КИС

Поскольку в построении модели предметной области кроме аналитиков на начальной стадии принимают участие эксперты предметной области (рис. 5), к применяемым моделям выдвигаются следующие требования:

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

Рис. 5. Участники процесса разработки модели предметной области.

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

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

Рис. 6. Структура модели предметной области.

Описание методологий анализа и проектирования приведено в большом количестве изданий и публикаций, и не представляет интереса приводить их еще раз. Остановимся подробнее на описании совместного применения языка UML и методики написания спецификаций прецедентов использования (юзкейсов-usecase), автором которой является Алистар Кобурн.

В конце 90-х годов XX века был разработан Унифицированный язык моделирования (Unified Modeling Language, UML), который является объектно-ориентированным графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль принадлежит программному обеспечению [5].

Несмотря на свои достоинства, UML всего лишь язык и является одной из составляющих процесса разработки программного обеспечения. Хотя UML не зависит от моделируемой реальности, лучше всего применять его, когда процесс моделирования основан на рассмотрении прецедентов использования и является итеративным и пошаговым, а сама система имеет четко выраженную архитектуру. Неоспоримой заслугой UML является введение понятия прецедента использования. "Экземпляр юзкейса (сценарий) это последовательность действий, выполняемых в системе, которые позволяют получить результат, наблюдаемый для актера этой системы, юзкейс определяется как совокупность всех своих сценариев" [6]. Однако, UML, вводя это понятие, не дает четких способов применения юзкейсов. Получается, что юзкейсы, интуитивно понятны аналитикам, но их применение в похожих ситуациях зачастую приводит к различным результатам.

В 1998 году была издана монография А. Кобурна "Эффективное написание юзкейсов" [6]. Реакция аудитории на нее была строго положительной и до сих пор в рейтингах электронных книжных магазинов эта работа получает отличные оценки.

Причина успеха объясняется тем, что была предложена строгая и логичная система применения юзкейсов; сформулировано новое определение юзкейса, предложена структура его текстового описания (спецификации). "Юзкейс определяет соглашение между заинтересованными лицами (стейкхолдерами - stakeholder) относительно поведения системы. Юзкейс описывает поведение системы в ответ на запрос со стороны одного из стейкхолдеров, который называется основным (primary) актером. Основой актер инициирует запрос для осуществления некоторой цели; система отвечает, защищая интересы своих стейкхолдеров. При этом могут реализоваться различные сценарии в зависимости от конкретного запроса и условий, в которых он был выполнен. Юзкейс объединяет все такие сценарии. Причем, написанный по структуре А. Кобурна юзкейс содержит в себе информацию, которую графически можно изобразить только на нескольких диаграммах, что сразу усложняет усвоение информации.

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

Необходимо обратить внимание на ключевую мысль, которая лейтмотивом проходит через всю книгу: "Написание юзкейсов фундаментально означает написание этюдов в прозе (в оригинале essays in prose) со всеми трудностями, которые присущи написанию хороших текстов в общем случае"[6].

Диаграммы юзкейсов языка UML при этом могут использоваться в качестве:

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

Продолжение

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме
Отправить ссылку на страницу по e-mail