Тема 12. Построение информационной системы поддержки (ИСП)

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

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

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

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

Наиболее важные участники разработки информационной системы поддержки - заказчики и пользователи. В контексте реинжиниринга бизнес-процессов заказчики являются одновременно владельцами бизнес-процессов, а пользователи информационной системы - участниками этих процессов. Как правило, их не интересует, как будет реализована информационная система. Для них самое важное - то, что система сможет делать и как ее использовать. Для них необходимо разработать различные сценарии использования системы. Эти сценарии должны быть представлены в терминах П-модели. Субъекты в таких моделях отражают разнообразные роли, которые могут играть участники бизнес-процессов и пользователи информационной системы.

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

Проектировщикам (их также именуют программистами) в отличие от аналитиков нужны модели, позволяющие описывать различные способы выполнения системы вплоть до создания программного кода. Они нуждаются в реальной объектной модели, представляющей собой некоторую абстракцию программного кода. Реальная объектная модель необходима также специалистам, которые тестируют готовые программы. В этой модели принимаются во внимание такие важные технические аспекты как среда разработки (язык реализации, доступные вычислительные ресурсы, используемая СУБД и т.д.) и ее ограничения. Результатом проектирования приложения являются исходные тексты программ, которые образуют модель реализации системы.

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

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

Рис.12.1. Основные этапы разработки программного обеспечения

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

2. Анализ требований. Цель этого этапа состоит в проверке полноты и непротиворечивости спецификации требований. Далее строится П-модель информационной системы. На этом этапе может быть разработан прототип графического интерфейса пользователя. Результатом этапа является П-модель информационной системы, включающая прецеденты, субъекты и описание интерфейсов конечного пользователя.

3. Идеальное проектирование. Предназначено для построения гибкой структуры информационной системы, обеспечивающей простоту ее модификации. Результатом является идеальная объектная модель системы.

4. Реальное проектирование. Здесь разрабатывается модель (блок-схема), служащая базисом для реализации информационной системы. Результат - реальная объектная модель информационной системы.

5. Реализация. На этом этапе создается программный код информационной системы.

6. Тестирование. Проверяется соответствие информационной системы предъявляемым к ней требованиям. Результатом этого этапа должны быть корректные результаты прогона системы на тестовых задачах.

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

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

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

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

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

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

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

Основной характеристикой "водопадного" (или «каскадного» - «waterflow») процесса является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

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

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

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

В реальной жизни оказывается, что на стадии формулировки требований заказчик не может точно определить все требования к программному продукту.

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

Спиральная модель разработки ПО, в тех или иных версиях используемая во множестве конкретных прикладных методик, построена на следующем шаблоне.

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

Формируется план, начинаются работы и отслеживается их выполнение.