3.3.2. Создание концепции новой ис

На основе результатов выполнения предпроектного обследования должна быть разработана концепция проекта новой или модернизация старой информационной системы, содержащая предложения и первичные формулировки целей дальнейшего проектирования и выработки общих требования к информационной системе. Работы по созданию концепции новой ИС регламентированы следующими нормативными документами: ГОСТ-34 (РД 50-34.698-90, приложение 1), ГОСТ Р ИСО/МЭК 12207-99 (пункты 5.3.2, 7.2, 7.1), ISO 9000-3 (пункт 5). Перечень и порядок работ может быть следующим:

1. Анализ предложений по усовершенствованию характеристик старой системы и первичное формулирование целей и требований к новой ИС.

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

3. Разработка предварительного описания характеристик внешней среды новой ИС.

4. Предварительное определение доступных ресурсов и ограничений проектирования новой ИС.

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

6. Разработка идеальной предварительной модели бизнес-процессов и функционирования новой ИС без учета реальных ограничений.

7. Разработка и документирование концепции и предложений по созданию новой ИС – целей, методов, требований и потенциальных решений без учета реальных ресурсов и ограничений.

Результатом каждой из этих работ является набор документов следующего содержания:

Результаты анализа предложений по характеристикам и первичные требования к новой ИС должны содержать:

• Обобщенные выводы и рекомендации по результатам обследования существующих бизнес-процессов и ИС.

• Сформулированные цели и задачи новых бизнес-процессов и ИС.

• Основные требования к бизнес-процессам и функциям новой ИС.

• Обоснование выбора перечня автоматизируемых функций и комплексов задач с оценкой очередности разработки и внедрения.

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

Предварительное описание постановки комплекса функциональных задач для проектирования новой ИС должно содержать разделы:

• Характеристики нового комплекса бизнес-процессов и ИС:

• назначение бизнес-процессов и комплекса задач новой ИС;

• использование функций и компонент унаследованной ИС;

• перечень объектов внешней среды, во взаимодействии с которыми должен решаться весь комплекс задач;

• связи данного комплекса задач с другими комплексами корпоративной информационной системы;

• предварительная оценка объема и содержания информации в базе данных;

• периодичность и продолжительность решения каждой задачи;

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

• Входная информация:

• источники информации и их идентификаторы;

• перечень и предварительное описание входных сообщений – объемы, формы представления, сроки и частота поступления;

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

• Выходная информация:

• получатели и назначение выходной информации;

• перечень и предварительное описание выходных сообщений;

• периодичность выдачи сообщений, допустимое время задержки решений.

Предварительное описание характеристик внешней среды новой или модернизированной ИС должно содержать:

• Перечень объектов внешней среды, взаимодействующих с новой ИС.

• Краткое описание характеристик объектов внешней среды.

Результаты предварительного анализа доступных ресурсов и ограничений проектирования ИС должны содержать оценки:

• Доступных финансовых затрат и их ограничений на весь процесс проектирования и на поддержку жизненного цикла ИС.

• Доступного коллектива специалистов и его квалификации для проектирования ИС.

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

• Характеристик доступных инструментальных средств для проектирования и поддержки ИС.

• Доступных ресурсов и специалистов для эксплуатации и развития ИС.

Предварительное технико-экономическое обоснование альтернативных вариантов ИС должно содержать:

• Ожидаемые экономические и социальные результаты реинжениринга бизнес-процессов и новой ИС:

• перечень основных источников экономической и социальной эффективности компании, получаемых в результате создания новой или модернизации старой ИС;

• предварительную оценку возможного количества и качества продукции и (или) социального эффекта.

• Оценку ожидаемых затрат на создание и эксплуатацию вариантов ИС с распределением их по очередям создания или по годам.

• Оценку ожидаемых затрат на переход с существующей на новую ИС.

• Ожидаемые во времени предварительные обобщенные показатели экономической эффективности вариантов ИС с учетом совокупных затрат на создание и внедрение.

• Оценку ожидаемых относительных изменений основных технико-экономических и социальных показателей и рентабельности совершенствования деятельности компании за счет разных вариантов новых бизнес-процесов и ИС

Предварительная идеальная модель бизнес-процесов новой ИС должна содержать:

• Результаты анализа объекта информатизации:

• перечень рекомендаций по функциям новой или модернизированной ИС;

• предварительные полные и непротиворечивые спецификации процессов новой ИС;

• первичный список требований к ИС.

• Идеальную модель потока событий в ИС с позиции пользователя:

• описание объектов-сущностей ИС, представляющих предметы и явления, явно фигурирующие в модели;

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

• описание управляющих объектов, координирующих поведение компонент системы;

• описание событийной модели.

• Графический прототип-модель, визуально демонстрирующую функционирование ИС:

• обобщенную структуру ИС, содержащую подсистемы, основные функции и важнейшие компоненты;

• краткое описание всех подсистем и компонент модели;

• описание каждой функции ИС, показывающее как компоненты участвуют в ее выполнении.

Отчет «Разработка и документирование концепции проектирования новой ИС» должен содержать:

• Описание результатов обследования и изучения бизнес-процессов и объекта информатизации.

• Описание и оценку преимуществ и недостатков разработанных альтернативных вариантов концепции реализации бизнес-процессов и создания новой ИС.

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

• Обоснование выбора оптимального варианта концепции и описание постановки задач ИС.

• Ожидаемые результаты и эффективность реализации выбранного варианта концепции ИС.

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

• Ориентировочный план реализации выбранного варианта концепции ИС.

• Ориентировочный перечень мероприятий, необходимых для перехода с существующей на новую ИС.

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

• Требования, гарантирующие необходимое качество, надежность функционирования и безопасность применения ИС.

• Принципы испытаний и приемки новой ИС.

• Первичную оценку целесообразности создания новой или модернизированной ИС и разработки системного проекта.

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

Одно из первых действий при проектировании – формирование требований к системе. При этом требование понимается как условие или характеристика, которым должна удовлетворять система. Изначально требования собираются в виде протоколов совещаний, семинаров, интервью. Затем они упорядочиваются и на их основе вырабатываются требования к функциональности системы и компонентам системы: базам данных, программным и техническим средствам. Существуют функциональные и нефункциональные требования. Функциональные требования определяют действия, которые должна выполнять система, без учета ограничений, связанных с ее реализацией. То есть функциональные требования определяют поведение системы и процесс обработки информации. Нефункциональные требования не определяют поведение системы, но описывают ее атрибуты или атрибуты системного окружения:

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

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

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

• Требования к надежности, которые обуславливают допустимую частоту и воздействие сбоев, а также возможности восстановления.

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

• Требования к ресурсам заказчика, то есть ограничения на финансовые, материальные, людские и другие ресурсы заказчика.

Многие, решаемые на этом этапе проектирования проблемы, относятся скорее не к задачам проектирования ИС, а к задачам управления проектами. Однако, именно на этом этапе при определении экономической эффективности необходимо рассмотреть проблемы так называемых «узких мест» информационной системы.

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

Рис. 24. Пример диаграммы активности системы

В приведенном примере явно видны 3 пика активности системы, максимальный из которых приходится на 11 часов. Использован тип диаграммы с накоплением.

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

Рис. 25. Еще один пример диаграммы активности системы

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

Более точно узкие места системы оцениваются на этапе разработки. Здесь уже есть реализованные компоненты системы. Средства автоматизации тестирования (например, LoadRunner, WinRunner и др.) позволяют отследить операции, которые выполняет то или иное приложение, автоматически сгенерировать сценарий запуска имитаторов работы реальных приложений и построить оценки узких мест системы.