«Гусарова Н.Ф. МЕТОДОЛОГИЯ ОРГАНИЗАЦИИ ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ Учебное пособие Санкт-Петербург 2012 Предисловие Настоящее учебное пособие составлено в соответствии с рабочей программой ...»

Рис. 2.5. Регистрация рабочего элемента Требование Рис. 2.6. Связывание Тестового сценария с Рабочим элементом Рис. 2.7. Назначение рабочего элемента Возможность Рис. 2.8. Организация ссылок рабочих элементов (Возможность и Тестовый сценарий) друг на друга Рис. 2.9. Спецификация системных требований Предусмотренные типы связей позволяют визуализировать иерархию требования как родительский дочерний дочерний и т.д. рабочий элемент в представлении выборки рабочих элементов в виде дерева иерархии.

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

В качестве другого примера можно привести корпоративную разработку компании LUXOFT [LUXOFT] в части поддержки управления требованиями. Общая концепция системы LUXproject представлена на рис. 2.10.

Рис. 2.10. Концепция системы управления проектом LUXproject В части управления требованиями система обеспечивает:

единый репозиторий требований;

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

трассируемость требований – от бизнес-требований к функциональным требованиям, от требований через задачи к коду и дефектам;

доступ к централизованному хранилищу документов;

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

визуализация изменений в исходном коде;

отражение текущего статуса сборок;

доступ к статистическим данным по дефектам;

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

Предлагаются также альтернативные системы управления требованиями, например, построенные на связке Confluence + Jira + SVN [связка], где:

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

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

Subversion, также известная как «SVN» – свободная централизованная система управления версиями.

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

2.11–2.20. Возможно визуальное оформление требований (средства оформления текста типа rich text, проверка орфографии, иллюстрации, таблицы, возможность приложения файлов и т. п.). Поддерживается удаленная работа с требованиями.

Рис. 2.11. Формирование структуры требований с произвольным уровнем вложенности Рис. 2.12. Фиксирование исходных и возникающих требований Рис. 2.13. Автоматическое связывание требований между собой (трассировка), в том числе межпроектных Рис. 2.14. Автоматическое связывание требований с заданиями на работы в инструменте планирования; контроль хода выполнения задач и отображение реализованных требований Рис. 2.15. Определение необходимых типов требований и атрибутов для них (приоритет, сложность, состояние, ответственный за реализацию и др.) Рис. 2.16. Генерация актуального технического задания по текущей структуре требований Рис. 2.17. Интеграция со средой разработки (Integrated Development Environment, IDE) Рис. 2.18. Учет истории и авторства изменений требований Рис. 2.19. Сбор, обработка и использование статистики требований На рынке представлен широкий выбор ПО для поддержки управления требованиями как для водопадной, так и для fgile-методологий в ценовом диапазоне от $62000 (Borland® CaliberRM™) до $50–$1000 (Vitech CORE Product Suite, ViewSet PACE Requirements Management Cradle REQ, Serena Dimensions RM и др.).

Рис. 2.20. Средства ведения форумов или дискуссий по требованиям 2.3.4. Техническое задание – комплексный документ проекта Техническое задание (ТЗ) – это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления. ТЗ подписывается руководителями организации-заказчика и организации-исполнителя.

При разработке ТЗ необходимо решить следующие задачи:

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

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

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

установить общие требования к проектируемой системе;

определить перечень задач создания системы и исполнителей;

определить этапы создания системы и сроки их выполнения;

провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.

Объем и форма ТЗ на создание ИС регулируется требованиями стандартов (ГОСТ 34.602-89, ISO 9001:2000 и др.), а также отраслевыми стандартами на разработку и внедрение ИС. В качестве примера ниже приводится форма технического задания и инструкция на выполнение опытно-конструкторских работ, направленных на создание программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения, рекомендуемая организациям-исполнителям Федеральной целевой программы "Научные и научно-педагогические кадры инновационной России на 2009–2013 годы" [ФЦП]:

';

1 Основание для проведения ОКР 2 Исполнитель ОКР 3 Цель выполнения ОКР 4 Назначение продукции 5 Технические требования к программе или программному комплексу 5.1 Состав продукции 5.2 Требования к функциональным характеристикам (каждое требование оформляется в виде отдельного пронумерованного пункта ТЗ. Требования должны быть сформулированы четко, исключая возможность их неоднозначного толкования).

5.2.1 Требования к составу выполняемых функций 5.2.2 Требования к организации входных данных 5.2.3 Требования к организации выходных данных 5.2.4 Требования к временным характеристикам 5.3 Требования к наджности 5.4 Условия эксплуатации 5.4.1 Климатические условия эксплуатации 5.4.2 Требования к видам обслуживания 5.4.3 Требования к численности и квалификации персонала 5.5 Требования к составу и параметрам технических средств 5.6 Требования к информационной и программной совместимости 5.7 Требования к упаковке и маркировке 5.7.1 Требования к упаковке 5.7.2 Требования к маркировке 5.8 Требования к транспортированию и хранению 5.9 Требования по стандартизации и унификации 6 Требования к документации 7 Специальные требования 7.1 Требования к испытаниям 8 Технико-экономические показатели 8.1 Основные технико-экономические требования (приводятся основные научно-практические и социально-экономические преимущества и выгоды, получаемые от внедрения научно-технических результатов проекта, а также возможные области его коммерческого применения и оценка его конкурентоспособности на мировом рынке).

9 Требования к патентной чистоте и патентоспособности 10 Перечень, содержание, сроки выполнения и стоимость этапов 10.1 Наименование этапов и выполняемые работы 10.2 Сроки исполнения и финансирование по этапам 11 Порядок выполнения и приемки этапов ОКР Приложение (перечень технической документации, разрабатываемой в рамках контракта) В зависимости от объема проекта, уровня ответственности, характера взаимоотношений между заказчиком и исполнителем и других факторов стандарт допускает различные формы и объемы ТЗ. Так, для создания небольших проектов (разработка сайтов, Интернет-рекламы, Интернетмагазинов и т.п.) получила распространение такая форма согласования требований,. как бриф.

Бриф [brief] – краткая письменная форма согласительного порядка между заказчиком и исполнителем (например, между рекламодателем и рекламистом), в которой прописываются основные параметры будущего проекта (например, рекламной кампании). Основная задача брифа – документирование пожеланий заказчика, принимаемых исполнителем, причем форма и техническое исполнение брифа могут быть достаточно произвольными (например, анкета, заполняемая заказчиком, графические материалы с возможными вариантами будущего проекта и т.д.).

2.3.1. Состав работ по планированию и номенклатура планов Согласно ГОСТ Р 51904–2002, в процессе планирования ПО должны быть выполнены следующие работы, относящиеся непосредственно к ЖЦ:

разработка планов создания ПО и передача их исполнителям, осуществуляющим процессы разработки и интегральные процессы;

определение и выбор стандартов разработки ПО, которые будут использованы для данного проекта;

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

обеспечение координации между планами разработки ПО и планами интегральных процессов для получения согласованных стратегий выполненияразличных процессов ЖЦ;

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

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

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

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

План разработки ПО (определяет используемые модели ЖЦ ПО и среду разработки ПО);

План верификации ПО (определяет средства, с помощью которых будут удовлетворены цели процесса верификации ПО);

План квалификационного тестирования ПО (определяет порядок выполнения квалификационного тестирования ПО);

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

План обеспечения качества ПО (определяет средства, с помощью которых будут удовлетворены цели процесса обеспечения качества ПО);

План установки ПО (определяет действия по установке разработанного ПО на рабочих местах пользователей, включая подготовку и обучение персонала и адаптацию существующих систем);

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

2.3.2. Календарное планирование и оперативное управление в проекте В соответствии с определением ЖЦ (см. раздел 1.1.4), проект – динамическое образование, и объединяющей осью для всех его процессов служит ось времени. В связи с этим решающую роль приобретают вопросы календарного планирования каждого процесса ЖЦ и синхронизация календарных графиков с последующей их интеграцией в сводный календарный график проекта (master project schedule). Базовую роль в этом процессе играет выявление критического путеи (посредством сетевого графика) и ведение календарного плана (посредством диаграммы Ганта).

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

1. Каждой работе соответствует одна и только одна вершина.

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

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

4. Все работы должны иметь обозначенную продолжительность. обозначены работами с нулевой продолжительностью. Работы с нулевой продолжительностью, в том числе первая (начало проекта) и последняя (конец проекта), называются вехами и обозначают начало или конец наиболее важных этапов проекта.

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

Таблица 2.6.

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

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

Раннее время начала i-й работы Tp(i) – время, раньше которого работа не может быть начата:

Tp(i) = max (Tp(j)+tj), jG, где G – множество работ, непосредственно предшествующих i-й работе.

Позднее время начала i-й работы Tп(i) – время, позже которого работа не может быть начата без увеличения продолжительности всего проекта:

Tп(i) = min (Tп (j)+tj), jH, где Н – множество работ, непосредственно следующих за i-й работой.

Результаты вычисления указанных величин приведены в табл. 2.7 и проиллюстрированы на рис. 2.22, 2.23. Критический путь получается соединением критических работ на сетевом графике. Он показан пунктирными стрелками на рис. 2.24.

Таблица 2. Рис. 2.22. Вычисление раннего времени начала работ Min(12-10,10-10)= 0-0= Рис. 2.23. Вычисление позднего времени начала работ Рис. 2.24. Критический путь проекта После вычисления величин Tп(i) и Tп(i) для каждой работы вычисляется резерв времени Н(i):

Н(i) = Tп(i) - Tп(i), который дает менеджеру возможность маневрировать временем их начала и используемыми ими ресурсами.

Календарный график проекта чаще всего строится на базе диаграммы Ганта (рис. 2.25), которая отображает следующие параметры проекта:

1. структуру работ, полученную на основе сетевого графика;

2. состав используемых ресурсов и их распределение между работами;

3. календарные даты, к которым привязываются моменты начала и завершения работ.

График (рис. 2.25) построен для распределения ресурсов в проекте согласно табл. 2.8. На графике ромбиками обозначены вехи, сплошными линиями – продолжительность работ, сплошными линиями со стрелками – резерв времени работ, пунктирными линиями – связь между окончанием предшествующих и началом последующих работ.

Таблица 2. конкретного трудового ресурса в ходе выполнения проекта.

На основании построенных графиков организуется оперативное управление проектом:

1. отслеживание фактического графика выполнения работ;

2. сравнение фактического графика с плановым;

3. принятие решений по ликвидации наметившихся отклонений от плана;

4. перепланирование проекта в случае значительных отклонений.

Рис. 2.25. Диаграмма Ганта Рис. 2.26. График загруженности ресурсов 2.3.3. Инструментальная поддержка планирования задач проекта Инструментальная поддержка планирования задач проекта реализуется в различных ППП и может быть проиллюстрирована на примере ППП Microsoft Office Project 2007.

Редактируемое семейство календарей проекта включает:

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

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

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

Microsoft Project 2007 поддерживает идеологию сетевого планирования, для чего выделяются следующие артефакты:

работа – действия, направленные на выполнение некоторой части проекта;

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

фаза – составная работа, состоящая из нескольких работ и завершаемая вехой;

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

В Microsoft Project допускаются различные виды временных зависимостей между задачами:

окончание–начало (формирует логическую последовательность работ);

начало–начало (объединяет задачи, которые могут выполняться параллельно);

окончание–окончание (отображает причинно-следственную связь работ);

начало–окончание (отображает причинно-следственную связь работ);

задержки и опережения (отражают нестрогое следование задач друг за другом);

ограничение (безусловная привязка планирования к конкретному сроку);

крайний срок ((привязка планирования к конкретному сроку с индикацией превышения).

Microsoft Project 2007 поддерживает визуальное моделирование основных диаграмм календарного и оперативного планирования. На рис. 2. представлена пустая диаграмма Ганта, в которую вводятся задачи проекта, среди которых назначаются вехи и фазы (рис. 2.28).

Рис. 2.27. Стартовое окно календарного планирования Рис. 2.28. Результат преобразования задач в вехи и фазы Создание связей между задачами выполняется как непосредственно в календарном графике (с помощью мыши), так и в таблице ввода данных (при помощи столбца Предшественник, в который вводятся номера непосредственно предшествующих задач). Результатом является календарный график проекта (рис. 2.29). Затем выполняется назначение длительностей задач (рис.

2.30), уточнение типа связей и ввод значений задержек или опережений, назначаются даты начала/окончания проекта, ограничения, крайние сроки и календари задач. Возможно добавление в проект повторяющейся задачи (рис.

2.31).

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

В заключение отметим, что календарное планирование и оперативное управление – неотъемлемая часть управления проектом. Эти аспекты прописываются в ТЗ на проект (см. раздел 2.2.4), и их несоблюдение может служить основанием для расторжения контракта на разработку ИС.

Рис. 2.29. Календарный график проекта Рис. 2.30. Результат ввода длительности задач Рис. 2.31. Периодическая задача на диаграмме Ганта 2.4. Управление информационными потоками в проекте 2.4.1. Содержание процесса управления информационными потоками ГОСТ Р ИСО/МЭК 15288-2005 определяет процесс управления информацией в качестве одного из процессов ЖЦ следующим образом.

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

определяется информация, подлежащая управлению;

определяются формы предоставления информации;

информация преобразуется и распределяется в соответствии с требованиями;

документируется статус информации;

информация является "свежей", полной и достоверной;

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

При реализации процесса управления информацией организация должна осуществлять следующие действия в соответствии с принятой политикой и процедурами:

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

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

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

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

e. обслуживать элементы информации и хранящиеся записи этих элементов в соответствии с требованиями целостности, защиты и сохранения таймы;

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

g. находить и распределять информацию между определенными сторонами в соответствии с требованиями согласованных трафиков или при определенных обстоятельствах h. предоставлять официальную документацию в соответствии с требованиями;

i. архивировать заданную информацию в соответствии с целями аудита и сохранения знаний;

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

2.4.2. Датацентрическая парадигма в управлении информационными Для реализации перечисленных требований существует калейдоскопическое множество технологий и программных средств, и выбор корпоративной стратегии здесь должен производиться с учетом общей концепции информационной архитектуры организации (см. раздел 1.2.4). Однако в настоящее время наблюдается тенденция к интеграции информационных потоков, т.е. к удовлетворению требований a–j с единых архитектурных позиций.

Пример такого движения демонстрирует стандарт ISO 15926 [15926].

Стандарт имеет оригинальное название "Industrial automation systems and integration--Integration of life-cycle data for process plants including oil and gas production facilities" и большое разнообразие переводов на русский язык, но, по существу, является стандартом датацентрического информационного моделирования и интеграции данных.

Главные идеи стандарта ISO 15926 сводятся к следующему.

Вместо тотальной «интеграции данных», которая требует больших ресурсов и является источником ошибок, используется дешевое однократное отображение (mapping), которое много проще, но также чревато ошибками (одни и те же названия могут означать разные объекты, и наоборот – разные названия могут означать одни и те же объекты). Поэтому при интеграции двух моделей данных рассматривается также третья модель – понятия более высокого уровня абстракции («онтология») В качестве модели данных используется не 3D-, а 4D-модель. 4Dобъекты существуют «всегда», рассматриваются из «внешнего времени», протяженны в пространстве и времени, имеют темпоральные части. При этом легче учитывать изменения, что хорошо для отображения информации о ЖЦ.

Произведен переход от документоцентрической (когда в качестве единицы информационного потока передается «документ») к датацентрической парадигме:

входные документы: парсируются до уровня «полей», которые рассматриваются как «данные»;

учетная система ориентирована на эти «данные»;

выходные документы: генерируются из «данных» на момент их формирования;

стандарт полностью поддерживает предметную область документооборота – документы, шаблоны, процедуры, «передача с учета на учет» и т.д.

Для технологической реализации стандарта может быть использована концепция Semantic Web или более простые технологии (Gellish и Excel). Использование в качестве промежуточного средства представления «информационных объектов» табличного представление Gellish (в свою очередь, отображенного на модель данных ISO 15926) допускает представление информационных объектов в виде XML-файлов,.xls-файлов, файлов баз данных и любых других табличных форматов. Для построения онтологии используется OWL, хранение информации реализуется в RDF triple/quadro store, в качестве языка запросов используется SPARQL.

Переход к датацентрической парадигме обеспечивает следующие преимущества в управлении информационными потоками в проекте :

• Устранение многократного ввода информации • Объединение информации о процессах/проектах/объекте • Объединение технической и управленческой информации • Автоматизация workflow (процессов) и проектного управления 2.4.3. Workflow-ориентированное управление Определенные преимущества в управлении информационными потоками при выполнении проекта для процессно-ориентированной организации может дать переход к новым стандартам описания бизнес-процессов – BPMN, BPEL (WSBPEL) [BPMN] Спецификация BPMN (Business Process Modeling Notation) 1.0 определяет графическую нотацию; формат файла обмена моделями – XPDL [XPDL]).

В качестве языка используется BPEL (Business Process Execution Language), который определяет модель и грамматику для описания поведения бизнеспроцессов, основанных на Web-сервисах, в терминах длительных, обладающих состоянием взаимодействий (состоящих из обмена сообщениями) между процессом и его партнрами.

Структура модели предполагает 3 типа подмоделей:

• Личный (Private) процесс (рис. 2.32) • Абстрактный (Abstract) процесс (рис. 2.33) • Сотрудничество (Collaboration) (рис. 2.34) – глобальный процесс В модели возможны:

• Поведение, зависящее от данных. Ветвления и слияния • Обработка исключений, цикл. Вложенные элементы работы • Транзакция, компенсация ошибки транзакции • Ветвление на основе событий Рис. 2.32. Личный процесс Рис. 2.33. Абстрактный процесс Рис. 2.34. Сотрудничество (Collaboration) В качестве примера на рис. 2.35 в нотации BPMN представлен бизнеспроцесс голосования по электронной почте.

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

• автоматическое создание отчтов о составе модели;

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

• автоматизация интеграции бизнесов и, на этой базе, соответствующего Рис. 2.35. Бизнес-процесс голосования по электронной почте в нотации BPMN 2.5.1. Содержание процесса управления конфигурацией Конфигурация в широком смысле (применительно к поддержке бизнеспроекта) определяется как именованный набор объектов (элементов конфигурации) произвольной природы, генерируемый в ходе выполнения проекта.

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

ГОСТ Р 51904-2002 определяет цели процесса управления конфигурацией ПО – определить критерии перехода, взаимосвязи и последовательность выполнения процессов – и состав работ по этому процессу:

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

Идентификация конфигурации проводится • для документов ЖЦ ПО;

• для каждого отдельного элемента конфигурации ПО (ЭКПО);

• для каждого отдельно управляемого компонента ЭКПО;

• для комбинаций ЭКПО, которые составляют программное средство.

Элемент конфигурации (configuration item) – объект внутри конфигурации, который удовлетворяет функции конечного использования и может быть однозначно определен в данной эталонной точке.

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

• установить уровень контроля (авторский контроль, контроль на уровне проекта, контроль заказчика);

• установить полномочия лиц на внесение изменений;

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

Базовая линия (baseline) – официально принятая версия элемента конфигурации, независимая от среды, формально обозначенная и зафиксированная в конкретный момент времени жизненного цикла элемента конфигурации.

Базовые линии (БЛ) устанавливаются для ЭК, на которые распространяется сертификационное доверие; для контроля процессов ЖЦ могут быть установлены промежуточные БЛ. БЛ должна быть определена в Указателе конфигурации ПО. При всех модификациях ПО должна быть обеспечена целостность БЛ, а также трассируемость БЛ и ЭК к соответствующим БЛ и ЭК предшествующей версии. БЛ и ЭК должны быть трассируемы либо к выходным данным, которые они идентифицируют, либо к процессу, с которым они связаны.

Должны быть обеспечены регистрация, оценка, рассмотрение и утверждение изменений на протяжении всего ЖЦ ПО. Стандарт особо подчеркивает, что процесс управления конфигурацией не прекращается после того, как ПО принимается заказчиком.

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

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

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

Обеспечивается контроль загрузки исполняемого кода в систему и среды ЖЦ ПО:

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

Документы ЖЦ ПО, относящиеся к конфигурации, могут быть отнесены к одной из двух категорий контроля (КК) в зависимости от уровня ПО (см.

раздел 2.7) в соответствии с табл. 2.9. В таблице знаком * обозначены цели, которые для документов данной категории должны быть удовлетворены в обязательном порядке, остальные цели удовлетворяются по усмотрению разработчика.

Таблица 2. 2.5.2. Организация информационной поддержки процесса управления конфигурацией (на примере AllFusion Harvest Change Manager) Структура и иерархия объектов AllFusion Harvest Change Manager [AllFusion] представлена на рис. 2.36.. В пакете предусмотрены две роли - администратор и пользователи. К административным функциям относятся:

• определение пользователей и групп пользователей;

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

• создание репозитория • создание представлений данных (базового, рабочих и моментальных В состав Harvest Change Manager входит 11 шаблонов ЖЦ, которые администратор может использовать как основу для создания своего собственного типа ЖЦ (табл. 2.9), а также набор стандартных процессов (табл. 2.10).

Рис. 2.36. Иерархия объектов в Harvest Change Manager Таблица 2. Шаблоны ЖЦ Содержание шаблона ЖЦ Управление запросами на изменение. Создание запроStandard problem tracking Расширенная модель управления запросами на измеFormal problem tracking Организация версионного контроля и отслеживание Version Control Шаблон для создания нового программного обеспечеNew development Release При разработке новой версии (релиза) продукта необParallel ходимо также поддерживать предыдущие версии проDevelopment Шаблон Production позволяет контролировать изменеProduction Шаблон, необходимый для связывания программного Third-Party обеспечения сторонних разработчиков с собственныSoftware Electronic Software Шаблон для использования в системах электронной дистрибуции программного обеспечения. Электронная Distribution дистрибуция программного обеспечения позволяет упростить процесс дистрибуции (передачи) программ компьютеров. Однако настройка такой системы является нетривиальной задачей и немаловажным фактором функционирования системы является организация конфигурационного менеджмента и контроля версий.

HelpDesk Desk, позволяющая обмениваться информацией между Integration различными приложениями службы Help Desk, к примеру, такими как AutoAnswer.

Этот шаблон используется для документирования изPackaged Application Change менений в системах класса: Oracle Financials, Management риск использования непроверенных изменений, которые могут неблагоприятно сказаться на общем функционировании системы или привести к ее краху.

Таблица 2. Тип процесса Описание процесса Данный процесс позволяет определенным пользоватеApprove лям подтвердить либо отклонить пакет для последующего перемещения пакета на следующий этап проекта либо Процесс, позволяющий скопировать файлы с клиентскоCheck In го компьютера в репозиторий Harvest, создавая тем самым новые элементы репозитория, либо обновляя существующие.

Процесс копирования элементов репозитория на клиентCheck Out Compare Views С помощью данного процесса создается отчет о различиях в двух отображениях, сравниваемые отображения могут быть как рабочими, так и моментальными снимками.

Использование данного процесса возвращает версию Concurrent элемента с ветви дерева версий на ствол дерева версий.

Merge Create Package Данный процесс создает пакет, в рамках которого отслеживаются изменения программного кода. Если в свойствах процесса указана опция автоматического создания формы, то создается форма, ассоциированная с Этот процесс необходим для слияния изменений элеCross Project ментов, сделанных в одном проекте с изменениями тех Merge Delete Version Процесс удаления версии элемента, хранящегося в репозитории Harvest; данный процесс имеет ряд ограничений версия не может быть удалена, если она существует в нескольких отображениях В состав Harvest включены два процесса, с помощью коDemote торых пакеты перемещаются между состояниями проекта. С помощью процесса Demote осуществляется перенос пакета с текущего состояния проекта на предыдущее. Interactive Merge С помощью этого процесса объединяются изменения, сделанные в версиях элементов в ветвях дерева версий с версиями изменений на стволе.

При помощи данного процесса создается отчет об измеList Version нениях версий элемента репозитория в рамках текущего Процесс Move Package необходим для перемещения паMove Package кета из одного состояния проекта в одно из состояний другого проекта. При этом перемещаются лишь описание пакета и его история, элементы пакета не могут быть перемещены. Этот тип процесса используется в основном для связи пакетов между проектами.

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

Процесс для переноса пакета либо группы пакетов с теPromote кущего состояния проекта на следующее состояние.

Процесс логического удаления выбранных элементов.

Remove Item Фактически этот процесс создает новую версию выбранного элемента и в дальнейшем для восстановления этого элемента необходимо удалить версию с пометкой Процесс переименования элемента. В процессе переRename Item именования элемента создается новая версия элемента.

Все предыдущие версии элемента отображаются под Процесс создания отображения типа моментальный Take snapshot В качестве процесса, определенного пользователем, User-defined можно использовать внешнюю программу, которая буprocess дет выполняться как процесс в рамках текущего жизненного цикла.

Администратор разрабатывает жизненный цикл из набора состояний, представленных в табл. 2.11.

Таблица 2. Наименование Содержание состояния состояния создаются запросы на изменение (пакета), запросы могут Assign быть созданы любым пользователем Harvest.

разработчики вносят все необходимые изменения в проCoding граммный код в соответствии с поступившими запросами на тестировщик просматривает запрос на изменение и тестируTest ет изменения в программном коде сделанные разработчиком в рамках данного состояния хранятся все авторизованные Release в пределах этого состояния хранятся все моментальные Snapshot Администратор:

• создает пользователи и группы пользователей.

• создает проект и три рабочих отображения.

• создает ряд процессов для каждого состояния.

• создает Репозиторий и устанавливает рабочую линию проекта.

• проводит разграничение доступа к объектам для пользователей и групп пользователей.

После настройки проекта администратором его могут начать использовать пользователи Harvest.

Harvest Change Manager поддерживает три типа разработки ПО:

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

- одновременная разработка (рис. 2.37). Для обеспечения многопользовательского доступа к элементам используется процесс check out с опцией concurrent update, с помощью этого процесса создается ветвь в дереве версий. После создания ветви дерева версий в ней фиксируются все версии изменений данного пакета. Для того чтобы перевести пакет с изменениями, сделанными в ветви, в другое состояние проекта, версии, находящиеся на ветви дерева версий нужно возвратить на ствол. Для этого используется стандартный процесс Concurrent Merge;

Рис. 2.37. Одновременная разработка - параллельный тип разработки позволяет вести работу одновременно над несколькими проектами и использовать в одном проекте версии пакета из другого проекта. Такой тип разработки позволяет создавать новый релиз программного обеспечения и при этом поддерживать текущий. Все изменения, производимые над текущим релизом (горячие патчи и т.д.) должны учитываться в новой финальной версии продукта. Для переноса пакета из одного релиза продукта в другой используется процесс Cross Project Merge.

2.5.3. Средства информационной поддержки Решения для управления конфигурацией и изменениями ПО (Software change and configuration management [SCCM] как сами по себе, так и вместе с приложениями для управления ЖЦ (Application Lifecycle Management, ALM), помогают разработчикам следить за изменениями, которые они вносят в свои продукты в процессе их развития. SCCM решает многие проблемы, возникающие в ходе разработки и общения с руководителями проектов – проблему частичного или полного одобрения работы, назначения ответственных, хранения фрагментов исходного кода или документов, сопутствующих разработке, а также слежения за изменениями этих документов.

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

• поддержка рабочего процесса (и документооборота в рамках рабочего процесса);

• интеграция со средствами управления, в том числе Project Management;

• поддержка нескольких рабочих команд;

• синхронизация;

• кроссплатформенность;

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

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

На сегодняшний день принято подразделять множество SCCM продуктов на три группы:

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

Продукты среднего звена, ориентированные на структурированные и неструктурированные взаимодействия в рамках группы разработчиков.

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

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

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

Как показывают результаты аналитического обследования [Gartner], среди лидеров рынка находится ПП Visual Studio Team System от корпорация Microsoft. Продукт хорошо интегрируется с системой управления проектами, гибко масштабируется, хотя поддержка разработок в рамках крупных команд все еще затруднена. Основными преимуществами Visual Studio Team System является гибкая модель процесса, а также возможность отслеживания изменений не отдельно в программном коде или документации, а в неких абстракциях («рабочая единица»), что уменьшает временные затраты разработчика на отслеживание изменений. Среди недостатков решения отмечается обязательное требование к запуску серверной части системы на Windows Server, а также сложный инсталляционный процесс. Кроме того, по мнению аналитиков, процесс настройки системы безопасности отнимает слишком много времени.

IBM Rational ClearCase - система конфигурационного управления программным проектом. По данным [Gartner], является лидером рынка по объему продаж. Выпускается в нескольких версиях (рис. 2.36):

Rational ClearCaseLT - продукт, предназначенный для небольших рабочих групп.

IBM Rational ClearCase LT предоставляет основные средства контроля версий компонентов разработки, идеально подходит для небольших и средних коллективов разработчиков, расположенных в одном месте.

IBM Rational ClearCase MultiSite - дополнительная система для Rational ClearCase, предназначенная для управления географически распределенными программными ресурсами, задействованными в средних и крупных проектах.

Рис. 2.36. Версии IBM Rational ClearCase Определенный интерес представляет продукт [DEVPROM], которая совместно с системой контроля версий, инфраструктурами автотестирования и выпуска сборок, реализует полноценную систему управления конфигурацией, ориентированную на аутсорсинговую разработку:

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

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

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

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

В заключение отметим, что задача управления конфигурациями проекта тесно смыкается с управлением сервисными активами и конфигурациями ИТ-инфраструктуры. Здесь могут использоваться решения EMC Ionix Solutions, Cisco и решения других вендоров.

Система менеджмента качества ISO 9000-2001 определяет качество как "степень соответствия присущих характеристик требованиям".

Повышение качества ПО рассматривается как итеративный процесс постоянного улучшения. Очевидно, что текущий уровень качества ПО есть некоторое приближение к идеалу, и необходимо установить приемлемый уровень качества. Согласно [SWEBOK], приемлемое качество может рассматриваться как количественно выраженный компромисс между заказчиком и исполнителем в отношении характеристик продукта, создаваемого исполнителем в интересах решения задач заказчика с учетом других ограничений проекта (в частности, стоимости, что часто именуется как cost of quality – стоимость качества). В свою очередь, стоимость качества (cost of quality) может быть дифференцирована на:

стоимость предупреждения дефектов (prevention cost), стоимость оценки (appraisal cost), стоимость внутренних сбоев (internal failure cost), стоимость внешних сбоев (external failure cost).

Существует два подхода к моделированию качества ПО:

общая система менеджмента качества ISO 9000-2001;

модель уровня зрелости процессов разработки ПО CMMI.

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

Существует два подхода к организации работ по повышению качества ПО:

TQM (Total Quality Management) – всеобщее управление качеством;

PDCA (Plan, Do, Check, Act – Планирование, Действие, Проверка, Реакция/Корректировка) – цикл Деминга.

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

Стандарт [9126] определяет 6 структурных наборов характеристик, которые, в свою очередь, детализируются субхарактеристиками:

Функциональность – набор атрибутов, характеризующих соответствие функциональных возможностей ПО набору требуемой пользователем функциональности. Детализируется следующими субхарактеристиками:

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

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

понятность простота использования изучаемость привлекательность.

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

временная эффективность используемость ресурсов.

Сопровождаемость – набор атрибутов, относящийся к объему работ, требуемых для проведения конкретных изменений (модификаций). Детализируется следующими субхарактеристиками:

удобство для анализа изменяемость стабильность тестируемость.

Мобильность – набор атрибутов, относящийся к способности ПО быть перенесенным из одного окружения в другое. Детализируется следующими субхарактеристиками:

адаптируемость простота установки (инсталляции) сосуществование (соответствие) замещаемость.

Субхарактеристика Соответствие принадлежит всем характеристикам и отражает отсутствие противоречий с иными стандартами или характеристиками.

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

В стандарте также выделены рекомендуемые характеристик качества в использовании:

системная эффективность – применение программного средства (ПС) по назначению;

продуктивность – производительность при решении основных задач ПС, достигаемая при реально ограниченных ресурсах[ в конкретной внешней среде применения;

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

удовлетворение требований и затрат пользователей (в соответствии с целями применения ПС).

2.6.3. Процессы управления качеством ПО Стандарт [12207] выделяет следующие специализированные процессы управления качеством:

процесс обеспечения качества (quality assurance process) процесс верификации (verification process) процесс аттестации (validation process) процесс совместного анализа (joint review process) процесс аудита (audit process) Процесс обеспечения качества обеспечивает подтверждение того, что программные продукты и процессы ЖЦ проекта соответствуют заданным требованиям. Такое подтверждение проводится на основе планирования, постановки работ и исполнения набора действий, направленных на то, чтобы качество стало неотъемлемой частью программного обеспечения. Конкретная организация процесса должна быть направлена на то, чтобы идентифицировать проблемы, которые практически неизбежны в любой сложной деятельности, на максимально ранних стадиях.

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

Процессы верификации и валидации (аттестации) общеупотребительное сокращение V&V) определены в ГОСТ Р ISO/IEC 12207 (см. раздел 2.2.2).

[SWEBOK], содержательно объединяя эти процессы, дает следующее определение: V&V (проверка и аттестация программного обеспечения) – упорядоченный подход в оценке программных продуктов, применяемый на протяжении всего жизненного цикла Процессы обзора и аудита также объединены в [SWEBOK] на основании стандарта [1028]., в котором представлены пять типов оценок и аудитов:

Управленческие оценки (management reviews) Технические оценки (technical reviews) Инспекции (inspections) Прогонки (walk-throughs) Аудиты (audtis) Назначение управленческих оценок состоит в отслеживании развития, определения статуса планов и расписаний, утверждения требования и распределения ресурсов, или оценки эффективности управленческих подходов, используемых для достижения поставленных целей.

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

Назначение инспекций состоит в обнаружении и идентификации аномалий в программном продукте. Отличия инспекций от оценок состоят в следующем:

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

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

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

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

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

Область применения системы, в которой будет работать программное обеспечение (критичное для безопасности ), критичное для Системные и программные требования Какие компоненты используются в системе – коммерческие (внешние) или стандартные (внутренние) Какие стандарты программной инженерии применимы в заданном контексте Каковы методы и программные инструменты, применяемые для разработки и сопровождения, а также для обеспечения качества и совершенствования (продукта и процессов) Бюджет, персонал, организация проектной деятельности, планы и расписания для всех процессов Кто целевые пользователи и каково назначение системы Уровень целостности системы Особую роль в выборе показателей качества играет уровень ответственности проектируемого ПО. Стандарт [51904] разделяет проектируемое ПО на уровни.

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

уровень А – ПО, аномальное поведение которого вызывает катастрофическую отказную ситуацию для объекта управления;

уровень В – ПО, аномальное поведение которого вызывает опасную/критическую отказную ситуацию для объекта управления;

уровень С – ПО, аномальное поведение которого вызывает существенную отказную ситуацию для объекта управления;

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

Процессы управления качеством обеспечивают нахождение дефектов.

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

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

Недостаток – некорректный шаг, процесс или определение данных в компьютерной программе.

Сбой – некорректный результат, полученный в результате недостатка.

Человеческая / пользовательская ошибка – действие человека, приведшее к некорректному результату.

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

основанные на статистических методах (например, анализ Парето, нормальное распределение и т.п.) статистические тесты анализ тенденций предсказание (например, модели надежности).

Для управления качеством ПО используются следующие техники:

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

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

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

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

Задачам тестирования в аспекте V&V отвечают такие типы, как:

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

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

тестирование третьей стороной.

ЧАСТЬ 3. ОРГАНИЗАЦИЯ ИНФОРМАЦИОННОЙ ПОДДЕРЖКИ

ПРОЕКТИРОВАНИИ И РАЗРАБОТКИ ПО

3.1. Информационная поддержка управления персоналом На рынке представлен широкий спектр ПО для поддержки управления персоналом с разнообразным набором функциональностей. Некоторые компании специализируются конкретно в области разработки, внедрения и сопровождения решений по автоматизации управления персоналом, другие создают свои кадровые системы в составе своих же ERP-решений. Приведем несколько примеров, ориентируясь в основном на отечественные разработки [HR].

В классе ПО типа PSA (Professional Services Automation) и TMS (Time Management System) сообщается о продукте ProjectMate. Система ProjectMate имеет привычный интерфейс, выполненный в стиле Microsoft Outlook. Система ProjectMate 6 имеет специальный модуль синхронизации с Microsoft Project, что дает следующие возможности:

детальное управление проектными затратами, стандартизация процесса планирования проектов, формализация ведения проектной документации.

выявление скрытых временных ресурсов, не задействованных должным образом.

Программный комплекс "АиТ:Управление персоналом" (разработчик – компания АиТ:Софт) позволяет решать широкий круг учетно-статистических и аналитических задач, связанных с кадровым менеджментом. В состав комплекса входят следующие модули: "Кадры", "Зарплата", "Табельный учет", "Учет рабочего времени", "Учет выполненных работ (наряды)", "Персонифицированный пенсионный учет", "Планирование штатных расписаний", "Автоматизация работы с негосударственным пенсионным фондом", "Репликация". Кроме того, дополнительно разработаны специализированные решения, помогающие в необходимых случаях расширить возможности программного комплекса – это "Оценка и аттестация персонала", "Автоматический учет рабочего времени (электронная проходная)" и др. Сервис "Кадровый вебпортал" решает задачу широкого информирования сотрудников о делах компании, что способствует повышению их лояльности и может использоваться в качестве инструмента мотивации. Сервис "Управление компетенциями" позволяет разрабатывать модели компетенций сотрудников предприятия, профилей сотрудников; помогает формировать планы на обучение, на создание кадрового резерва, предложения по мотивации и пр.; Сервис "Управление обучением" позволяет формировать планы на обучение и тренинги, вести БД провайдеров обучения, отслеживать процесс и результаты обучения.

Продукт "АНД Проджект: Расширенный учет кадров для Microsoft Dynamics AX" отличается от других систем, решающих похожие задачи, тем, что он органично встроен в ERP-систему, фактически являясь е частью. Задачи, связанные с расчетом зарплаты и кадровым учетом, как правило, очень трудоемки (особенно на крупных предприятиях) ввиду большого объема данных, вычислений, повышенных требований к безопасности и надежности расчетов. В решении "АНД Проджект" можно вести организационную структуру и штатное расписание, тарифные сетки, индивидуальные сведения о сотрудниках, их аттестации и пр. Система позволяет оформлять трудовые отношения, осуществлять кадровое движение, рассчитывать отпуска и командировки, формировать производственный календарь и готовить большое количество управленческой отчетности, касающейся кадров. Решение "АНД Проджект: Расширенный учет кадров" зарегистрировано в компании Microsoft, где внесено в международный каталог партнерских отраслевых и функциональных продуктов для системы Microsoft Dynamics AX.

Продукт "БОСС-Кадровик" (разработчик – группа компаний "АйТи") является тиражной полнофункциональной системой управления персоналом.

"БОСС-Кадровик" состоит из следующих контуров: "Учетновычислительный контур", "Контур управления кадровыми процессами" и "Контур анализа кадровых процессов". Используя возможности соответствующих контуров, пользователи системы могут вести всю учетную работу по персоналу, рассчитывать заработную плату, управлять различными мероприятиями по персоналу (подбор, оценка, мотивация, обучение), анализировать кадровую деятельность в различных разрезах и т.д. Продукт позволяет предприятиям на практике реализовать единую кадровую политику, основанную на унифицированных процедурах, проводить структурнофункциональную оптимизацию дочерних предприятий согласно профилю успешной компании, оптимизацию численности и профессиональноквалификационного состава трудовых ресурсов, централизованно управлять различными группами персонала в масштабах холдинга, а также проводить объективный агрегированный анализ состояния человеческих ресурсов холдинга. Продукт способен обрабатывать массивы данных численностью в десятки и сотни тысяч человек, обеспечивать одновременную работу сотен пользователей. Благодаря универсальному интерфейсу интеграции "БОССКадровик" успешно работает с финансовыми, бухгалтерскими, управленческими и другими информационными системами.

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

Разработчик "SAP СНГ" предлагает полнофункциональное ERP-решение "Управление ресурсами предприятия". Его составной частью является подсистема "Управление человеческим капиталом" (HCM), которая объединяет технологии управления персоналом с возможностью реализации стратегических целей компании в рамках единого информационного пространства. Она обеспечивает выполнение функций планирования и аналитики, оперативного управления персоналом, формирования и развития кадрового потенциала, управления сотрудничеством и коммуникациями и многое другое; позволяет отделу управления персоналом более тесно и эффективно сотрудничать с руководителями других структурных подразделений.

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

В качестве примера приведем сочетание средств коммуникации, характерное для коммуникаций в крупной ИТ-компании:

совместная работа над документом реализуется на базе идеология WEB 2.0; для технологической организации совместной работы используются различные программные продукты, как правило, на базе wiki-движка;

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

распределенные видеоконференции и попарное общение разработчиков реализуется через Skype;

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

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

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

быстрые и эффективные профессиональные консультации практически по всем возникающим у разработчиков вопросам;

быстрое и эффективное решение организационных вопросов посредством электронного документооборота;

удаленное повышение квалификации, тренинги и т.п., однако порождает и проблемы:

отвлечение сотрудников на общение, непосредственно не связанное с производственной деятельностью;

утечка корпоративной информации.

Для решения первой проблемы постоянно разрабатываются методики, реализуемые техническими средствами, например:

перекрытие конкретных сервисов, сетевых ресурсов и т.п.;

учет количества нажатий на клавиатуру, выполняемых сотрудником в течение рабочего времени;

отслеживание и последующий анализ сетевых логов сотрудника.

В то же время решение проблем безопасности возлагается не только и не столько на технические средства, сколько на организационновоспитательные меры, в том числе:

широкое внедрение корпоративной культуры;

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

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

3.3. Средства интегральной информационной поддержки 3.3.1. Основные задачи средств интегральной информационной Представленный в пособии материал дает представление о многообразии задач, решаемых в ходе проектирования, реализации и управления ЖЦ ПО.

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

1. специализированное ПО для управления проектами;

2. включение в состав CASE-продуктов функционала для поддержки проектирования;

3. расширение интегрированных сред разработки программного обеспечения в направлении поддержки высокоуровневых процессов проектирования;

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

5. расширение систем документооборота до систем Workflow и Groupware.

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

5.1. Системы управления документооборотом (СУД) – это технология, которая подразумевает управление только документами, а это еще не все процессы компании. Основное отличие СУД от Workflow – в большей ориентированности на документ. Практически все СУД содержат большое количество функций для работы с документами (например, поиск документа по ключевым словам), которые есть далеко не во всех системах Workflow и Groupware.

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

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

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

• процесс выделен;

• процесс структурирован;

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

• процесс периодически повторяется.

Первые три ограничения являются ответом на вопрос «какие процессы можно описать», а последнее – «какие целесообразно».

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

Сформулируем более подробно задачи, решаемые информационными системами типа Workflow [5 шагов]:

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

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

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

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

поддержание системы в актуальном состоянии, отражающем особенности текущего состояния рынка, стратегию и тактику деятельности предприятия.

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

3.3.2. Примеры ПП для информационной поддержки процессов Приводимые ниже примеры сгруппированы в соответствии с направлениями, выделенными в разделе 3.3.1.

ПО для управления проектами подробно изучается в соответствующем курсе (см., например, [Сатунина]). В качестве примера в настоящем курсе показаны некоторые возможности Microsoft Office Project 2007 (см. раздел 2.3.3). На рынке представлено множество ПП для поддержки управления проектом, и выбор такого ПО для конкретного проекта должен организовываться как решение многокритериальной задачи. В качестве примера можно упомянуть "социальный рейтинг" систем управления проектами, выполняемыми в режиме on-line ([on-line]; см. также раздел 3.2.1) Включение в состав CASE-продуктов функционала для поддержки проектирования.

Линейка AllFusion компании Computer Associates [AllFusion] – семейство интегрированных решений для разработки, развертывания и управления информационными системами на предприятии. CASE-средства этой линейки позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций.

Основные компоненты линейки AllFusion:

AllFusion Process Modeler (BPwin) – моделирование бизнес-процессов;

AllFusion ERwin Data Modeler (ERwin) – проектирование структур данных (рис. 3.8);

AllFusion Data Model Validator (ERwin Examiner) – проверка моделей данных;

AllFusion Model Manager (ModelMart) – сервер для совместной работы пользователей Process Modeler и/или ERwin Data Modeler ;

AllFusion Component Modeler (Paradigm Plus) – проектирование информационных систем и компонентов ПО;

AllFusion Model Navigator – просмотр моделей, созданных в ERwin Data Modeler и Process Modeler;

AllFusion Saphir Option – средство просмотра структур данных корпоративных информационных систем ERP-класса (PeopleSoft, SAP R/3 и J.D.

Edwards OneWorld).

Рис. 3.8. Интерфейс многоуровневой архитектуры проектирования в ERwin Data Modeler Программный продукт Ramus [Ramus] создан как основной инструмент ведения проектов по построению или реорганизации систем управления предприятием. К таковым могут относиться: проекты по реинженирингу бизнес-процессов, проекты внедрения процессного управления, проекты построения системы менеджмента качества, проекты построения системы управления знаниями и т.п. Ramus ориентирован на достаточно большик и сложных организации.

Основные возможности Ramus:

Моделирование процессов (согласно методологиям IDEF0 и DFD);

Разработка систем классификации и кодирования предприятия с внутренними перекрестными связями, которая также тесно увязывается и с моделями процессов;

Формирование отчетности по моделям и системе классификации, в том числе и отчетности в форме такой регламентирующей документации как должностные инструкции и регламенты процессов;

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

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

кроссплатформенность;

восстановление всех данных утраченных в результате сбоев питания и других системных сбоев;

гибкий графический интерфейс пользователя;

эргономичность редактора диаграмм;

возможность отмены действий пользователя.

Ramus является коммерческим продуктом, однако на официальном сайте разработчиков выложена его демо-версия, не ограниченная по функциональности. Кроме того, для свободного скачивания доступен пакет с усеченной функциональностью Ramus Educational. Исходный код ядра Ramus версии 1.2.5 и модуль экспорта/импорта данных в xls файлы опубликованы под открытой лицензией GPL.

Расширение интегрированных сред разработки программного обеспечения в направлении поддержки высокоуровневых процессов проектирования.

Интегрированная среда разработки (англ. IDE, Integrated development environment) – система программных средств, используемая программистами для разработки программного обеспечения (ПО). Из универсальных IDE отметим Visual Studio и Eclipse.

Microsoft Visual Studio – линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. В версии Visual Studio® 2010 введен ряд возможностей [MSVS], которые помогают управлять, осуществлять коммуникации, отслеживать работы, а также создавать отчеты по статусам проекта и ключевым показателям производительности на протяжении всего жизненного цикла проекта. Линейка Visual Studio 2010 содержит новые инструменты для создания максимально подробных и удобных описаний ошибок. Данные инструменты позволяют «отлаживать прошлое», записывать видео и состояние системы в момент ошибки, а также автоматизировать тестирование пользовательского интерфейса. Линейка Visual Studio 2010 также предлагает новый комплекс инструментов для архитектурного проектирования и анализа кода. Поддержка стандарта UML, построение и проверка комплексных моделей и анализ взаимозависимостей в коде позволяют улучшить архитектурную целостность программных систем.

Eclipse – это основанная на Java расширяемая платформа разработки с открытым исходным кодом. По сути, это просто среда разработки и набор сервисов для построения приложений на основе встраиваемых компонентов (плагинов). В составе Eclipse имеется стандартный набор плагинов, в том числе хорошо известный инструментарий – Java Development Tools (JDT).

Eclipse также включает в себя среду разработки плагинов (PDE), которая в первую очередь заинтересует тех, кто хочет расширить сам Eclipse, так как позволяет создавать свои инструменты, встраиваемые в среду Eclipse.

Хотя Eclipse написан на Java, использовать его можно и с другими языками. К примеру, уже имеются (или разрабатываются) плагины, поддерживающие такие языки программирования как C/C++ и COBOL. Структура Eclipse может также использоваться как основа для других типов приложений, не имеющих отношения к разработке ПО, например, систем управления контентом. В частности, на основе Eclipse было создано ПО IBM Rational Software Architect, которое легло в основу семейства инструментов IBM для разработки на Java.

Проект Eclipse был создан в 2001 г. компанией IBM и поддержан консорциумом поставщиков программного обеспечения. Сегодняшнее сообщество Eclipse состоит из частных лиц и организаций, представляющих индустрию ПО, в котором участвует более 100 компаний.

Eclipse распространяется в рамках лицензии EPL – Eclipse Public License (Открытая лицензия Eclipse) V1.0, одобренной OSI и нацеленной на то, чтобы облегчить коммерческое признание Eclipse, при этом сохраняя лояльность к авторам исходного кода. Тем не менее, Eclipse доступен бесплатно.

В дополнение к плагинам типа JDT, предназначенным для редактирования, компиляции и отладки приложений, имеются плагины, поддерживающие весь процесс разработки: моделирование, автоматизацию построения, тестирование модулей, тестирование производительности, управление версиями и конфигурацией. Например, Eclipse содержит плагин для работы с Системой параллельных версий (CVS, Concurrent Versions System) для управления исходным кодом. Плагин Team (Команда) соединяется с CVSсервером, позволяя членам команды разработчиков работать с набором файлов, содержащих исходные тексты, не вмешиваясь в изменения, вносимые другими. На странице [Eclipse] имеется достаточно полный каталог доступных плагинов.

Формирование коллекций лучших практик, принципов и моделей, методически и идеологически объединяющих отдельные корпоративные решения с целью поддержки полного ЖЦ разрабатываемого ПО ITIL (Information Technology Infrastructure Library) ([Безмалый]; см. также раздел 3.1.3) создано как руководство по управлению предоставлением IT-услуг. Изложенный в данной библиотеке руководящих документов подход приемлем как для фирм, непосредственно работающих в области информационных технологий, так и для IT-подразделений, оказывающих подобные услуги собственному предприятию. ITIL имеет следующие преимущества: 1) данное руководство является независимым от конкретного производителя IТуслуг; 2) у него нет зарегистрированного собственника, что позволяет свободно использовать ITIL в любых условиях; 3) рекомендации согласованы между собой и охватывают весь цикл предоставления IT-услуг. Описываемая методология системно представляет каждый процесс как в его особенностях, так и во взаимосвязи с остальными.

Публикации (методики) ITIL содержат 2 группы: Поддержка услуг (Service Support) и Поставка услуг (Service Delivery), в среде которых рассматриваются 10 фундаментальных процессов:

Поддержка услуг (Service Support) Управление инцидентами (Incident Management).

Управление проблемами (Problem Management) Управление изменениями (Change Management) Управление конфигурациями (Configuration Management) Управление релизами (Release Management) Поставка услуг Service (Delivery) Управление доступностью (Availability Management) Управление мощностью (Capacity Management) Управление финансами (Financial Management) Управление услугами (Service Level Management) Управление сервисом (IT Service Continuity Management) Кроме того, существует еще целый ряд дополнительных публикаций.

ITIL не перекрывает все вопросы управления IT-предприятием (подразделением). Например, вопросы управления и разработки проектов должны рассматриваться в сочетании с другими методиками других методик, скажем, COBIT или ICCMM (примеры приведены в разделах 2.7.4, 3.1.3).

Ряд крупных фирм на основе ITIL разработали собственные рекомендации, совместимые с данной библиотекой, в том числе:

НР в развитие ITIL предложила более прикладную методологию – HP ITSM (Reference Model). Она описывает подходы к выполнению проектов, типовые решения и шаблоны. При этом свободно не распространяется и используется в самой НР, в частности, являясь методологической основой известного программного пакета HP OpenView ServiceDesk.

Подобную работу с ITIL провела и IBM, хотя существует и собственная разработка корпорации Information Management System (IMS).

Microsoft создала программу Microsoft Enterprise Services в составе Microsoft Solutions Frameworks (MSF), Microsoft Readiness Framework (MRF) и Microsoft Operations Framework (MOF). Как отмечалось на презентации MOF, «Мы взяли ITIL, независимую от технологий, и применили ее к платформе Microsoft для предоставления IT-услуг в гетерогенных средах».

MOF (Microsoft Operations Framework) [MOF] – это совокупность принципов и моделей, направленных на совершенствование руководства операциями. Областями применения MOF являются рабочие станции и серверные платформы, обновление ПО, мониторинг, масштабирование и миграция на новые платформы, безопасность, использование IT в малом и среднем бизнесе, организация инфраструктуры в филиалах, обновление и консолидация.

MOF состоит из набора статей (white papers), руководств (operations guides), служб, материалов, курсов и включает в себя не только модель процессов (MOF Process Model);, как это было в ITIL, но также модель команд исполнителей (MOF Team Model) и модель рисков (MOF Risk Model).

Модель процессов (рис. 3.10) включает в себя четыре составляющие.

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

Рис. 3.10. Модель процессов MOF Модель процессов MOF поддерживается двадцатью сервисными функциями управления (Service Management Functions, SMFs). В нее входят все модули ITIL, а кроме того – описание процесса управления рабочей силой (Workforce Management), т.е. поддержку кадровой политики. Модель процессов MOF строится вокруг выпуска и жизненного цикла отдельного решения по обслуживанию (например, разработанного приложения или развернутой инфраструктуры), тогда как ITIL ориентирована на уровень IT-операций в целом.

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

Рис. 3.11. Ролевая структура модели команды MOF Модель рисков MOF (рис. 3.12) основана на том, что превентивные действия по управлению рисками заложены в каждую операционную роль и ITпроцесс, а персонал, выполняющий IT-операции, обладает навыками управления рисками для часто возникающих проблем. Необходимые для этого шаги также подробно описаны в модели. Тем самым управление рисками интегрировано в каждодневную работу операционного IT-персонала.

Рис. 3.12. Модель рисков MOF Системы управления документами широко представлены на рынке, и их динамика отслеживается в сети Интернет (см., например, [СЭД]). Аналитические обзоры позволяют выделить следующие тенденции развития этого рынка:

насыщение потребности в области классического делопроизводства;

развитие рынка BPM (Business Process Management);

появление отраслевых стандартов;

декомпозиция системы, компоненты от независимых производителей;

вторичный рынок готовых решений на базе платформ;

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

Канцелярии – Дело, Кодекс, LanDocs, Евфрат?

Наборы приложений – PayDocs, NauDoc Архивы – Саперион, LanDocs, Эффектофисс Lotus Notes + Company Media, БОСС-референт Платформы – Documentum, Hummingbird (НВ) Платформы с Российской спецификой (готовое решение) – DocsVision, Директум, Оптима, Евфрат?

Инфраструктура Инструменты Рис. 3.13. Сравнение различных систем документооборота Системы Workflow, представленные на рынке, существенно различаются по уровню детализации моделируемых процессов – от систем, ориентированных на поддержку высокоуровневых процессов предприятия (примеры представлены в табл. 3.4 [5 шагов]), до низкоуровневых инструментов, предназначенных для программистов. К числу последних относится Microsoft Windows Workflow Foundation.

Таблица 3.4. Сравнение систем управления потоками работ Workflow цифровая подпись ФАПСИ лицензия № 107) документов по маршруту Редактор маршрутных Графический Графический Графический Графический технологических этапов даря рабочего времени венной схемы документооборота схемы документооборота документов тов (картотека атрибутам регистр.

нормативных значений новки/снятия с Контроля полнителей новке на контроль нении этапа чении сроков исполнения тупа пользователей системном журнале Технология Microsoft Windows Workflow Foundation была анонсирована как «движок» для процессов, модель для программирования и набор инструментов для разработчиков, позволяющий быстро создавать приложения с функциями управления процессами. Windows Workflow Foundation — это набор действий (activities), координирующих исполнителей заданий с приложениями и другими программными компонентами корпоративных информационных систем, а также набор библиотек.NET 3.0, реализующих базовые интерфейсы среды исполнения (Runtime) процесса, «собранного» из этих действий. Среда исполнения процесса обеспечивает:

последовательность выполнения activities;

нотификацию, обработку событий, запуск и остановку процесса;

инфраструктуру для временного хранения окружения процесса.

В интерпретации Workflow Foundation [msdn] рабочие процессы (Workflow) обеспечивают механизм моделирования и реализации бизнеспроцесса как последовательности операций, которые управляют взаимодействием людей и серверных систем для выполнения бизнес-функции. Бизнеспроцессы, понимаемые как бизнес-приложения, требуют активного участия человека и обычно выполняются длительное время, поскольку осуществляется сложная координация многих сущностей. Рабочие процессы, применяемые для реализации таких бизнес-процессов, служат механизмом координации, агрегации и распределения бизнес-данных.

Поскольку бизнес-процессы по своей природе являются распределенными, имеет смысл развертывать рабочий процесс как распределенное приложение. Чтобы поддерживать такую функциональность, группа разработки Windows Workflow Foundation выбрала веб-сервисы и IIS в качестве хостплатформы, на которой в предварительной версии.NET Framework 3.0 выполняются приложения распределенного рабочего процесса. В ближайшем будущем появится встроенная поддержка Windows Communication Foundation.

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

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

Сочетание этих двух технологий позволяет представлять бизнеспроцессы как веб-сервисы. Благодаря этим технологиям можно создавать макро-веб-сервисы, определяющие бизнес-взаимодействия, применять политики «гидратации» и «дегидратации» рабочего процесса (workflow hydration and dehydration policies) для поддержки веб-сервисов, хранящих информацию о состоянии, и обеспечивать мониторинг. Еще одно преимущество – возможность указать, что операцию требуется выполнить по завершении запроса к веб-сервису. Это позволяет продолжать выполнение запроса к веб-сервису без прямого запроса от клиента веб-сервиса в некое заранее определенное время. Эта функциональность позволяет реализовать эскалацию (escalation) и задание периодов ожидания. Кроме того, декларативная природа определения рабочего процесса позволяет реализовать полностью декларативную бизнес-логику.

В заключение отметим, что технология Microsoft Windows Workflow Foundation интегрируется и в другие ПП обсуждаемой сферы. Например, в архитектуре системы управления документами и бизнес-процессами DocsVision [DocsVision] выделен особый слой, реализующий спецификации Microsoft Windows WorkFlow Foundation.