Основа понятия руководство по

        ё

Раздаточный материал

для команды по разработке ПО

В рамках курса «Технология разработки программного обеспечения» выделены следующие роли в группе по разработке ПО:

• Руководитель – общее руководство проектом, написание документации, общение с заказчиком ПО
• Системный аналитик – разработка требований (составление технического задания, проекта программного обеспечения)
• Тестер – составление плана тестирования и аттестации готового ПО (продукта), составление сценария тестирования, базовый пример, проведение мероприятий по плану тестирования
• Разработчик – моделирование компонент программного обеспечения, кодирование

План проекта:

1. Введение. Краткое описание целей проекта и проектных ограничений (бюджетных, временных и т.д.), которые важны для управления проектом.
2. Организация выполнения проекта. Описание способа подбора команды разработчиков и распределение обязанностей между членами команды.
3. Анализ рисков. Описание возможных проектных рисков, вероятности их проявления и стратегий, направленных на их уменьшение.
4. Аппаратные и программные ресурсы, необходимые для реализации проекта. Перечень аппаратных средств и программного обеспечения, необходимого для разработки программного продукта. Если аппаратные средства требуется закупать, приводится их стоимость совместно с графиком закупки и поставки.
5. Разбиение работ на этапы. Процесс реализации проекта разбивается на отдельные процессы, определяются этапы выполнения проекта, приводится описание результатов («выходов») каждого этапа и контрольные отметки.
6. График работ. В этом графике отображаются зависимости между отдельными процессами (этапами) разработки ПО, оценки времени их выполнения и распределение членов команды разработчиков по отдельным этапам.
7. Механизмы мониторинга и контроля за ходом выполнения проекта. Описываются предоставляемые менеджером отчеты о ходе выполнения работ, сроки их предоставления, а также механизмы мониторинга всего проекта.

Рисунок 1  График работ

Временные и сетевые диаграммы

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

Рассмотрим этапы некоего проекта, представленные в таблице 1, из которой, в частности, видно, что этап Т3 зависит от этапа Т1. Это значит, что этап Т1 должен завершиться прежде, чем начнется этап Т3. Например, на этапе Т1 проводится компонентный анализ создаваемого программного продукта, а на этапе Т3 — проектирование системы.

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

Таблица 1 – Этапы проекта

Этап	Длительность (дни)	Зависимость	Этап	Длительность (дни)	Зависимость
Т1	8		Т7	20	Т1 (М1)
Т2	15		Т8	25	Т4 (М5)
Т3	15	Т1 (М1)	Т9	15	Т3, Т6 (М4)
Т4	10		Т10	15	Т5, Т7 (М7)
Т5	10	Т2, Т4 (М2)	Т11	7	Т9 (М6)
Т6	5	Т1, Т2 (М3)	Т12	10	Т11 (М8)

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

Любой этап не может начаться, пока не выполнены все этапы на всех путях, ведущих от начала проекта к данному этапу. Например, этап Т9 не может начаться, пока не будут завершены этапы ТЗ и Т6. Отметим, что в данном случае достижение контрольной отметки М4 говорит о том, что эти этапы завершены.

Минимальное время выполнения всего проекта можно рассчитать, просуммировав в сетевой диаграмме длительности этапов на самом длинном пути (длина пути здесь измеряется не количеством этапов на пути, а суммарной длительностью этих этапов) от начала проекта до его окончания (это так называемый критический путь). В нашем случае продолжительность проекта составляет 11 недель или 55 рабочих дней. На рисунке 2 критический путь показан более толстыми линиями, чем остальные пути. Таким образом, общая продолжительность реализации проекта зависит от этапов работ, находящихся на критическом пути. Любая задержка в завершении любого этапа на критическом пути приведет к задержке всего проекта.

Рисунок 2 – Сетевая диаграмма этапов

Задержка в завершении этапов, не входящих в критический путь, не влияет на продолжительность всего проекта до тех пор, пока суммарная длительность этих этапов (с учтом задержек) на каком-нибудь пути не превысит продолжительности работ на критическом пути. Например, задержка этапа Т8 на срок, меньший 20 дней, никак не влияет на общую продолжительность проекта. На рисунке 3 представлена временная диаграмма, на которой показаны возможные задержки на каждом этапе.

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

Рисунок 3 – Временная диаграмма длительности этапов

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

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

Таблица 2 – Распределение исполнителей по этапам

Этап	Исполнитель	Этап	Исполнитель	Этап	Исполнитель
Т1	Джейн	Т5	Мэри	Т9	Джейн
Т2	Анна	Т6	Анна	Т10	Анна
Т3	Джейн	Т7	Джим	Т11	Фред
Т4	Фред	Т8	Фред	Т12	Фред

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

Рисунок 4 – Временная диаграмма распределения работников по этапам

Разработать информационную систему туристического агентства.

1. Общие сведения.

1.1.        Наименование системы

Полное наименование: Информационная система туристического агентства. Краткое наименование: ИС-Турагент.

1.2.        Основания для проведения работ

Работа выполняется на основании договора №1254 от 01.10.2013 г. между турагентством «Орфей» и ООО «Арсенал».

1.3.        Наименование организаций – Заказчика и Разработчика

Заказчик: Турагентство «Орфей». Адрес фактический: г. Москва, Пр. Мира 110. Телефон / Факс: +7 (495) 123-45-66

Разработчик: ООО «Арсенал». Адрес фактический: г. Москва, Ленинградский пр. 78. Телефон / Факс: +7 (495) 321-55-87

1.4.        Плановые сроки начала и окончания работы

Начало работы: 01.10.2013 г.

Окончание работы: 31.12.2013 г.

Календарный план работ приведен в приложении.

1.5.        Источники и порядок финансирования

Финансирование осуществляется в соответствии с договором   №1254 от 01.10.2013 г.

1.6.        Порядок оформления и предъявления заказчику результатов работ

Работы по созданию ИС-Турагент сдаются Разработчиком поэтапно в соответствии с календарным планом Проекта. По окончании каждого из этапов работ Разработчик сдает Заказчику соответствующие отчетные документы этапа, состав которых определены Договором.

2.        Назначение и цели создания системы

2.1.        Назначение системы

Основным назначением «ИС-Турагент» является автоматизация информационно-аналитической деятельности в бизнес-процессах Заказчика. В рамках проекта автоматизируется информационно-аналитическая деятельность в следующих бизнес-процессах:

1. Ведение базы договоров с туроператорами (закупка товаров).

1. Ведение базы турпакетов, предлагаемых туроператорами (характеристика товара).
2. Ведение базы клиентов (покупателей).
3. Ведение базы заказов от клиентов (продажа товаров).
4. Составление итоговых отчетов о деятельности компании.

2.2.        Цели создания системы.

ИС-Турагент создается с целью:

• повышения качества выполнения основных бизнес-процессов компании;
• сокращения времени на выполнение основных бизнес-процессов;
• создания единой системы отчетности по показателям деятельности.

3.        Характеристика объектов автоматизации

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

дующие позиции: название страны, город, отель, длительность пребывания, варианты авиаперелета.

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

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

Структурное подразделение	Наименование процесса	Возможность автоматизации	Решение об автоматизации в ходе проекта
Отдел работы с туроператорами	Ведение БД договоров с туроператорами	Возможна	Будет автоматизирован
Отдел работы с клиентами	Ведение БД клиентов	Возможна	Будет автоматизирован
Отдел работы с предложениями туроператоров	Ведение БД тур-пакетов	Возможна	Будет автоматизирован
Отдел работы с заказами	Ведение БД заказов	Возможна	Будет автоматизирован
Отдел работы с отчетами	Составление отчетов	Возможна	Будет автоматизирован

4. Требования к системе

4.1. Требования к системе в целом

4.1.1. Требования к структуре   и функционированию системы

4.1.1.1. Перечень подсистем, их назначение и основные характеристики.

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

В Системе предлагается выделить следующие функциональные подсистемы:

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

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

В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP.

Для организации доступа пользователей к системе должен использоваться протокол презентационного уровня HTTP и его расширение HTTPS.

4.1.1.3.Требования к режимам функционирования системы.

Для ИС-Турагент определены следующие режимы функционирования:

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

В основном режиме функционирования системы:

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

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

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

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

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

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

4.1.1.4.Требования по диагностированию системы.

Требования не предъявляются.

4.1.2. Требования к численности и квалификации персонала системы и режиму его работы

4.1.2.1. Требования к численности персонала

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

В состав персонала, необходимого для обеспечения эксплуатации ИС-Турагент в рамках соответствующих подразделений Заказчика, необходимо выделение следующих ответственных лиц:

администратор системы ИС-Турагент — 1 человек.

4.1.2.2. Требования к квалификации персонала

К квалификации персонала, эксплуатирующего Систему ИС-Турагент, предъявляются следующие требования:

• конечный пользователь — знание соответствующей предметной области; знания и навыки работы с Web-приложениями;
• администратор системы — знание методологии проектирования баз данных; знание СУБД; знание языка запросов SQL.

4.1.2.3. Требования к режимам работы персонала

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

4.1.3. Показатели назначения

Система должна обеспечивать возможность исторического хранения

данных с глубиной не менее 10 лет.

Система должна обеспечивать возможность одновременной работы 10 пользователей.

Время отклика системы для операций навигации по экранным формам системы не должно превышать 5 сек, для операций формирования справок и выписок — не более 10 сек.

Время формирования аналитических отчетов определяется их сложностью и может занимать продолжительной время.

4.1.4. Требования к надежности

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

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

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

4.1.5. Требования к эргономике и технической эстетике

В части внешнего оформления:

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

В части диалога с пользователем:

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

4.1.6. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

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

Технические средства Системы и персонал должны размещаться в существующих помещениях Заказчика, которые по климатическим условиям должны соответствовать ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды» (температура окружающего воздуха от 5 до 40 °С, относительная влажность от 40 до 80 % при Т=25 °С, атмосферное давление от 630 до 800 мм ртутного столба).

Размещение технических средств и организация автоматизированных рабочих мест должны быть выполнены в соответствии с требованиями ГОСТ 21958-76 «Система «Человек-машина».

Для электропитания технических средств должна быть предусмотрена трехфазная четырех-проводная сеть с глухо заземленной нейтралью 380/220 В (+10-15)% частотой 50 Гц (+1-1) Гц. Каждое техническое средство запиты-вается однофазным напряжением 220 В частотой 50 Гц через сетевые розетки с заземляющим контактом.

Для обеспечения выполнения требований по надежности должен быть создан комплект запасных изделий и приборов (ЗИП).

Состав, место и условия хранения ЗИП определяются на этапе технического проектирования.

4.1.7. Требования к защите информации от несанкционированного доступа

4.1.7.1. Требования к информационной безопасности

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

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

4.1.7.2. Требования к антивирусной защите

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

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

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

4.1.8.        Требования по сохранности информации при авариях

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

4.1.9.        Требования к защите от влияния внешних воздействий

Применительно к программно-аппаратному окружению Системы предъявляются следующие требования к защите от влияния внешних воздействий:

• электромагнитное излучение радиодиапазона, возникающее при работе электробытовых приборов, электрических машин и установок, приёмопередающих устройств, эксплуатируемых на месте размещения АПК Системы, не должны приводить к нарушениям работоспособности подсистем.
• Система должна иметь возможность функционирования при колебаниях напряжения электропитания в пределах от 155 до 265 В (220 ± 20 % — 30 %);
• Система должна иметь возможность функционирования в диапазоне допустимых температур окружающей среды, установленных изготовителем аппаратных средств.
• Система должна иметь возможность функционирования в диапазоне допустимых значений влажности окружающей среды, установленных изготовителем аппаратных средств.
• Система должна иметь возможность функционирования в диапазоне допустимых значений вибраций, установленных изготовителем аппаратных средств.

4.1.10.        Требования по стандартизации и унификации

Разработка системы должна осуществляться с использованием стандартных методологий функционального моделирования: IDEF0, DFD и информационного моделирования IE и IDEF1Х в рамках рекомендаций по стандартизации Р50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования».

Моделирование должно выполняться в рамках стандартов, поддерживаемых программными средствами моделирования ERWin 4.х и BPWin 4.х. Для работы с БД должен использоваться язык запросов SQL в рамках стандарта ANSI SQL-92.

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

4.1.11.        Дополнительные требования

Требования не предъявляются.

4.1.12. Требования безопасности

Требования не предъявляются.

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

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

• ввод и редактирование данных о туроператоре;
• ввод и редактирование данных о турпакетах;
• оформление договоров с туроператорами;
• формирование отчетов.

1. Временной регламент реализации каждой функции, задачи.
2. Требования к качеству реализации функций, задач.
3. Перечень критериев отказа для каждой функции

4.2.2.        Подсистема ведения базы данных клиентов.

Подсистема должна состоять из следующих модулей:

• ввод данных о клиенте;
• редактирование данных о клиентах;
• удаление данных о клиентах.

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

Подсистема должна состоять из следующих модулей:

ввод и редактирование данных о стране;

ввод и редактирование данных о городах;

ввод и редактирование данных об отелях;

ввод и редактирование данных о видах размещения в отелях;

ввод и редактирование данных об авиарейсах.

4.2.4.        Подсистема ведения базы заказов.

Подсистема должна состоять из следующих модулей:

• заполнение и редактирование листа бронирования;
• оформление договора с клиентом;
• оформление заказа;

• сопровождение процесса приема-выдачи документов и процесса оплаты тура.

4.3. Требования к видам обеспечения

4.3.1 Требования к математическому обеспечению

Требования не предъявляются.

4.3.2. Требования к информационному обеспечению

4.3.2.1.        Требования к составу, структуре и способам организации данных в системе.

Модель данных Системы физически должна быть реализована в реляционной СУБД .

4.3.2.2.        Требования к информационному обмену между компонентами системы

Требования не предъявляются.

4.3.2.3.        Требования к информационной совместимости со смежными системами

Требования не предъявляются.

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

Основные классификаторы и справочники в системе (клиенты, туроператоры, турпакеты) должны быть едиными.

4.3.2.5.        Требования по применению систем управления базами данрых.

Для реализации хранения данных должна использоваться СУБД MySQL.

4.3.2.6. Требования к структуре процесса сбора, обработки, передачи данных в системе и представлению данных

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

4.3.2.7.        Требования к защите данных от разрушений при авариях и сбоях в электропитании системы

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

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

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

4.3.2.8.        Требования к контролю, хранению, обновлению и восстановлению данных

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

К хранению и восстановлению данных предъявляются следующие требования:

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

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

Требования не предъявляются.

4.3.3.        Требования к лингвистическому обеспечению

При реализации системы должны применяться следующие языки высокого уровня: PHP, SQL и встроенные средства диалогового взаимодействия BI приложения HTML.

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

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

Для описания предметной области (объекта автоматизации) должен использоваться Erwin.

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

4.3.4.        Требования к программному обеспечению

СУБД должна иметь возможность установки на ОС Windows XP и более поздние версии.

К обеспечению качества ПС предъявляются следующие требования:

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

4.3.5. Требования к техническому обеспечению

Сервер базы данных должен быть развернут на HP9000 SuperDome №1, минимальная конфигурация которого должна быть: CPU: 16 (32 core); RAM: 128 Gb; HDD: 500 Gb; Network Card: 2 (2 Gbit).

Сервер приложений должен быть развернут на платформе HP Integrity, минимальная конфигурация которого должна быть: CPU: 6 (12 core); RAM: 64 Gb; HDD: 300 Gb; Network Card: 3 (1 Gbit).

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

4.3.6.        Требования к метрологическому обеспечению

Требования не предъявляются.

4.3.7.        Требования к организационному обеспечению

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

• расписанием Заказчика, которое, в случае необходимости, может изменяться. К организации функционирования Системы и порядку взаимодействия персонала, обеспечивающего эксплуатацию, и пользователей предъявляются следующие требования:
• в случае возникновения со стороны функционального подразделения необходимости изменения функциональности системы, пользователи должны действовать следующим образом <описать, что должны делать пользователи (кому писать, звонить, идти) в случае необходимости доработки системы>;
• подразделение, обеспечивающее эксплуатацию системы, должно заранее (не менее чем за 3 дня) информировать всех пользователей (с указанием точного времени и продолжительности) о переходе её в профилактический режим.

К защите от ошибочных действий персонала предъявляются следующие требования:

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

4.3.8.        Требования к методическому обеспечению

В состав нормативно-правового и методического обеспечения системы

должны входить следующие законодательные акты, стандарты и нормативы:

• ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.
• ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы.

4.3.9.        Требования к патентной чистоте

Требования не предъявляются.

5. Состав и содержание работ по созданию системы

Работы по созданию системы выполняются в три этапа:

• Проектирование. Разработка эскизного проекта. Разработка технического проекта.
• Разработка рабочей документации. Адаптация программ.
• Ввод в действие.

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

6.        Порядок контроля и приёмки системы

6.1. Виды и объем испытаний системы

Система подвергается испытаниям следующих видов:

1. Предварительные испытания.
2. Опытная эксплуатация.
3. Приемочные испытания.

Состав, объем и методы предварительных испытаний системы определяются документом «Программа и методика испытаний», разрабатываемым на стадии «Рабочая документация».

Состав, объем и методы опытной эксплуатации системы определяются документом «Программа опытной эксплуатации», разрабатываемым на стадии «Ввод в действие».

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

6.2. Требования к приемке работ по стадиям

Приемка работ проводится комиссией в составе: представитель от заказчика и один представитель от исполнителя.

7.        Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

Требования не предъявляются.

8. Требования к документированию

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

Этап	Документ
Проектирование. Разработка эскизного проекта. Разработка технического проекта.	Ведомость эскизного проекта Пояснительная записка к эскизному проекту
Ведомость технического проекта Пояснительная записка к техническому проекту
Схема функциональной структуры
Разработка рабочей документации. Адаптация программ	Ведомость эксплуатационных документов Ведомость машинных носителей информации Паспорт Общее описание системы Технологическая инструкция
Руководство пользователя
Описание технологического процесса обработки данных (включая телеобработку) Инструкция по формированию и ведению базы данных (набора данных) Состав выходных данных (сообщений)
Каталог базы данных
Программа и методика испытаний Спецификация Описание программ Текст программ
Ввод в действие	Акт приёмки в опытную эксплуатацию Протокол испытаний Акт приемки Системы в промышленную эксплуатацию Акт завершения работ

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

9. Источники разработки

Настоящее Техническое Задание разработано на основе следующих документов и информационных материалов:

1. Договор   №1254 от 01.10.2013 г. между турагентством «Орфей» и ООО «Арсенал».
2. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.
3. ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы.
4. ГОСТ 24.701-86 «Надежность автоматизированных систем управления».

«Забытые» парадигмы программирования

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

Ладно. Введение это очень весело, но вы его все равно не читаете, так что кому интересно — добро пожаловать под кат!

Императивное программирование

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

Это были машинные коды, языки ассемблера и ранние высокоуровневые языки, вроде Fortran.

Ключевые моменты:

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

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

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

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

Основные понятия:

— Инструкция
— Состояние

Порожденные понятия:

— Присваивание
— Переход
— Память
— Указатель

Языки поддерживающие данную парадигму:

Как основную:

— Языки ассемблера
— Fortran
— Algol
— Cobol
— Pascal
— C
— C++
— Ada

Как вспомогательную:

— Python
— Ruby
— Java
— C#
— PHP
— Haskell (через монады)

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

Структурное программирование

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

Основоположниками структурного программирования были такие знаменитые люди как Э. Дейкстра и Н. Вирт.

Языками-первопроходцами в этой парадигме были Fortran, Algol и B, позже их приемниками стали Pascal и C.

Ключевые моменты:

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

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

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

Иногда goto все-же делает код читабельнее, благодаря чему он до сих пор широко используется, несмотря на все заявления его противников.

Основные понятия:

— Блок
— Цикл
— Ветвление

Языки поддерживающие данную парадигму:

Как основную:

— C
— Pascal
— Basic

Как вспомогательную:

— C#
— Java
— Python
— Ruby
— JavaScript

Поддерживают частично:
— Некоторые макроассемблеры (через макросы)

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

Процедурное программирование

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

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

Этим понятием на этот раз была процедура.

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

Ключевые моменты:

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

В современном программировании процедура может иметь несколько точек выхода (return в C-подобных языках), несколько точек входа (с помощью yield в Python или статических локальных переменных в C++), иметь аргументы, возвращать значение как результат своего выполнения, быть перегруженной по количеству или типу параметров и много чего еще.

Основные понятия:

— Процедура

Порожденные понятия:

— Вызов
— Аргументы
— Возврат
— Рекурсия
— Перегрузка

Языки поддерживающие данную парадигму:

Как основную:

— C
— C++
— Pascal
— Object Pascal

Как вспомогательную:

— C#
— Java
— Ruby
— Python
— JavaScript

Поддерживают частично:
— Ранний Basic

Стоит отметить, что несколько точек входа из всех этих языков поддерживаются только в Python.

Модульное программирование

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

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

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

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

Ключевые моменты:

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

Например файл List.mod включающий в себя класс List
и функции для работы с ним — модуль.

Папка Geometry, содержащая модули Shape, Rectangle и Triangle — тоже модуль, хоть и некоторые языки разделяют понятие модуля и пакета (в таких языках пакет — набор модулей и/или набор других пакетов).

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

Основные понятия:

— Модуль
— Импортирование

Порожденные понятия:

— Пакет
— Инкапсуляция

Языки поддерживающие данную парадигму:

Как основную:

— Haskell
— Pascal
— Python

Как вспомогательную:

— Java
— C#
— ActionScript 3

Поддерживают частично:
— C/C++

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

Вместо заключения

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

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

©
2008+, Рахматуллин А.И.

Министерство образования и науки
Российской Федерации

КАЗАНСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ
УНИВЕРСИТЕТ
им. А.Н. ТУПОЛЕВА

Кафедра прикладной математики и
информатики им. Ю.В. Кожевникова

А.И. РАХМАТУЛЛИН, Д.С. ГУЩИНА

ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНЫХ
СИСТЕМ

Комплексное учебное пособие

Казань 2008

Содержание

Введение 3

Раздел 2. Методология
разработки ПО 17

Раздел 3. Технология
разработки ПО 31

Раздел 4. Подходы
разработки ПО 70

Раздел 5. Инженерия
и инструментарий ПО 146

Раздел 6.
Методические указания 152

6.1. Лабораторные
работы 152

6.2. Курсовая
работа 225

6.3. Самостоятельная
работа студентов 244

6.4. Примерные
тестовые задания 255

Литература 261

Введение

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

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

Изложение
материала дисциплины ведётся аналогично
изложению, принятому в пособии [1]
с учётом особенностей дисциплины. Для
получения дополнительной информации
по данной дисциплине рекомендуются
пособия [2,3],
а также словарь-справочник [4]
и книга [5].

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

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

Раздел1. Основы разработки по

В данном
разделе рассматриваются основные
понятия и определения, необходимые для
ясного понимания всего материала
дисциплины.

1.1. Основные понятия и определения

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

Система– совокупность взаимодействующих
единиц – элементов, функционирующих
совместно для достижения определённых
целей.Элемент–
относительно самостоятельная структурная
«единица» системы.

Части
системыпредставляют собой
определённые группы элементов этой
системы.Компонент–
часть системы, выполняющая одну /
несколько её функций.Модуль– отдельный компонент / группа компонентов,
обеспечивающая одну / ряд функций для
работы других модулей и, в свою очередь,
использующая функции, обеспечиваемые
иными модулями.Подсистема– часть системы, функции которой
относительно независимы от функций
остальных частей системы.Подсистема– это система, являющаяся частью
рассматриваемой системы, анадсистема– это система, частью которой является
рассматриваемая система.

Процессный
подход является составной частью
системного подхода.

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

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

Понятия
«система» и «процесс» тесно связаны:
система выполняет некоторый процесс,
процесс представляет собой функционирование
некоторой системы.

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

В
разработке ПО оба понятия «система» и
«процесс» играют существенную роль,
позволяя рассматривать её с использованием
системного подхода, а также грамотно
осуществлять управление разработкой
ПО.

Основными
понятиями программирования являются
алгоритм и программа.

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

Программа– формализованное описание алгоритма
для его выполнения на компьютере. Из-за
наличия других смыслов и значений
понятия «программа» в настоящее время
используют понятиекомпьютерная
программа.

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

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

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

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

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

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

Наиболее
общим рассматриваемым понятием является
система. С точки зрения разработки
система включает в себя вычислительные
системы, персонал и т.д. Таким образом,
система является более ёмким понятием,
чем ПО: оно включает в себя ещё и окружение,
в котором функционирует ПО, как таковое.

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

С
организационной и экономической точек
зрения наиболее часто используют понятия
«прототип» и «программный продукт».

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

Кроме
продукта (результата человеческого
труда) интерес представляет и услуга
(участие по оказанию помощи в деятельности).
Услуга(тж. сервис) –
деятельность по оказанию помощи в
эксплуатации продукта.

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

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

С
решением тесно связаны два важнейших
понятия – «проект» и «команда».

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

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

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

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

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

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

Если
конкретный результат не указан, обычно
говорят о процессе разработки.

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

Продукт
можно рассматривать аналогично живому
организму: он имеет жизненный
цикл(ЖЦ), который начинается с
«зарождения» (возможно, с зарождения
замысла / идеи) и заканчивается его
«смертью» (изъятием из употребления).
Концепция ЖЦ оказывается чрезвычайно
полезной при управлении проектом.

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

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

Рис.1.1.
Взаимосвязь жизненных циклов

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

Несмотря на свою уникальность, всеобъемлемость, универсальность и важность затрагиваемых вопросов, COBIT производит весьма неоднозначное впечатление.

Занятый подготовкой учебного курса по аудиту безопасности информационных систем, автор не смог обойти вниманием стандарт COBIT, ориентированный, прежде всего, на руководство организаций, ИТ-аудиторов и регламентирующий вопросы управления информационными технологиями. COBIT является синтезом четырех десятков международных стандартов де-юре и де-факто. Его задача — ликвидация разрыва между руководством организации с их видением бизнес-целей и ИТ-департаментом, осуществляющим поддержку информационной инфраструктуры организации, которая должна работать на достижение этих целей. Стремление сделать стандарт как можно более универсальным и не зависящим ни от технических платформ, ни от отраслевых особенностей возводит его создателей на столь высокий уровень абстракции, с которого порой перестает быть виден предмет изучения. Несмотря на свою уникальность, всеобъемлемость, универсальность и важность затрагиваемых вопросов, COBIT производит весьма неоднозначное впечатление.

Данная статья рассматривает основные положения стандарта с точки зрения ИТ-аудитора. Основное внимание уделено изложению «Концептуального ядра COBIT», являющегося основой для понимания всех основных положений стандарта, и «Руководства по аудиту».

Структура и состав документов COBIT

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

Первая версия стандарта была выпущена в 1996 году Организацией аудита и контроля информационных систем (Information Systems Audit and Control Foundation, ISACF). Она включала в себя «Концептуальное ядро» (COBIT Framework), определяющее набор основополагающих принципов и понятий в области управления ИТ, описание «Задач управления» (Control Objectives) и «Руководство по аудиту» (Audit Guideline). Вторая версия COBIT была опубликована в 1998 году. Она содержала переработанную версию высокоуровневых и детальных «Задач управления», дополненных «Набором инструментов внедрения» (Implementation Tool Set). Третья редакция была выпущена уже Институтом управления ИТ (IT Governance Institute), учрежденным Ассоциацией аудита и контроля информационных систем (Information Systems Audit and Control Association, ISACA), совместно с ISACF с целью развития и популяризации принципов управления ИТ; он в настоящее время и является основным разработчиком COBIT. В третьей версии стандарта появилось «Руководство по менеджменту» (Management Guidelines) в основе которого лежит понятие «Система управления ИТ» (IT Governance).

Резюме для руководства

«Резюме для руководства» служит введением в остальные разделы стандарта. Оно содержит общие сведения о стандарте, определяет миссию COBIT и понятие системы управления ИТ.

Эффективное управление ИТ — важнейший фактор для успеха каждой организации. Многие осознают потенциальные выгоды, связанные с использованием высоких технологий, однако только успешные организации способны адекватно оценивать и управлять рисками, связанными с их внедрением. Система управления ИТ, одно из основных понятий в COBIT, в настоящее время признается ключевой частью системы управления предприятием (Enterprise Governance). Система управления ИТ определяется в стандарте как структура взаимоотношений и процессов, задающих направление и осуществляющих управление предприятием для достижения бизнес-целей путем получения добавленной стоимости при наличии баланса между величиной рисков и возвратом инвестиций, сделанных в ИТ.

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

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

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

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

Концептуальное ядро

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

Концептуальное ядро предоставляет владельцу бизнес-процесса инструмент для реализации стратегии управления ИТ. Отправным пунктом является следующее утверждение:

ДЛЯ СВОЕВРЕМЕННОГО И ПОЛНОГО ПОЛУЧЕНИЯ ИНФОРМАЦИИ, НЕОБХОДИМОЙ ОРГАНИЗАЦИИ ДЛЯ ДОСТИЖЕНИЯ БИЗНЕС-ЦЕЛЕЙ, УПРАВЛЕНИЕ ИТ-РЕСУРСАМИ ДОЛЖНО ОСУЩЕСТВЛЯТЬСЯ ПРИ ПОМОЩИ НАБОРА ЕСТЕСТВЕННЫМ ОБРАЗОМ СГРУППИРОВАННЫХ ПРОЦЕССОВ.

Концептуальное ядро COBIT сформировано из набора 34 высокоуровневых задач управления (одна задача для каждого ИТ-процесса), сгруппированных в четыре домена: планирование и организация; комплектование и внедрение; предоставление и поддержка; мониторинг. Такая структура охватывает все аспекты управления и использования ИТ. Выполнение всех 34 задач управления, позволяет гарантировать владельцу бизнес-процесса, что система управления ИТ является адекватной задачам бизнеса.

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

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

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

На основе перечисленных классов требований определяется несколько отчасти пересекающихся категорий бизнес-требований к информации (информационные критерии):

• эффективность (effectiveness) — актуальность и уместность информации для бизнес-процесса, а также ее своевременность, корректность, непротиворечивость и практичность;
• продуктивность (efficiency) — предоставление информации путем оптимального использования ресурсов;
• конфиденциальность (confidentiality) — защищенность информации от несанкционированного раскрытия;
• целостность (integrity) — точность и полнота информации, а также ее обоснованность с точки зрения ценностей и ожиданий бизнеса;
• доступность (availability) — возможность получения необходимой информации в течение времени, определяемого требованиями бизнеса; также включает защиту информации и ее носителей от похищения или уничтожения;
• соответствие (compliance) — соответствие информации законам, распоряжениям и соглашениям, регулирующим бизнес-процессы;
• надежность (reliability) — предоставление руководству информации, пригодной для использования в управлении, для подготовки финансовой и иной отчетности.

Определяются следующие классы ИТ-ресурсов:

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

Например, при реализации ИТ-процесса «управления финансовыми потоками организации при помощи электронных платежных систем», задействованы все виды ИТ-ресурсов, в том числе:

• данные в виде электронных ордеров, электронных ключей, используемых для шифрования и подписи этих ордеров при отправке в банк, выписок о состоянии счетов, полученных из банка, а также бумажные оригиналы этих документов;
• прикладные системы, включающие в себя программное обеспечение «банк — клиент», а также ручные процедуры, связанные с подготовкой, верификацией, подписанием бумажных документов и формирование электронных платежек в системе «банк — клиент»;
• технологии, используемые для реализации электронных платежей, вместе с рабочими местами операторов платежной системы, телекоммуникационным оборудованием (модемы, каналообразующее оборудование и линии связи), операционная система, на базе которой функционирует программное обеспечение системы «банк — клиент», СУБД, используемая для хранения электронных ордеров и квитанций, полученных из банка;
• средства поддержки, включая изолированное помещение, в котором установлен АРМ оператора системы банк-клиент и физические средства контроля доступа в это помещение в виде электронных замков и видеокамер;
• людские ресурсы — сотрудники бухгалтерии организации, выполняющие функции по формированию, верификации, подписанию, отправке электронных ордеров и т. п., а также технические специалисты, отвечающие за администрирование и сопровождение системы «банк — клиент».

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

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

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

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

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

Концептуальное ядро можно рассматривать с трех точек зрения: информационные критерии; ИТ-ресурсы; ИТ-процессы (см. рис. 2).

Рис. 2. Куб COBIT

Остановимся на том, как определяются четыре домена управления, в которые группируются процессы COBIT.

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

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

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

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

Детальные задачи управления

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

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

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

Формулировки задач управления в COBIT носят в максимальной степени абстрактный характер, что делает их независимыми от конкретных платформ и характера деятельности организации. Задачи управления ориентированы на руководство организации, персонал ИТ-департамента, подразделения внутреннего контроля и аудита, а также (что наиболее важно) на владельцев бизнес-процессов. Они предоставляют рабочий справочник для всех субъектов управления и дают четкое определение минимального набора механизмов управления, необходимых для обеспечения эффективности, продуктивности и экономии ресурсов.

Руководство по менеджменту

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

Определяемые в COBIT модели зрелости организации (Maturity Model) позволяют руководству организации дать оценку текущему состоянию ИТ-процессов в сравнении с лучшими примерами в данной отрасли и найти возможности их совершенствования.

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

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

1. На нулевом, самом нижнем уровне о зрелости речь вообще не идет, системы управления ИТ как таковой не существует, а необходимость ее создания не осознается. Наблюдается полное отсутствие управляемых ИТ-процессов. Все ключевые ИТ-роли выполняются «незаменимыми» сотрудниками, часто являющимися «универсалами», мастерами на все руки. Общая стратегия развития ИТ отсутствует. Часто действия «универсалов» между собой не согласованы. При необоснованно завышенных расходах, например, на обеспечение информационной безопасности в такой организации совокупный результат, как правило, близок к нулю. Если зависимость предприятия от ИТ большая, то в такую организацию инвесторам не выгодно вкладывать деньги.
2. В организациях, находящихся на первом уровне зрелости, руководство начинает осознавать необходимость реализации комплексного подхода к управлению ИТ, что вызвано большой зависимостью этих организаций от ИТ и значительными расходами, которые не дают видимых результатов. На этом уровне еще не существует стандартизированных ИТ-процессов и преобладает фрагментарный подход к их реализации. Руководство только начинает задумываться о получении возврата инвестиций, сделанных в ИТ, не располагая, однако, методикой оценки их эффективности. Для решения каждой задачи ИТ-специалистами вырабатываются собственные подходы. Связь между бизнес-целями и деятельностью ИТ-департамента отсутствует. На этом уровне в настоящее время находятся многие российские предприятия, вкладывающие значительные средства в развитие и поддержание работоспособности своих информационных систем.
3. На втором уровне зрелости уже существуют стандартизированные ИТ-процессы, однако они не документированы и пока не являются частью системы управления. Фактически они реализуются в виде стандартной практики отдельных ИТ-специалистов. На этом уровне необходимость планомерного внедрения системы управления ИТ уже ни у кого не вызывает сомнений, активно разрабатываются показатели эффективности ИТ-процессов, внедряются процессы планирования, мониторинга и предоставления ИТ-услуг, устанавливаются взаимосвязи между ИТ и бизнес-процессами, разрабатывается стратегия развития ИТ. Руководство организации принимает активное участие в формировании управляемых ИТ-процессов, для которых уже существуют базовые методы оценки эффективности. Однако сказывается недостаток опыта управления ИТ, используется ограниченное количество механизмов управления и показателей эффективности.
4. Если на предыдущих уровнях зрелости преобладает администратор-«универсал», то, начиная с третьего уровня, доминирующей становится роль системы управления. Здесь все процедуры стандартизированы и документированы, а сотрудники обучены их использованию. Деятельность ИТ-отдела регламентирована этими процедурами. Однако механизмы контроля качества выполнения процедур пока не работают, а сами процедуры далеки от совершенства, и об их оптимизации говорить не приходится.
5. Четвертый уровень зрелости характеризуется наличием системы контроля качества ИТ-процессов. Эта система осуществляет непрерывный мониторинг ИТ-процессов, устанавливает стандарты качества и контролирует соответствие ИТ-процессов данным стандартам. Наличие системы контроля качества позволяет выявлять неэффективно действующие механизмы управления ИТ-системой и постоянно работать над повышением их эффективности. Четвертый уровень — это уровень, на котором существуют управляемые ИТ-системы.
6. На высшем уровне система управления ИТ отличается от предыдущего по существу лишь более высоким уровнем оптимизации ИТ-процессов, которые являются управляемыми и измеряемыми. Информация о выполнении каждого ИТ-процесса фиксируется. ИТ являются эффективным инструментом бизнеса, а система управления ими — одной из составных частей системы управления организацией.

Критические факторы успеха (Critical Success Factor) определяют ориентированные на руководство методы внедрения системы управления ИТ-процессами. Это важнейшие задачи, решение которых способствует достижению целей ИТ-процессов. К числу общих факторов успеха, применимых к любому ИТ-процессу, относятся:

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

Ключевые индикаторы целей (Key Goal Indicator) определяют критерии оценки достижения бизнес-целей при помощи ИТ-процессов. Несколько примеров наиболее общих целей ИТ-процессов: доступность информационных ресурсов, систем и служб; минимизация рисков, связанных с нарушением целостности и конфиденциальности данных; снижение себестоимости ИТ-процессов.

Ключевые индикаторы производительности (Key Performance Indicator) определяют критерии оценки производительности ИТ-процессов в достижении ими бизнес-целей организации. Примерами наиболее общих индикаторов производительности служат: время реакции системы; степень утилизации пропускной способности сети или вычислительных мощностей; повышение качества и совершенствование функциональности информационных служб и т. п.

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

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

Набор инструментов внедрения

«Набор инструментов внедрения» разъясняет ключевые концепции, предлагая пошаговое описание и примеры внедрения.

Процесс внедрения COBIT в деятельность организации выглядит так:

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

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

Руководство по аудиту

Руководство по аудиту (Audit Guideline) позволяет производить проверку реализации каждого из 34 высокоуровневых ИТ-процессов на предмет достижения каждой из 318 детальных задач управления, что дает возможность аудитору гарантировать руководству предприятия адекватность реализованной системы управления ИТ и формировать рекомендации по ее улучшению.

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

Подробное описание схемы и основных подходов к проведению ИТ-аудита в соответствии с требованиями COBIT приводятся в статье автора «Общее руководство по проведению ИТ-аудита в соответствии со стандартом COBIT», которая будет опубликована в следующем номере журнала «Директор ИС».

Выводы

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

В состав третьей редакции COBIT входит несколько книг, в том числе «Резюме для руководства», «Концептуальное ядро», «Руководство по менеджменту», «Руководство по аудиту», «Детальные задачи управления» и «Набор инструментов внедрения».

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

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

Литература

1. COBIT 3rd Edition, Released by the COBIT Steering Committee and the IT Governance Institute, July 2000
2. Астахов А. М., Аудит безопасности информационных систем, ISACA.RU, 2002

Александр Астахов — руководитель отдела защиты информации ОАО «Вимм-Билль-Данн продукты питания», CISA, участник рабочей группы ISACA.RU, AstahovAM@wbd.ru

---

Терминология

Дадим определение нескольким ключевым для COBIT понятиям.

Control (механизм управления)

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

Control Objective (задача управления)

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

COBIT, Control OBjectives for Information and related Technology (задачи управления для информационных и смежных технологий)

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

COBIT Framework (концептуальное ядро COBIT)

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

IT Governance (система управления информационными технологиями)

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

За прекрасную картинку спасибо Toggl.com.

Подготовлено по материалам вебинара «Модели и методологии разработки ПО» Анастасии Кайгородовой, преподавателя факультета тестирования ПО.

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

Этапы жизненного цикла ПО

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

Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.

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

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

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

Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты — оперативно всё исправлять.

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

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

Основные модели разработки ПО

• Code and fix — модель кодирования и устранения ошибок;
• Waterfall Model — каскадная модель, или «водопад»;
• V-model — V-образная модель, разработка через тестирование;
• Incremental Model — инкрементная модель;
• Iterative Model — итеративная (или итерационная) модель;
• Spiral Model — спиральная модель;
• Chaos model — модель хаоса;
• Prototype Model — прототипная модель.

Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.

Waterfall (каскадная модель, или «водопад»)

В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х.

Преимущества «водопада»

• Разработку просто контролировать. Заказчик всегда знает, чем сейчас заняты программисты, может управлять сроками и стоимостью.
• Стоимость проекта определяется на начальном этапе. Все шаги запланированы уже на этапе согласования договора, ПО пишется непрерывно «от и до».
• Не нужно нанимать тестировщиков с серьёзной технической подготовкой. Тестировщики смогут опираться на подробную техническую документацию.

Недостатки каскадной модели

• Тестирование начинается на последних этапах разработки. Если в требованиях к продукту была допущена ошибка, то исправить её будет стоить дорого. Тестировщики обнаружат её, когда разработчик уже написал код, а технические писатели — документацию.
• Заказчик видит готовый продукт в конце разработки и только тогда может дать обратную связь. Велика вероятность, что результат его не устроит.
• Разработчики пишут много технической документации, что задерживает работы. Чем обширнее документация у проекта, тем больше изменений нужно вносить и дольше их согласовывать.

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

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

V-образная модель (разработка через тестирование)

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

Преимущества V-образной модели

• Количество ошибок в архитектуре ПО сводится к минимуму.

Недостатки V-образной модели

• Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».

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

Incremental Model (инкрементная модель)

Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети.

1. Заказчик решил, что хочет запустить соцсеть, и написал подробное техническое задание. Программисты предложили реализовать основные функции — страницу с личной информацией и чат. А затем протестировать на пользователях, «взлетит или нет».
2. Команда разработки показывает продукт заказчику и выпускает его на рынок. Если и заказчику, и пользователям социальная сеть нравится, работа над ней продолжается, но уже по частям.
3. Программисты параллельно создают функциональность для загрузки фотографий, обмена документами, прослушивания музыки и других действий, согласованных с заказчиком. Инкремент за инкрементом они совершенствуют продукт, приближаясь к описанному в техническом задании.

Преимущества инкрементной модели

• Не нужно вкладывать много денег на начальном этапе. Заказчик оплачивает создание основных функций, получает продукт, «выкатывает» его на рынок — и по итогам обратной связи решает, продолжать ли разработку.
• Можно быстро получить фидбэк от пользователей и оперативно обновить техническое задание. Так снижается риск создать продукт, который никому не нужен.
• Ошибка обходится дешевле. Если при разработке архитектуры была допущена ошибка, то исправить её будет стоить не так дорого, как в «водопаде» или V-образной модели.

Недостатки инкрементной модели

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

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

Iterative Model (итеративная модель)

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

Рассмотрим на примере создания мессенджера, как эта модель работает.

1. Заказчик решил, что хочет создать мессенджер. Разработчики сделали приложение, в котором можно добавить друга и запустить чат на двоих.
2. Мессенджер «выкатили» в магазин приложений, пользователи начали его скачивать и активно использовать. Заказчик понял, что продукт пользуется популярностью, и решил его доработать.
3. Программисты добавили в мессенджер возможность просмотра видео, загрузки фотографий, записи аудиосообщений. Они постепенно улучшают функциональность приложения, адаптируют его к требованиям рынка.

Преимущества итеративной модели

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

Недостатки итеративной модели

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

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

Spiral Model (спиральная модель)

Используя эту модель, заказчик и команда разработчиков серьёзно анализируют риски проекта и выполняют его итерациями. Последующая стадия основывается на предыдущей, а в конце каждого витка — цикла итераций — принимается решение, продолжать ли проект. Эту модель начали использовать в 1988 году.

Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом». 

1. Заказчик решил, что хочет сделать такую систему, и заказал программистам реализовать управление чайником с телефона. Они начали действовать по модели «водопад»: выслушали идею, провели анализ предложений на рынке, обсудили с заказчиком архитектуру системы, решили, как будут её реализовывать, разработали, протестировали и «выкатили» конечный продукт.
2. Заказчик оценил результат и риски: насколько нужна пользователям следующая версия продукта — уже с управлением телевизором. Рассчитал сроки, бюджет и заказал разработку. Программисты действовали по каскадной модели и представили заказчику более сложный продукт, разработанный на базе первого.
3. Заказчик подумал, что пора создать функциональность для управления холодильником с телефона. Но, анализируя риски, понял, что в холодильник сложно встроить Wi-Fi-модуль, да и производители не заинтересованы в сотрудничестве по этому вопросу. Следовательно, риски превышают потенциальную выгоду. На основе полученных данных заказчик решил прекратить разработку и совершенствовать имеющуюся функциональность, чтобы со временем понять, как развивать систему «Умный дом».

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

Преимущества спиральной модели

• Большое внимание уделяется проработке рисков.

Недостатки спиральной модели

• Есть риск застрять на начальном этапе — бесконечно совершенствовать первую версию продукта и не продвинуться к следующим.
• Разработка длится долго и стоит дорого.

На основе итеративной модели была создана Agile — не модель и не методология, а скорее подход к разработке.

Что такое Agile?

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

• экстремальное программирование (Extreme Programming, XP);
• бережливую разработку программного обеспечения (Lean);
• фреймворк для управления проектами Scrum;
• разработку, управляемую функциональностью (Feature-driven development, FDD);
• разработку через тестирование (Test-driven development, TDD);
• методологию «чистой комнаты» (Cleanroom Software Engineering);
• итеративно-инкрементальный метод разработки (OpenUP);
• методологию разработки Microsoft Solutions Framework (MSF);
• метод разработки динамических систем (Dynamic Systems Development Method, DSDM);
• метод управления разработкой Kanban.

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

Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban. 

Kanban

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

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

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