Значение понятия руководство по

        ё

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

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

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

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

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

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 «Надежность автоматизированных систем управления».

©
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 (система управления информационными технологиями)

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

https://gbcdn.mrgcdn.ru/uploads/post/1168/og_image/a7c9405c70331cef17f9a8e903ff8c62.jpg

Лютер Халси Гулик[260] (1892–1993) – американский исследователь проблем организации и управления, специалист по государственному управлению, последователь и популяризатор административной теории А. Файоля, представитель «второго поколения классической школы».

Л. Гулик родился в Осаке. В 1919 г. был назначен главой специального училища при Бюро муниципальных исследований, преобразованного позднее в Национальный институт государственного управления США. С 1921 г. – президент Национального института государственного управления. В 1930-х гг. вошел в состав Комитета Браунлоу, занимавшегося реорганизацией управления при президенте США, а также помогал созданию государственной администрации Расчетной палаты. Долгое время Л. Гулик занимал многие ответственные посты в правительстве, включая Комитет по производству вооружений, Комиссию ООН по репарациям в Москве, Потсдаме, Токио и Маниле, а также президентский Комитет по административному управлению. Л. Гулик являлся консультантом во многих международных организациях, например Всемирной организации здравоохранения при ООН и ЮНЕСКО. В 1960-е гг. стал консультантом президента Г. Насера по вопросам создания новой конституции Египта. Читал лекции по вопросам управления в Мичиганском университете.

Основные работы. В период с 1920 по 1990 г. самостоятельно и в соавторстве с другими учеными Л. Гулик написал пятьдесят книг и около двухсот статей. Наиболее известная публикация – «Доклады о науке управления» (1937). Она была подготовлена к печати совместно с Линдалом Урвиком и представляет собой интернациональный сборник работ, написанных известными специалистами в области классической теории управления: Г. Денниссоном, А. Файолем, М. Фоллетт, Дж. Ли, Дж. Муни и др.

В этом однотомном сборнике содержатся наиболее исчерпывающие формулировки классических теорий организационных структур, и его можно рассматривать, по сути, как работу по истории управленческой мысли в области теории организации. Из одиннадцати разделов работы «Доклады о науке управления» две статьи принадлежат Л. Гулику: «Заметки по теории организации» и «Наука, ценности и общественная организация». Кроме того, к числу основных работ Л. Гулика можно отнести: «Административные размышления о Второй мировой войне» (1948), «Политическое и административное руководство» (1963).

В своих работах Л. Гулик попытался свести в единую эффективную схему европейские «гуманистические» взгляды на управление с научным прагматизмом Ф. У. Тейлора. Большое внимание он уделял анализу государственного управления, принципам построения организаций, рассмотрению вопросов общего руководства.

По общему мнению западных ученых, статья Лютера Гулика «Заметки по теории организации», открывающая сборник «Доклады о науке управления», стала окончательным утверждением подхода к управлению организациями, основанного на «принципах», и является самым ясным и наиболее подробным выражением взглядов автора на философию управления[261].

Теория разделения и координации труда. Л. Гулик начинает статью «Заметки по теории организации» с изложения классической концепции разделения труда и видит в этом явлении основную причину происхождения организации. По мнению Л. Гулика, вопрос «разделения труда – это вопрос человеческой сущности, времени и пространства»[262]. На каждом широкомасштабном и сложно структурированном предприятии, требующем большого количества людей, наилучший результат будет достигнут при разделении труда между ними. Разделение труда необходимо, поскольку, во-первых, оно делает возможным более эффективное использование разнообразных умений и навыков работников, а во-вторых, уменьшает потери времени.

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

1. Когда оно создает задачи, решение которых требует участия менее чем одного работника.

2. Когда оно связано с технологией и привычным образом действий в данное время в данном месте.

3. Когда физическое разделение переходит в органическое разделение. Например, «если отправить переднюю часть коровы пастись на луг, а заднюю часть оставить в амбаре и постоянно ее доить».

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

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

Л. Гулик выделил два основных способа к осуществлению координации:

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

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

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

Л. Гулик выделил несколько ограничивающих факторов в развитии процесса координации. Основные из них:

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

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

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

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

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

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

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

Л. Гулик пишет: «При планировании подразделений, подчиняющихся непосредственно президенту, должен применяться принцип ограничения сферы контроля; при создании отделов со специальными функциями должен применяться принцип однородности. Если на каком-либо предприятии распределение множества функций организованно таким образом, что первое сверху подразделение не всегда пересекается с первым находящимся внизу отделом, то тогда следует создать дополнительные подразделения и отделы. Однако при каждом последующем шаге строгое следование двум противоречащим принципам должно ослабевать, пока не произойдет их совпадение».

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

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

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

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

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

Если деятельность подразделения внутри организации определяется более чем одним из перечисленных выше принципов, то возникает опасность увеличения разногласий между подразделениями, особенно там, где происходит пересечение или перекрытие их полномочий. Поэтому основная управленческая функция руководителя будет состоять в ослаблении этих противоречий с целью обеспечения спокойной работы всей организации. Л. Гулик считал, что разногласия могут быть ослаблены или преодолены в результате введения пятого координирующего элемента – координации с помощью идей. Он пишет: «Любое крупное и комплексное предприятие будет неспособным к эффективному устройству, если вместо координации его деятельности будет осуществляться лишь налаживание ее организации. …Соответственно и наиболее трудной задачей для руководителя является не командование, а управление, то есть развитие желания и готовности к совместной работе ради общей цели у всех людей, вовлеченных в любой вид трудовой деятельности на данном предприятии».

В целом в работе Л. Гулика «Заметки по теории организации» было выделено десять «универсальных» принципов организации:

1) разделение труда и специализация;

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

3) координация посредством иерархии;

4) координация посредством идеи;

5) координация посредством комиссий;

6) децентрализация;

7) единство командования;

штаб и линия;

9) делегирование;

10) диапазон управления.

В своих более поздних сочинениях Л. Гулик продолжал выступать за признание и одобрение принципов управления.

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

Функции управления. Теория управления Л. Гулика основывается на файолевском понимании «пяти элементов администрации». При этом Л. Гулик считал сферу деятельности высшего управленческого звена более обширной и сложной, чем она была представлена у А. Файоля. Поэтому Л. Гулик расширил функции администрации А. Файоля и выделил семь направлений деятельности и обязанностей любого руководителя высшего звена.

В своей статье «Заметки по теории организации» Л. Гулик ввел знаменитую мнемоническою аббревиатуру POSDCORB, отражающую функции управления: планирование, организация, подбор персонала, руководство, координация, отчетность, бюджетирование. Он подчеркивал, что «POSDCORB – это аббревиатура, составленная, чтобы привлечь внимание к различным функциональным элементам деятельности руководителя, так как понятия “администрирование ” и “ менеджмент ” потеряли свой конкретный смысл». POSDCORB задумывался как связующее звено между теорией управления и реальной управленческой практикой.

Понятие POSDCORB составлено из начальных букв слов, означающих следующие виды деятельности:

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

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

• Staffing (управление персоналом) – комплекс функций, связанных с приемом на работу, обучением персонала, а также

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

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

• Co-ordinating (координация) – всевозможные обязанности и полномочия по созданию связей между различными частями работы.

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

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

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

По мнению Л. Гулика, «если эти семь элементов могут являться основными обязанностями руководителя высшего звена, значит, они могут быть преобразованы в отдельные подразделения исполнительной власти». Необходимость и возможность их создания определяется размером и сложностью структуры предприятия. Исследователь пишет, что «на крупных предприятиях, где руководитель высшего звена не в состоянии справиться с возлагаемой на него работой, необходимо организовать одно или несколько подразделений POSDCORB».

В более поздних работах Л. Гулик изменил формулу POSDCORB на POSDECORB. Был добавлен еще один элемент – Evaluation (оценка)[263]. Автор также пришел к признанию важности принципа децентрализации, делегирования полномочий служащим низшего звена и их участия в принятии решений.

По мнению Л. Гулика, люди, находящиеся на вершине управленческой иерархии, должны обладать широким набором качеств. Он подчеркивает необходимость наличия у руководителей организаторских способностей и умения повести за собой подчиненных. При этом Л. Гулик указал и на факторы, которые могут ограничивать возможности руководителя. К ним относятся: 1) неопределенность будущего; 2) недостаточность знаний у самих руководителей; 3) отсутствие у них необходимых административных навыков и отработанных методов; 4) общая нехватка предписанных и научно обоснованных процедур и программ; 5) огромное количество переменных факторов и неполнота человеческого знания, в частности о человеке и его жизни.

В работе «Административные размышления о Второй мировой войне» Л. Гулик акцентирует внимание на необходимости замены руководителей, в случае если они оказываются не соответствующими ситуации. В то же время Л. Гулик рекомендует сохранение престижа высшего руководства. По его мнению, «это жестоко по отношению к нижестоящим организациям и подчиненным, но сохраняет целостность общего управления в мире испытаний и ошибок… Высшее руководство должно отвечать за общий результат, а не за каждый подотчетный ему сегмент»[264].

Рассматривая вопросы управления и роли руководителя на государственном уровне, Л. Гулик формулировал вопрос так: «Должен ли администратор быть динамичным, активным лидером города, или он должен заниматься чисто административным руководством в узком смысле этого слова, а решение всех стратегических (политических) вопросов предоставить совету?»[265] Л. Гулик пришел к выводу, что политическую функцию нельзя отделить от административной, поскольку многие политические решения неразрывно связаны с администрированием.

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

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

• развитие профессиональных ассоциаций работников;

• поиск путей решения проблем, возникающих на рабочем месте;

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

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

Таким образом, в своей теории организации Л. Гулик рассматривает процесс управления как единое целое, не ограниченное только формальными аспектами. Он подчеркивает важность учета неформальных факторов организации, особенностей человеческих отношений. Однако Л. Гулику не удалось до конца понять значение человеческого элемента в организациях. Как подчеркивал Д. М. Гвишиани, в большинстве своем разработанные им организационные принципы касаются в основном лишь архитектоники формальной организации[266].

В 1950–60-е гг. ХХ в. в большинстве стран Запада актуализировалась задача планирования и прогнозирования экономики. Л. Гулик также занимался разработкой вопросов планирования. Основываясь на анализе американской экономики, Л. Гулик пришел к выводу о том, что планирование является важнейшим элементом управления. По его мнению, необходимо непрерывное планирование – как до разработки программы, так и во время ее реализации в качестве источника информации для размышления и анализа: «Планирование, исследования и текущая работа идут рука об руку; они являются параллельными и взаимовлияющими видами деятельности. Планирование должно также быть гибким, не создающим помех; но не следует чрезмерно увлекаться планированием, так как это сокращает возможности осуществления выбора в настоящем и будущем»[267].

Хотя основное внимание Л. Гулик уделял разработке целостной управленческой теории, он пришел к выводу о том, что всесторонне разработанной теории управления так и не существует. То, что имелось вместо нее, он называл «более или менее достоверными и частично подтвержденными предположениями», а не доказанной управленческой теорией.

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

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

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

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

_____________________________________________________________________________________________________________________

[260] Фамилия Guliсk иногда передается по-русски как Гьюлик.

[261] Классики теории государственного управления: американская школа / под ред. Дж. Шафритца, А. Хайда. Москва : Издательство Московского университета, 2003. С. 88 ; Классики менеджмента : пер. с англ. / под ред. М. Уорнера. Санкт-Петербург : Питер, 2001. С. 261–262.

[262] Здесь и далее цитирование работы Л. Гулика «Заметки по теории организации» будет проводиться по сборнику трудов ведущих теоретиков американской управленческой мысли: Классики теории государственного управления: американская школа / под ред. Дж. Шафритца, А. Хайда. Москва : Издательство Московского университета, 2003. С. 100–118.

[263] Государственное управление : словарь — справочник по материалам «International Encyclopedia of Public Policy and Administration» : пер. с англ. Санкт-Петербург : Петрополис, 2001. 630 с.

[264] Классики менеджмента : пер. с англ. / под ред. М. Уорнера. Санкт-Петербург : Питер, 2001. С. 265.

[265] Gulick L. Political and Administrative Leadership // Public Management. 1963. November

[266] Гвишиани Д. М. Организация и управление. Москва : Наука, 1972. С. 267.

[267] Классики менеджмента : пер. с англ. / под ред. М. Уорнера. Санкт-Петербург : Питер, 2001. С. 266.

Выходные данные учебного пособия: 

История менеджмента : учебное пособие / Е. П. Костенко, Е. В. Михалкина ; Южный федеральный университет. — Ростов-на- Дону: Издательство Южного федерального университета, 2014. — 606 с. 

Вернуться к оглавлению «История менеджмента: учебное пособие» 

Software is a set of programmed instructions stored in the memory of stored-program digital computers for execution by the processor. Software is a recent development in human history, and it is fundamental to the Information Age.

Ada Lovelace’s programs for Charles Babbage’s Analytical Engine in the 19th century is often considered the founder of the discipline, though the mathematician’s efforts remained theoretical only, as the technology of Lovelace and Babbage’s day proved insufficient to build his computer. Alan Turing is credited with being the first person to come up with a theory for software in 1935, which led to the two academic fields of computer science and software engineering.

The first generation of software for early stored-program digital computers in the late 1940s had its instructions written directly in binary code, generally written for mainframe computers. Later, the development of modern programming languages alongside the advancement of the home computer would greatly widen the scope and breadth of available software, beginning with assembly language, and continuing on through functional programming and object-oriented programming paradigms.

Before stored-program digital computers[edit]

Origins of computer science[edit]

Computing as a concept goes back to ancient times, with devices such as the abacus, the Antikythera mechanism, Astrolabes, Mechanical Astronomical clocks and Mechanical Calculators.^[1] The Antikythera mechanism is an example for a highly complex ancient mechanical Astronomical device.^[2]

However, these devices were pure hardware and had no software — their computing powers were directly tied to their specific form and engineering.

Software requires the concept of a general-purpose processor — what is now described as a Turing machine — as well as computer memory in which reusable sets of routines and mathematical functions comprising programs can be stored, started, and stopped individually, and only appears recently in human history.

The first known computer algorithm was written by Ada Lovelace in the 19th century for the Analytical Engine, to translate Luigi Menabrea’s work on Bernoulli numbers for machine instruction.^[3][3] However, this remained theoretical only — the lesser state of engineering in the lifetime of these two mathematicians proved insufficient^{[citation needed]} to construct the Analytical Engine.

The first modern theory of software was proposed by Alan Turing in his 1935 essay Computable numbers with an application to the Entscheidungsproblem (decision problem).^[4]

This eventually led to the creation of the twin academic fields of computer science and software engineering, which both study software and its creation. Computer science is more theoretical (Turing’s essay is an example of computer science), whereas software engineering is focused on more practical concerns.

However, prior to 1946, software as we now understand it – programs stored in the memory of stored-program digital computers – did not yet exist. The very first electronic computing devices were instead rewired in order to «reprogram» them. The ENIAC, one of the first electronic computers, was programmed largely by women who had been previously working as human computers.^{[5] [6]} Engineers would give the programmers blueprints of the ENIAC wiring and expected them to figure out how to program the machine.^[7] The women who worked as programmers prepped the ENIAC for its first public reveal, wiring the patch panels together for the demonstrations.^{[8] [9][10]} Kathleen Booth developed Assembly Language in 1950 to make it easier to program the computers she worked on at Birkbeck College.^[11]

Grace Hopper worked as one of the first programmers of the Harvard Mark I.^[12] She later created a 500-page manual for the computer.^[13] Hopper is often falsely credited with coining the terms «bug» and «debugging,» when she found a moth in the Mark II, causing a malfunction;^[14] however, the term was in fact already in use when she found the moth.^[14] Hopper developed the first compiler and brought her idea from working on the Mark computers to working on UNIVAC in the 1950s.^[15] Hopper also developed the programming language FLOW-MATIC to program the UNIVAC.^[14] Frances E. Holberton, also working at UNIVAC, developed a code^{[clarification needed]}, C-10, which let programmers use keyboard inputs and created the Sort-Merge Generator in 1951.^[16][17] Adele Mildred Koss and Hopper also created the precursor to a report generator.^[16]

Early days of computer software (1948–1979)[edit]

In his manuscript «A Mathematical Theory of Communication», Claude Shannon (1916–2001) provided an outline for how binary logic could be implemented to program a computer. Subsequently, the first computer programmers used binary code to instruct computers to perform various tasks. Nevertheless, the process was very arduous. Computer programmers had to provide long strings of binary code to tell the computer what kind of data it should store. Code and data had to be loaded onto computers using various tedious mechanisms, including flicking switches or punching holes at predefined positions in cards and loading these punched cards into a computer. With such methods, if a mistake was made, the whole program might have to be loaded again from the beginning.

The very first time a stored-program computer held a piece of software in electronic memory and executed it successfully, was 11 am 21 June 1948, at the University of Manchester, on the Manchester Baby computer. It was written by Tom Kilburn, and calculated the highest factor of the integer 2^18 = 262,144. Starting with a large trial divisor, it performed division of 262,144 by repeated subtraction then checked if the remainder was zero. If not, it decremented the trial divisor by one and repeated the process. Google released a tribute to the Manchester Baby, celebrating it as the «birth of software».

FORTRAN was developed by a team led by John Backus at IBM in the 1950s. The first compiler was released in 1957. The language proved so popular for scientific and technical computing that by 1963 all major manufacturers had implemented or announced FORTRAN for their computers.^[18][19]

COBOL was first conceived of when Mary K. Hawes convened a meeting (which included Grace Hopper) in 1959 to discuss how to create a computer language to be shared between businesses.^[16] Hopper’s innovation with COBOL was developing a new symbolic way to write programming.^[13] Her programming was self-documenting.^[20] Betty Holberton helped edit the language which was submitted to the Government Printing Office in 1960.^[21] FORMAC was developed by Jean E. Sammet in the 1960s.^[21] Her book, Programming Languages: History and Fundamentals (1969), became an influential text.^[21][22]

Apollo Mission[edit]

The Apollo Mission to the moon depended on software to program the computers in the landing modules.^[23][24] The computers were programmed with a language called «Basic» (no relation with the BASIC programming language developed at Dartmouth at about the same time).^[25] The software also had an interpreter which was made up of a series of routines and an executive (like a modern-day operating system), which specified which programs to run and when.^[25] Both were designed by Hal Laning.^[25] Margaret Hamilton, who had previously been involved with software reliability issues when working on the US SAGE air defense system, was also part of the Apollo software team.^[23][26] Hamilton was in charge of the onboard flight software for the Apollo computers.^[23] Hamilton felt that software operations were not just part of the machine, but also intricately involved with the people who operated the software.^[25] Hamilton also coined the term «software engineering» while she was working at NASA.^[27]

The actual «software» for the computers in the Apollo missions was made up of wires that were threaded through magnetic cores.^[28] Where the wire went through a magnetic core, that represented a «1» and where the wire went around the core, that represented a «0.»^[28] Each core stored 64 bits of information.^[28] Hamilton and others would create the software by punching holes in punch cards, which were then later processed on a Honeywell mainframe where the software could be simulated.^[23] When the code was «solid,» then it was sent to be woven into the magnetic cores at Raytheon, where women known as «Little Old Ladies» worked on the wires.^[23] The program itself was «indestructible» and could even withstand lightning strikes, which happened to Apollo 12.^[28] Wiring the computers took several weeks to do, freezing software development during that time.^[29]

While using the simulators to test the programming, Hamilton discovered ways that code could produce dangerous errors when human mistakes were made while using it.^[23] NASA believed that the astronauts would not make mistakes due to their training.^[30] Hamilton was not allowed to program code to prevent errors that would lead to system crash, so she annotated the code in the program documentation.^[23] Her ideas to add error-checking code was rejected as «excessive.»^[23] However, exactly what Hamilton predicted would happen occurred on the Apollo 8 flight, when human error caused the computer to wipe out all of the navigational data.^[23]

Bundling of software with hardware and its legal issues[edit]

Later, software was sold to multiple customers by being bundled with the hardware by original equipment manufacturers (OEMs) such as Data General, Digital Equipment and IBM. When a customer bought a minicomputer, at that time the smallest computer on the market, the computer did not come with pre-installed software, but needed to be installed by engineers employed by the OEM.^{[citation needed]}

This bundling attracted the attention of US antitrust regulators, who sued IBM for improper «tying» in 1969, alleging that it was an antitrust violation that customers who wanted to obtain its software had to also buy or lease its hardware in order to do so. However, the case was dropped by the US Justice Department, after many years of attrition, as it concluded it was «without merit».^[31]

Data General also encountered legal problems related to bundling – although in this case, it was due to a civil suit from a would-be competitor. When Data General introduced the Data General Nova, a company called Digidyne wanted to use its RDOS operating system on its own hardware clone. Data General refused to license their software and claimed their «bundling rights». The US Supreme Court set a precedent called Digidyne v. Data General in 1985 by letting a 9th circuit appeal court decision on the case stand, and Data General was eventually forced into licensing the operating system because it was ruled that restricting the license to only DG hardware was an illegal tying arrangement.^[32] Even though the District Court noted that «no reasonable juror could find that within this large and dynamic market with much larger competitors», Data General «had the market power to restrain trade through an illegal tie-in arrangement», the tying of the operating system to the hardware was ruled as per se illegal on appeal.^[33]

In 2008, Psystar Corporation was sued by Apple Inc. for distributing unauthorized Macintosh clones with OS X preinstalled, and countersued. One of the arguments in the countersuit — citing the Data General case — was that Apple dominates the market for OS X compatible computers by illegally tying the operating system to Apple computers. District Court Judge William Alsup rejected this argument, saying, as the District Court had ruled in the Data General case over 20 years prior, that the relevant market was not simply one operating system (Mac OS) but all PC operating systems, including Mac OS, and noting that Mac OS did not enjoy a dominant position in that broader market. Alsup’s judgement also noted that the surprising Data General precedent that tying of copyrighted products was always illegal had since been «implicitly overruled» by the verdict in the Illinois Tool Works Inc. v. Independent Ink, Inc. case.^[34]

Packaged software (Late 1960s-present)[edit]

This section needs expansion. You can help by adding to it. (March 2019)

An industry producing independently packaged software — software that was neither produced as a «one-off» for an individual customer, nor «bundled» with computer hardware — started to develop in the late 1960s.^[35]

Unix (1970s–present)[edit]

Unix was an early operating system which became popular and very influential, and still exists today. The most popular variant of Unix today is macOS (previously called OS X and Mac OS X), while Linux is closely related to Unix.

The rise of Microcomputers[edit]

In January 1975, Micro Instrumentation and Telemetry Systems began selling its Altair 8800 microcomputer kit by mail order. Microsoft released its first product Altair BASIC later that year, and hobbyists began developing programs to run on these kits. Tiny BASIC was published as a type-in program in Dr. Dobb’s Journal, and developed collaboratively.

In 1976, Peter R. Jennings for instance created his Microchess program for MOS Technology’s KIM-1 kit, but since it did not come with a tape drive, he would send the source code in a little booklet to his mail-order customers, and they would have to type the whole program in by hand. In 1978, Kathe and Dan Spracklen released the source of their Sargon (chess) program in a computer magazine. Jennings later switched to selling paper tape, and eventually compact cassettes with the program on it.

It was an inconvenient and slow process to type in source code from a computer magazine, and a single mistyped – or worse, misprinted – character could render the program inoperable, yet people still did so. (Optical character recognition technology, which could theoretically have been used to scan in the listings rather than transcribe them by hand, was not yet in wide use.)

Even with the spread of cartridges and cassette tapes in the 1980s for distribution of commercial software, free programs (such as simple educational programs for the purpose of teaching programming techniques) were still often printed, because it was cheaper than making and attaching cassette tapes to magazines.

However, eventually a combination of four factors brought this practice of printing complete source code listings of entire programs in computer magazines to an end:

• programs started to become very large
• floppy discs started to be used for distributing software, and then came down in price
• regular people started to use computers – and wanted a simple way to run a program
• computer magazines started to include cassette tapes or floppy discs with free or trial versions of software on them

Very quickly, commercial software started to be pirated, and commercial software producers were very unhappy at this. Bill Gates, cofounder of Microsoft, was an early moraliser against software piracy with his famous Open Letter to Hobbyists in 1976.^[36]

1980s–present[edit]

This section needs expansion. You can help by adding to it. (September 2013)

Before the microcomputer, a successful software program typically sold up to 1,000 units at $50,000–60,000 each. By the mid-1980s, personal computer software sold thousands of copies for $50–700 each. Companies like Microsoft, MicroPro, and Lotus Development had tens of millions of dollars in annual sales.^[37] They similarly dominated the European market with localized versions of already successful products.^[38]

A pivotal moment in computing history was the publication in the 1980s of the specifications for the IBM Personal Computer published by IBM employee Philip Don Estridge, which quickly led to the dominance of the PC in the worldwide desktop and later laptop markets – a dominance which continues to this day. Microsoft, by successfully negotiating with IBM to develop the first operating system for the PC (MS-DOS), profited enormously from the PC’s success over the following decades, via the success of MS-DOS and its add-on-cum-successor, Microsoft Windows. Winning the negotiation was a pivotal moment in Microsoft’s history.

Free and open source software[edit]

Recent developments[edit]

App stores[edit]

Applications for mobile devices (cellphones and tablets) have been termed «apps» in recent years. Apple chose to funnel iPhone and iPad app sales through their App Store, and thus both vet apps, and get a cut of every paid app sold. Apple does not allow apps which could be used to circumvent their app store (e.g. virtual machines such as the Java or Flash virtual machines).

The Android platform, by contrast, has multiple app stores available for it, and users can generally select which to use (although Google Play requires a compatible or rooted device).

This move was replicated for desktop operating systems with GNOME Software (for Linux), the Mac App Store (for macOS), and the Windows Store (for Windows). All of these platforms remain, as they have always been, non-exclusive: they allow applications to be installed from outside the app store, and indeed from other app stores.

The explosive rise in popularity of apps, for the iPhone in particular but also for Android, led to a kind of «gold rush», with some hopeful programmers dedicating a significant amount of time to creating apps in the hope of striking it rich. As in real gold rushes, not all of these hopeful entrepreneurs were successful.

Formalization of software development[edit]

The development of curricula in computer science has resulted in improvements in software development. Components of these curricula include:

1. Structured and Object Oriented programming^[39]
2. Data structures^[40]
3. Analysis of Algorithms^[41]
4. Formal languages^[42] and compiler construction^[43]
5. Computer Graphics Algorithms^[44]
6. Sorting and Searching^[45]
7. Numerical Methods,^[46] Optimization and Statistics^[47]
8. Artificial Intelligence^[48] and Machine Learning^[49]

How software has affected hardware[edit]

As more and more programs enter the realm of firmware, and the hardware itself becomes smaller, cheaper and faster as predicted by Moore’s law, an increasing number of types of functionality of computing first carried out by software, have joined the ranks of hardware, as for example with graphics processing units. (However, the change has sometimes gone the other way for cost or other reasons, as for example with softmodems and microcode.)

Most hardware companies today have more software programmers on the payroll than hardware designers^{[citation needed]}, since software tools have automated many tasks of printed circuit board (PCB) engineers.

Computer software and programming language timeline[edit]

The following tables include year by year development of many different aspects of computer software including:

1. High level languages^[50][51]
3. Operating systems^[52]
5. Networking software and applications^[53]
7. Computer graphics hardware, algorithms and applications^[54][55]
9. Spreadsheets
11. Word processing
13. Computer aided design^[56]

1971–1974[edit]

	1971	1972	1973	1974
Programming languages	CDL KRL SUE	C INTERCAL PL/M Prolog Smalltalk SQL	COMAL LIS ML Speakeasy-3	BASIC FOUR CLU GRASS PROSE
Operating systems	DEC RSTS-11	Data General RDOS	Soviet ALGOL 68	DEC DOS-11
Computer networks		Wozniak’s Blue Box	Bob Metcalfe develops Ethernet
Computer graphics		Newell & Sancha visible surface algorithm		Catmull & Straber develop z-buffer
CAD/CAM	MCS founded	ADAM	Auto-Draft	Tektronix 4014

1975–1978[edit]

	1975	1976	1977	1978
Programming languages	ABC Altair BASIC CS-4 Modula Scheme	Mesa Plus Ratfor S SAM76 SAS Smalltalk-76	Blue Bourne Shell Commodore BASIC FP Icon IDL Red Standard MUMPS Yellow IDL	C shell HAL/S MATLAB RPG III SMALL VisiCalc SQL
Operating systems	CP/M	Cambridge CAP	1BSD	2BSD Apple DOS
Computer networks	Telenet packet switching
Computer graphics	EDS founded		Antialiasing
Word processors		Electric Pencil		AppleWriter
CAD/CAM	Solid modeling	McDonnell Douglas buys Unigraphics	Forerunner to CATIA	Raster graphics display

1979–1982[edit]

	1979	1980	1981	1982
Programming languages	AWK Icon Modula-2 REXX Vulcan dBase-II	Ada 80 C with classes CBASIC	BBC BASIC IBM BASICA	Draco PostScript Speakeasy-IV
Operating systems	Atari DOS	86-DOS	MS-DOS 1 Acorn MOS	Commodore DOS
Computer networks	Usenet	TCP/IP
Computer graphics				Silicon Graphics founded
Word processors	Wordstar	WordPerfect for DG Mini	Bank Street AppleWriter II	WordStar 3.0 WordPerfect for DOS
Spreadsheet	VisiCalc		Lotus 1-2-3
CAD/CAM	IGES	VersaCAD	Dassault Systems	Autodesk founded

1983–1986[edit]

	1983	1984	1985	1986
Programming languages	ABAP Ada 83 C++ GW-BASIC Korn Shell Objective-C occam True BASIC Turbo Pascal	CLIPPER Common Lisp Good Old MAD (GOM) OPL Redcode RPL Standard ML Matlab Framework FRED	Paradox QuickBASIC Framework II FRED	CorVision Eiffel GFA BASIC Informix-4GL LabVIEW Miranda Object Pascal PROMAL
Operating systems	MS-DOS 2 Lisa Office SunOS 1	MS-DOS 3 System Software	Windows 1.0 Atari TOS AmigaOS	AIX 1
Computer networks	ARPANET splits off MILNET	Novell NetWare Research In Motion founded	NSFNET connects 5 Supercomputers
Computer graphics			ATI founded	Intel 82786 coprocessor
Word processors	Word 1 for DOS	Word 1 for Mac	WordPerfect 4.2 for DOS
Spreadsheet			Excel for Mac
CAD/CAM	Autodesk releases AutoCAD 1.2,1.3,1.4	AutoCAD 2	Bentley Systems Parametric Technology	AutoLISP

1987–1990[edit]

	1987	1988	1989	1990
Programming languages	Ada ISO 8652 Clean Erlang HyperTalk Mathematica Oberon occam 2 Perl Self Turbo Basic	A+ Hamilton C shell Object REXX Octave RPG/400 SPARK STOS BASIC Tcl Mathematica Framework III FRED	Bash LPC Modula-3 PowerBASIC Turbo Pascal OOP VisSim FL	AMOS BASIC AMPL EuLisp Haskell J Object Oberon Z Shell
Operating systems	Windows 2.0	MS-DOS 4 Windows 2.1x OS/2 A/UX	EPCO	Windows 3.0
Computer networks		Morris worm	World Wide Web starts	HTML
Computer graphics	JPEG and GIF	Pixar’s Tin Toy wins Oscar	AutoDesk 3D Studio
Word processors	Microsoft Works for DOS	PC Magazine Reviews 55 Packages	WordPerfect 5.1 Word for Windows	Microsoft Office for Windows
Spreadsheet	Excel for Windows	Quattro Pro
CAD/CAM	Deneba releases Canvas X AutoCAD 9	CATIA 3 AutoCAD 10	Parametric T-Flex	Visionary Design Systems founded AutoCAD 11 ACIS 1

1991–1994[edit]

	1991	1992	1993	1994
Programming languages	GNU E Oberon-2 Oz Q Visual Basic Python Framework IV FRED	Turbo Pascal Dylan	Ruby AppleScript Brainfuck K Lua NewtonScript R Transcript Self ZPL	CLOS ANS Forth ANSI Common Lisp Claire Pike RAPID
Operating systems	MS-DOS 5 Linux	Windows 3.1x 386BSD	MS-DOS 6 Newton OS Solaris	AIX 4.0, 4.1
Computer networks		Mosaic web browser	NetWare 4	Netscape Navigator
Computer graphics		OpenGL	Nvidia founded
Word processors	Microsoft Works			Novell buys WordPerfect
CAD/CAM	EDS buys Unigraphics	CADAM & CATIA begin unification	AutoCAD 12	Simple Vector Format

1995–1998[edit]

	1995	1996	1997	1998
Programming languages	Ada 95 ColdFusion Delphi Java JavaScript LiveScript PHP Ruby	Curl Lasso NetRexx OCaml Perl Data Language WebDNA	Component Pascal E ECMAScript F-Script ISLISP Pico REBOL Squeak Smalltalk Tea Rebol	M2001 Open Source Erlang Pikt PureBasic REALbasic Standard C++ UnrealScript
Operating systems	Windows 95 Digital UNIX	Windows NT 4.0 Palm OS	Inferno Mac OS 7.6 Mac OS 8	Windows 98 Solaris 7 64-bit
Computer networks	The research proposal for Google was formed.	Mosaic web browser Inter@ctive Pager	NetWare 4	Netscape Navigator
Computer graphics	Pixar Goes Public after Toy Story	3Dfx Voodoo	ATI Rage Pro	Voodoo Banshee
Word processors	Word 95 for Windows	Corel buys WordPerfect from Novell
CAD/CAM	MicroStation Advanced solid modeling	Canvas 5	ISO 13567 AutoCAD 14	Dassault Systems buys Matra Datavision products

1999–2002[edit]

	1999	2000	2001	2002
Programming languages	D GameMaker Language Harbour XSLT	ActionScript C# Ferite Join Java Joy XL Visual Basic .NET	AspectJ GDScript Processing RPG IV	Gosu Io
Operating systems	Mac OS X Server 1.0 Mac OS 9	Windows 2000 Windows ME Mac OS X Public Beta	v10.0 Cheetah v10.1 Puma Windows XP	Windows XP 64-bit Edition 10.2 Jaguar
Computer networks	BlackBerry 850		NetWare 4	Netscape Navigator
Computer graphics	S3 Savage 4 GeForce 256	Radeon DDR (R100)	Nvidia Kyro II GeForce 3
Word processors	Sun buys Star Division
CAD/CAM	Pro/Engineer 2000	AutoCAD 2000	EDS buys SDRC	Unigraphics NX Autodesk buys Revit

2003–2006[edit]

	2003	2004	2005	2006
Programming languages	Factor Nemerle Scala Squirrel	Alma-0 Boo FreeBASIC Groovy Little b Subtext	Ada 2005 F# Seed7	Cobra Links OptimJ Windows PowerShell
Operating systems	v10.3 Panther Red Hat Enterprise Linux Windows Server 2003		v10.4 Tiger Ubuntu 5 Windows XP Professional x64 Edition
Computer networks	802.11g Apple Safari	Gmail Facebook founded Mozilla Firefox		BlackBerry Pearl 8100

2007–2010[edit]

	2007	2008	2009	2010
Programming languages	Clojure Fantom Fortress LOLCODE Oberon-07 Vala	Genie Pure	CoffeeScript Go Idris Parasail	Chapel RPG Open Access Rust
Operating systems	Windows Vista v10.5 Leopard	Android	Windows 7 v10.6 Snow Leopard Android 1.5 «Cupcake» Android 1.6 «Donut» Android 2.0–2.1 «Eclair»	Android 2.2 «Froyo» Android 2.3 «Gingerbread»
Computer networks		Google Chrome Chromium	Wi-Fi 802.11n
Computer graphics		Assassin’s Creed	Up Cloth Simulation	Avatar wins «Best Picture»
Word processors		Oracle buys OpenOffice from Sun	Oracle releases OpenOffice to Apache Software Foundation
CAD/CAM	Siemens buys UGS

2011–2014[edit]

	2011	2012	2013	2014
Programming languages	Dart	Ada 2012 Elixir Julia TypeScript CryEngine#CryEngine 3 (BeamNG.drive)	Xojo	Hack Swift
Operating systems	v10.7 Lion Android 3.x «Honeycomb» Android 4.0 «Ice Cream Sandwich»	Windows 8 v10.8 Mountain Lion Android 4.1.x–4.2.x «Jelly Bean»	v10.9 Mavericks Windows 8.1 Android 4.3 «Jelly Bean» Android 4.4 «KitKat»	v10.10 Yosemite Android 5.0 «Lollipop»
Computer networks		802.11ac
Computer graphics	Hugo wins Oscar Visual Effects	CryEngine3 and its 3D soft body physics

See also[edit]

• Forensic software engineering
• History of computing hardware
• History of operating systems
• History of software engineering
• List of failed and overbudget custom software projects
• List of pioneers in computer science
• Women in computing
• Timeline of women in computing

References[edit]

Sources[edit]

• Ceruzzi, Paul E. (1998). History of Computing. Cambridge, Massachusetts: MIT Press. ISBN 9780262032551 – via EBSCOhost.
• Evans, Claire L. (2018). Broad Band: The Untold Story of the Women Who Made the Internet. New York: Portfolio/Penguin. ISBN 9780735211759.
• Gürer, Denise (1995). «Pioneering Women in Computer Science» (PDF). Communications of the ACM. 38 (1): 45–54. doi:10.1145/204865.204875. S2CID 6626310.
• Light, Jennifer S. (1999). «When Computers Were Women». Technology and Culture. 40 (3): 455–483. doi:10.1353/tech.1999.0128. JSTOR 25147356. S2CID 108407884.
• Mindell, David A. (2008). Digital Apollo: Human and Machine in Spaceflight. Cambridge, Massachusetts: The MIT Press. ISBN 9780262266680.
• Smith, Erika E. (2013). «Recognizing a Collective Inheritance through the History of Women in Computing». CLCWeb: Comparative Literature and Culture. 15 (1): 1–9. doi:10.7771/1481-4374.1972.

External links[edit]

• Media related to History of software at Wikimedia Commons

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

Программная инженерия

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

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

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

Основные сведения

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

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

Все же, несмотря на юность профессии, будущее области радужно, поскольку, Money Magazine и Salary.com оценили профессию разработчика программного обеспечения как лучшую работу в Америке в 2006.

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

История

Когда первые современные цифровые компьютеры появились в начале 1940-х годов [9] наборы исполняемых команд уже были встроены в машину. Специалисты быстро поняли, что этот подход не слишком удобен. Так появилась “архитектура хранимых программ” или архитектура фон Неймана. Таким образом, деление на «железо» и «программное обеспечение» началось с абстракции, используемой чтобы решить проблему сложности вычислений.

Первые языки программирования стали появляться в 1950-х годах, и это был еще один важный шаг в абстракции. Основные языки, такие как Fortran, Algol и Cobol были выпущены в конце 1950-х для решения научных, алгоритмических и бизнес-задач соответственно. Дейкстра написал свою известную статью, «Go To Statement Considered Harmful» в 1968 году, а Дэвид Парнас ввел ключевое понятие модульности и скрытия информации в 1972 году, чтобы помочь программистам справляться со все более и более сложными программными системами. Системное программное обеспечение для управления аппаратным, названное “операционная система” было представлено компанией Unix в 1969 году. В 1967 году язык Simula ввел понятие объектно-ориентированной парадигмы программирования.

Эти достижения в области программного обеспечения были встречены большим прорывом компьютерной технике. В середине 1970-х годов был представлен микрокомпьютер, что позволило любителям получить собственный компьютер и писать свои программы для него. Это, в свою очередь привело к появлению персональных компьютеров (ПК) и Microsoft Windows. Также в середине 1980-х появляются такие понятия как цикл разработки программного обеспечения в качестве некоторого консенсуса для централизованной разработки программного обеспечения. Конец 1970-х и начало 1980-х годов ознаменовались появлением нескольких новых Simula-подобных объектно-ориентированных языков программирования, в том числе Smalltalk, Objective-C и C++.

Open Source, появившийся в начале 90-х в форме Linux, а также других программ, ввел понятие “базара” или децентрализованного стиля разработки ПО. Затем мировая паутина и стремительная популяризация интернета в середине 90-х изменили программную инженерию еще раз. Распределенные системы получили широкое распространение, как способ устройства систем, а также язык Java с его собственной виртуальной машиной, сделали еще один шаг в абстракции. Сотрудничество программистов позволило появиться на свет документу, названному Agile Manifesto, который поддерживал облегчение процессов, что способствовало написанию более дешевых и регулярно обновляемых программ.

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

Профессия

Правовые требования к лицензированию и сертификации профессиональных программных инженеров отличаются во всем мире. В Великобритании, Британское компьютерное общество выдает лицензии программных инженеров и члены общества могут также стать «дипломированными инженерами» (C.Eng), а в некоторых районах Канады, например, Альберта, Онтарио и Квебек, программные инженеры могут также быть «профессиональными инженерами» (P.Eng) и / или «мастерами информационных систем» (ISP) ,однако, нет никаких правовых требований для данных специализаций.

Работа

В 2004 году американское Бюро статистики труда, насчитало 760 840 программных инженеров, занимающих рабочие места в США. В тот же период времени было около 1,4 млн. практиков, занятых в США в других смешанных инженерных специальностях. Благодаря своей относительной новизне, как формальная область изучения, программная инженерия часто преподается как часть учебной программы компьютерных наук, и многие программные инженеры имеют неплохие познания в информатике.

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

Большинство программных инженеров и программистов работает 40 часов в неделю, а около 15 процентов программных инженеров и 11 процентов программистов работали более 50 часов в неделю в 2008 году. Травмы в этих профессиях встречаются редко. Однако, как и в других профессиях, где надо проводить много времени перед компьютером, люди этих специальностей более подвержены к усталости глаз, болям в спине, а также болезням рук и запястий, таких как синдром запястного канала.

Сертификация

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

Расширение сертификации «Общие навыки разработки программного обеспечения» доступны через различные профессиональные сообщества. В 2006 году IEEE сертифицировала более 575 специалистов в области программного обеспечения, как «Certified Software Development Professional»(CSDP). В 2008 году они добавили сертификат начального уровня известный как «Certified Software Development Associate» (CSDA). У ACM была профессиональная программа сертификации в начале 1980-х, которая была прекращена из-за отсутствия интереса.В ACM также рассматривали возможность сертификации профессиональных программных инженеров в конце 1990-х годов, но в итоге решили, что такая сертификация не подходит для профессиональной производственной практики разработки программного обеспечения.

В Великобритании, Британское компьютерное общество разработало юридически признанную профессиональную сертификацию, называемую «Chartered IT Professional» (CITP), и доступную только для полных членов (MBCS). Программные инженеры имеют право на членство в Институте Инженерии и Технологии и могут соответственно получить статус дипломированного инженера. В Канаде, Организация en:Canadian Information Processing Society также разработала юридически признанную профессиональную сертификацию, названную «Information Systems Professional» (ISP). [23] В Онтарио, Канада, Программные инженеры, которые заканчивают канадский Engineering Accreditation Board (CEAB), успешно сдавшие Professional Practice Examination (PPE) и, имеющие по крайней мере 48 месяцев опыта работы программным инженером, имеют право получить лицензию через PEO(«Профессиональные инженеры Онтарио») и могут стать Профессиональными инженерами (P.Eng).

Влияние глобализации

Первоначальное развитие аутсорсинга, а также относительно низкая стоимость человеческих ресурсов в развивающихся странах третьего мира привело к взрыву мыльного пузыря .com 1990-х годов. Это оказало негативное воздействие на многие аспекты профессии программного инженера. Например, некоторые студенты в развитых странах не хотели получать образование, связанное с программной инженерией из-за страха оффшорного аутсорсинга (импорт программных продуктов или услуг из других стран) и вытеснения иностранными рабочими. Хотя судя по статистике в настоящее время ничего не угрожает программной инженерии как таковой. Однако профессии, связанные с программированием кажется, действительно, были затронуты. Тем не менее, способность ловко использовать зарубежные рабочие ресурсы, улучшило общую работоспособность многих организаций. Когда североамериканцы будут уходить с работы, азиаты только прибывать на нее. Когда азиаты будут уходить с работы, европейцы будут на нее приезжать. Это обеспечивает непрерывную возможность иметь людей, следящих за критически важными бизнес-процессами 24 часа в сутки, без выплаты компенсации за сверхурочную работу и не лишая людей сна.

Образование

Знания в области программирования являются необходимым условием для того, чтобы стать программным инженером. В 2004 году IEEE Computer Society выпустил SWEBOK, который был опубликован в качестве стандарта ISO / IEC 19759:2004, описывающего объем знаний, который по их мнению, должен получить дипломированный программный инженер с четырехлетним опытом. Многие люди входят в эту профессии, получив высшее образование или отучившись в профессионально-техническом училище. Стандартный учебный план для международной степени бакалавра программной инженерии был определен CCSE, и обновлен в 2004 году. Ряд университетов имеют программы обучения программных инженеров. С 2010 года насчитывалось 244 очных программы, 70 Интернет-курсов, 230 программ для специалистов, 41 программ для ученых в этой области, а также 69 программ для сертификатов в Соединенных Штатах.

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

Сравнение с другими дисциплинами

Основные различия между программной инженерией и другими инженерными дисциплинами, по мнению некоторых исследователей, в различном уровне затрат на производство.^[3]

Поддисциплины

Программная инженерия может быть разделена на десять поддисциплин. К ним относятся:

• Анализ системных требований: выявление, анализ, спецификация и проверка требований к программному обеспечению.
• Проектирование программного обеспечения: процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или компонента.
• Конструирование программного обеспечения: поэтапное создание работающего программного обеспечения
• Тестирование программного обеспечения: динамический контроль поведения программы на конечном множестве тестов, надлежащим образом выбранных из бесконечной области.
• Обслуживание программное обеспечение: совокупность мероприятий, необходимых для обеспечения экономически эффективной поддержки программного обеспечения.
• Управление конфигурацией: определение конфигурации системы на различные моменты времени для систематического контроля изменений конфигурации, а также сохранение целостности и прослеживаемости конфигурации на протяжении всего жизненного цикла системы.
• Управление разработкой программного обеспечения: применение мер управления, планирования, координации, измерения, мониторинга, контроля и отчетности, для того, чтобы разработка и сопровождение программного обеспечения являлась систематической и дисциплинированной.
• Процесс разработки программного обеспечения: определение, реализация, оценка, измерение, управление, изменение и улучшение процесса жизненного цикла программы как такового.
• Средства и методы разработки программного обеспечения: компьютерные средства, которые предназначены для оказания помощи процессам жизненного цикла программы (см. Computer Aided Software Engineering), а также методы, которые применяют к структуре деятельности разработки программного обеспечения с целью сделать разработку более систематической и в конечном счете иметь более шансов на успех.
• Качество программного обеспечения: проверка удовлетворения набором собственных характеристик программы требованиям к программному обеспечению.

Родственные дисциплины

Программная инженерия является разделом информатики и связана с менеджментом. Она также считается частью общей инженерии систем.

Инженерия систем

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

Внешние ссылки

	Инженерия программного обеспечения на Викискладе?

• Computing Curricula 2005: The Overview Report by The Joint Task Force for Computing Curricula ACM/AIS/IEEE-CS
• Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering by The Joint Task Force on Computing Curricula ACM/IEEE-CS
• Guidelines for Associate-Degree Transfer Curriculum in Software Engineering by The ACM Two-Year College Education Committee and The IEEE Computer Society/ACM Joint Task Force on Software Engineering
• Guide to the Software Engineering Body of Knowledge
• Computer Software Engineers — Definition and statistics from the U.S. Bureau of Labor Statistics
• A Student’s Guide to Software Engineering Projects — a free online guide for students taking SE project courses
• The Open Systems Engineering and Software Development Life Cycle Framework OpenSDLC.org the integrated Creative Commons SDLC

См. также

• Компьютинг
• Компьютерные науки
• Информационные технологии
• Информационные системы
• Программирование
• Программное обеспечение
• Аппликативные вычислительные системы
• Разработка программного обеспечения
• Структурное программирование
• SWEBOK — Software Engineering Body of Knowledge

Литература

• Иан Соммервилл. Инженерия программного обеспечения, 2002 [1]
• Орлов С. А. Технологии разработки программного обеспечения: Разработка сложных программных систем Изд. 3-е, 2004
• Эрик Дж. Брауде. Технология разработки программного обеспечения, 2004
• Липаев, В.В. Программная инженерия. Методологические основы [Текст] : Учеб. / В. В. Липаев ; Гос. ун-т — Высшая школа экономики. — М. : ТЕИС, 2006. — 608 с. — 1000 экз. —

ISBN 5-7598-0424-3, УДК 004.41(075.8), ББК 32.973.26-018я73, Липаев, Высшая школа экономики, ТЕИС, 2006, pdf, экономика, программирование

Примечания

A Guide to the Project Management Body of Knowledge (далее PMBoK) — руководство к своду знаний по управлению проектами представляет собой совокупность профессиональных знаний по управлению проектами, признанных в качестве стандарта.

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

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

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

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

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

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

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

Институт управления проектами PMI (Project Management Institute) использует данный стандарт в качестве основного справочного материала по управлению проектами для своих программ профессионального развития и сертификации.

История Project Management Body of Knowledge

Первое издание PMBoK, было выпущено Институтом управления проектами (PMI — Project Management Institute) еще в 1986 году. Это была революционная методология, которую изначально ориентировали на помощь членам института в рамках подготовки к экзамену PMP (Project Management Professional), а так же данная методология по управлению проектами должна была оказать влияние на подход к управлению проектами в будущем.

Методология получила название «A guide to the Project Management Body of Knowledge» или PMBoK. Уже в 1991 году методологию PMBoK признают национальным стандартом ANSI (American National Standards Institute). Первую редакцию такого стандарта по управлению проектами опубликовали в 1994 году. Через два года была выпущена вторая редакция PMBoK, это произошло из-за быстрого роста членов PMI.

В скором будущем появилась третья редакция и называлась она — PMBoK Guide 2000. В 2004 году PMI выпускает своё очередное творение — PMBoK Guide Third Edition, которое получило самое большое распространение свода знаний по управлению проектами PMI.

31 декабря в 2008 году вышла в свет новая версия методологии — PMBoK Fourth Edition, которая, как и свой предшественник претерпела значительные изменения и стала по сути таким же революционным изданием. В этой версии были изменены сами методики PMI. В стандарт включили дополнительные методики: ведения аналитических работ, прототипирование, итеративность и применение систем искусственного интеллекта с целью построения прогноза реализации и завершения проекта в части сроков и бюджета.

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

Дополнительная область знания — Управление заинтересованными лицами (разделили область знаний Communication Management на две: Communication Management и Stakeholders Management). Дополнительные процессы следующие — Plan Scope Management, Plan Schedule Management, Plan Cost Management, Plan Stakeholder Management, а также Control Stakeholder Engagement. Обновление программ сертификации произойдет с 1 июля 2013 года. Дата выпуска PMBoK Guide 6th Edition еще не известна, но PMI уже определились с годом — 2016 год.

Описание методологии PMBoK

Области знаний PMBoK

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

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

Управление интеграцией проекта (Project Integration Management)

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

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

Управление содержанием проекта (Project Scope Management)

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

Управление содержанием проекта напрямую связано с определением и контролем того (содержания), что будет включено и что не будет включено в проект. Описываются схемы процессов Сбора требований, Определения содержания проекта, создания Иерархической структуры работ — ИСР (Work Breakdown Structure, WBS), Подтверждения содержания и Управления содержанием.

Управление сроками проекта (Project Time Management)

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

Управление стоимостью проекта (Project Cost Management)

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

Управление качеством проекта (Project Quality Management)

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

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

Управление человеческими ресурсами проекта (Project Human Resource Management)

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

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

Схема процессов управления человеческими ресурсами включает в себя: Разработку плана управления человеческими ресурсами, Набор команды проекта, Развитие команды проекта и Управление командой проекта.

Управление коммуникациями проекта (Project Communications Management)

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

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

Схема  процессов управления коммуникациями проекта включает в себя: Определение заинтересованных сторон проекта, Планирование коммуникаций, Распространение информации, Управление ожиданиями заинтересованных сторон проекта (начиная с пятой версии — PMBoK Fifth Edition, данные процессы вынесли в отдельную область знаний — Управление аинтересованными сторонами проекта Project Stakeholder Management), Отчеты об исполнении.

Управление рисками проекта (Project Risk Management)

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

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

Управление поставками проекта (Project Procurement Management)

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

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

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

Управление заинтересованными сторонами проекта (Project Stakeholder Management)

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

Группы процессов PMBoK

Все процессы в руководстве PMBoK разделяются на следующие группы:

Группа процессов инициации

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

• Разработка Устава проекта (Develop Project Charter)
• Определение заинтересованных сторон (Identity Stakeholders)

Группа процессов планирования

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

• Разработка плана управления проектом (Develop Project Management Plan)
• План управления содержанием (Plan Scope Management)
• Сбор требований (Collect Requirements)
• Определение содержания (Define Scope)
• Создание иерархической структуры работ — ИСР (Create Work Breakdown Structure — WBS)
• Разработка плана управления расписанием (Develop Schedule Management Plan)
• Определение операций (Define Activities)
• Определение последовательности операций (Sequence Activities)
• Оценка ресурсов операций (Estimate Activity Resources)
• Оценка длительности операций (Estimate Activity Durations)
• Разработка расписания (Develop Schedule)
• Разработка плана управления стоимостью (Develop Cost Management Plan)
• Оценка стоимости (Estimate Costs)
• Определение бюджета (Determine Budget)
• Планирование качества (Plan Quality)
• Разработка плана управления человеческими ресурсами (Develop Human Resource Plan)
• Планирование коммуникаций (Plan Communications)
• Планирование управления рисками (Plan Risk Management)
• Идентификация рисков (Identify Risks)
• Качественный анализ рисков (Perform Qualitative Risk Analysis)
• Количественный анализ рисков (Perform Quantitative Risk Analysis)
• Планирование реагирования на риски (Plan Risk Responses)
• Планирование закупок (Plan Procurements)
• Разработка плана управления заинтересованными сторонами (Develop Stakeholder Management Plan)

Группа процессов исполнения

Объединяет человеческие и другие ресурсы для выполнения плана управления проектом данного проекта. В группу процессов исполнения входят следующие процессы:

• Руководство и управление исполнением проекта (Direct and Manage Project Execution)
• Ообеспечение качества (Perform Quality Assurance)
• Набор команды проекта (Acquire Project Team)
• Развитие команды проекта (Develop Project Team)
• Управление командой проекта (Manage Project Team)
• Управление коммуникациями (Manage Communications)
• Осуществление закупок (Conduct Procurements)
• Управление вовлеченностью заинтересованных сторон (Manage Stakeholder Engagement)

Группа процессов мониторинга и управления

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

• Мониторинг и управление работами проекта (Monitor and Control Project Work)
• Общее управление изменениямиОбщий контроль изменений (Perform Integrated Change Control)
• Подтверждение содержания (Validate Scope)
• Контроль содержанияУправление содержанием (Control Scope)
• Контроль расписанияУправление расписанием (Control Schedule)
• Контроль стоимостиУправление стоимостью (Control Costs)
• Процесс контроля качества (Perform Quality Control)
• Мониторинг и контроль коммуникаций (Monitor and Control Communications)
• Мониторинг и контроль рисков (Monitor and Control Risks)
• Контроль закупокконтрактов (Control Procurement)
• Контроль вовлеченности заинтересованных сторон (Control Stakeholder Engagement)

Группа завершающих процессов

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

• Закрытие проекта или фазы (Close Project or Phase)
• Закрытие контрактов (Close Procurement)

Жизненный цикл по PMBoK

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

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

Инструменты и методы PMBoK

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

Данные инструменты и техники существуют сами по себе и уже давно применяются в различных направления деятельности человека. В процессах PMBoK существуют входы, выходы и методы. Именно при реализации методов определенных процессов и подразумевается применение руководителем проекта (Project Manager) тех или иных инструментов и техник. Ниже приведен список основных методов, инструментов и техник применимых к определенным процессам:

Методы

• Анализ дерева решений (Decision Tree Analysis).
• Анализ допущений (Assumptions Analysis).
• Анализ ожидаемого денежного значения (Expected Monetary Value (EMV) Analysis).
• Анализ отклонений (Variance Analysis).
• Анализ сети (Schedule Network Analysis или Network Analysis).
• Анализ сильных и слабых сторон, возможностей и угроз (Strengths, Weaknesses, Opportunities, and Threats Analysis, или SWOT Analysis).
• Анализ характера и последствий отказов (Failure Mode and Effect Analysis, FMEA).
• Aнализ чувствительности (Sensitivity Analysis).
• Быстрый проход (Fast Tracking).
• Выравнивание ресурсов (Resource Leveling).
• Декомпозиция (Decomposition).
• Метод «операции в узлах» (метод диаграмм предшествования) (Precedence Diagramming Method, PDM).
• Метод Дельфи (дельфийский метод) (Delphi Technique).
• Метод критического пути (Critical Path Methodology, CPM).
• Метод критической цепи (Critical Chain Method).
• Метод Монте-Карло (Monte Carlo Analysis).
• Метод освоенного объема (Earned Value Technique, EVT).
• Метод оценки и анализа программ (Program Evaluation and Review Technique, PERT).
• Мозговой штурм (Brainstorming).
• Оценка «снизу вверх» (Bottom-up Estimating).
• Планирование методом набегающей волны (Rolling Wave Planning).
• Управление освоенным объемом (Earned Value Management, EVM).

Инструменты

• Диаграмма Ганта (Gantt Chart).
• Диаграмма Парето (Pareto Chart).
• Иерархическая структура рисков (Risk Breakdown Structure, RBS).
• Информационная система управления проектами (Project Management Information System, PMIS).
• Матрица вероятности и воздействия (Probability and Impact Matrix).
• Матрица ответственности (Responsibility Assignment Matrix, RAM).
• Расписание контрольных событий (Milestone Schedule).
• Сетевая модель (Schedule Model).
• Система санкционирования выполнения работ (Work Authorization System).
• Система управления изменениями (Change Control System).
• Система управления конфигурацией (Configuration Management System).

Экзамены, сертификация и обучение

На данный момент в мире насчитывается более 470,000 менеджеров и специалистов по управлению проектами, имеющих сертификацию PMP – Project Management Professional. Степень по управлению проектами PMP, может получить каждый специалист из любой отрасли. PMP позволяет войти в ряды самого большого и престижного сообщества специалистов по управлению проектами.

Для получения степени PMP,  необходимо соответствовать определенным требованиям к образованию и опыту работы. Также необходимо пройти экзамен в виде теста на компьютере в специализированных аккредитованных центрах по всему миру (Registered Education Provider). Данный тест разработан для объективной оценки компетенций претендента в части управления проектами.

Требования к кандидату

Необходимо соответствовать первой или второй категории. Первая категория — высшее образование (не ниже бакалавра), 4,500 часов (36 непересекающихся месяцев за последние 6 лет) работы в области управления проектами (по пяти группам процессов) до подачи заявки. Также на момент подачи заявки, кандидат должен иметь 35 часов обучения (PDU).

При себе иметь подтверждающие документы:

1. Сведетельство о высшем образовании.
2. Форма подтверждения опыта
3. Перечень обучающих программ, пройденых кандидатом (35 PDU)

Посредством теста на степень PMP оцениваются применение знаний и навыков, использование инструментов и методов применяемых на практике при управлении проектами. Еще в 1997 году были разработаны требования к экзамену. Претенденту необходимо выбрать один правильный ответ из 4 вариантов по каждому из 200 вопросов. Сам тест состоит из 175 вопросов, остальные 25 вопросов определяются, как претестовые и в зачет не идут. Все вопросы в тесте разрабатываются комиссией, состоящей из специалистов со степенью PMP. Вопросы входящие в тест, ежегодно проверяются на соответствие экзаменационным требованиям. Для успешного прохождения теста, претенденту, за 4 часа, необходимо положительно ответить на 106 вопросов из 175. Получается, что проходной балл по экзамену составляет 61%.

Подготовка к экзамену PMP

Из множества учебников и материалов для подготовки к экзамену на степень PMP основным конечно же является сам свод знаний по управлению проектами — PMBoK Guide. Данный стандарт на двух языках (английский и русский) и множество дополнительных материалов (книг и учебников) по управлению проектами можно приобрести в специализированных on-line магазинах PMI.

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

Содержание экзамена PMP

Далее в процентном соотношении представлена разбивка вопросов экзамена по группам процессов:

• Инициация проекта (Project Initiating) – 13 % вопросов
• Планирование проекта (Project Planning) – 24 % вопросов
• Исполнение проекта (Project Executing) — 30 % вопросов
• Контроль проекта (Project Control) – 25 % вопросов
• Завершение проекта (Project Closing) – 8 % вопросов

В свое время, PMI провело исследование по описанию ролей (The Role Delineation Study), которое в последствии легло в основу Кодекса Профессиональной Этики (PMP Examination Specification). Данное исследование описывает экзаменационные вопросы, и как следствие служит отличным материалом для подготовки к экзамену.

Просмотры: 32 937

Источник (печатная версия): Словарь русского языка: В 4-х
т. / РАН,
Ин-т лингвистич.
исследований; Под ред. А. П. Евгеньевой. — 4-е изд., стер. — М.: Рус. яз.;
Полиграфресурсы,
1999;
(электронная версия): Фундаментальная
электронная
библиотека