Продуктовый ИТ-консалтинг

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

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

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

Основные стадии и этапы работ создания информационной системы

1. Формирование требований к ИС
2. Разработка концепции ИС
3. Техническое задание.
4. Эскизный проект.
5. Технический проект.
6. Рабочая документация.
7. Ввод в действие
8. Сопровождение ИС.

1. Методология быстрой разработки приложений (RAD).

Одним из возможных подходов к разработке ИС в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ИС, содержащий 3 элемента:

· небольшую команду программистов (от 2 до 10 человек);

· короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

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

Жизненный цикл АИС по методологии RAD состоит из четырех фаз:

· фаза анализа и планирования требований;

· фаза проектирования;

· фаза построения;

· фаза внедрения.

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

На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации.

После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:

· общая информационная модель системы;

· функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

· точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

· построенные прототипы экранов, отчетов, диалогов.

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

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

1. Современные технологии разработки многоуровневых ИС.

В процессе создания многоуровневой ЭИС выделяют логическое и физическое проектирование. Физическое проектирование рассматривает механизмы построения многоуровневых ЭИС, организацию аппаратного обеспечения и связано с рассмотрением процессов распределенного обмена между узлами сети и внутри узла, в том числе: где хранить информацию (данные), где её обрабатывать, какие данные и куда следует передавать. Решение этих задач включает реализацию методик распределения вычислительных работ по уровням обработки информации и узлам сети; распределения данных информационных массивов по узлам сети; определения количества компьютеров в узле. Для решения перечисленных задач могут быть использованы экономико-математические методы и модели, а также специальный инструментарий класса CASE.

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

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

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

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

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

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

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

Каждый уровень логической архитектуры многоуровневой ЭИС, характеризуется более сложным и комплексным абстрагированием по сравнению с нижележащим уровнем; наличием формальных и явных интерфейсов между этими уровнями, обеспечивающих при обращении к нижележащему уровню активизацию более детального поведения; присутствием внутри каждого уровня некоторых свойств, отражающих особенности функционирования данного уровня, скрытых, и недоступных для других уровней. То есть трехуровневая архитектура обеспечивает защиту каждого из уровней от конкретных деталей, содержащихся в нижележащем уровне. Например, уровень “бизнесправила ” защищен концептуально и механически от уровня “хранилище данных”, где осуществляется управление базой данных. Наиболее детальным является уровень “хранилище данных”, на более высоком уровне абстракции располагается уровень “бизнес правила” и, наконец, наивысший уровень абстрагирования представляет собой уровень “документы”, с которым в своей повседневной работе ежедневно соприкасаются пользователи ЭИС, даже не подозревая о наличии нижележащих уровней и сложностях в организации этих уровней.