Основы программной инженерии

Основы программной инженерии

Кризисы программирования и возникновение программной инженерии

На рубеже 60-х – 70-х годов прошлого века стоимость программного обеспечения стала приближаться к стоимости аппаратного обеспечения (компьютеров), а динамика её роста позволяла прогнозировать, что к середине 90-годов все человечество будет заниматься разработкой программ Это событие явилось первым кризисом программирования. Благодаря ему появилась идея для сокращения стоимости программ использовать инженерные методы в производстве программ, которая постепенно оформилась в программную инженерию (или технологию программирования в нашей стране).

С тех пор программная инженерия бурно развивается. Причём этапы её развития связаны с решением очередной системной проблемы:

1. Появление модульного подхода к программированию

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

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

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

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

2. Формирование структурного подхода к программированию

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

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

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

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

– стандартизация всех этапов жизненного цикла программного комплекса;

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

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

3. Становление объектно-ориентированного подхода

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

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

1. Инкапсуляция – объединение в классе свойств и методов.

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

3. Полиморфизм – определение свойств и методов объекта по контексту.

Объектно-ориентированный подход позволил успешно перейти к спиральной модели разработки программных продуктов, значительно снизив потери от необходимости учёта всё новых требований заказчика.

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

Управление жизненным циклом программных средств

Понятие жизненного цикла

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

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

– определение потребностей;

– исследование и описание основных концепций;

– проектирование и разработка;

– испытания системы;

– создание и производство;

– распространение и продажа;

– эксплуатация;

– сопровождение и мониторинг;

– снятие с эксплуатации (утилизация).

Модели жизненного цикла

2.1. Типичная схема управления процессом создания программного обеспечения

Управление процессами при разработке программного обеспечения в общем случае реализуется по спиральной схеме и состоит из следующих повторяемых действий [25]:

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

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

- реализация и изменение процесса (Process Implementation and Change), предусматривающая выполнение разработанного плана по внедрению нового (усовершенствованного) процесса, в результате чего он процесс должен быть внедрен в практику организации;

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

Спиральная модель

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

Боэм формулирует перечень наиболее распространенных (по приоритетам) рисков [25]:

- Дефицит специалистов.

- Нереалистичные сроки и бюджет.

- Реализация несоответствующей функциональности.

- Разработка неправильного пользовательского интерфейса.

- “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.

- Непрекращающийся поток изменений.

- Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.

- Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

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

- “Разрыв” в квалификации специалистов разных областей знаний.

Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.

Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму

В 2000 году [Boehm, 2000], представляя анализ использования спиральной модели и, в частности, построенного на его основе подхода MBASE – Model-Based (System) Architecting and Software Engineering (MBASE), Боэм формулирует 6 ключевых характеристик или практик, обеспечивающих успешное применение спиральной модели:

1. Параллельное, а не последовательное определение артефактов (активов) проекта

2. Согласие в том, что на каждом цикле уделяется внимание:

o целям и ограничениям, важным для заказчика

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

o идентификации и разрешению рисков

o оценки со стороны заинтересованных лиц (в первую очередь заказчика)

o достижению согласия в том, что можно и необходимо двигаться дальше

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

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

5. Управление жизненным циклом в контексте обязательств всех заинтересованных лиц на основе трех контрольных точек:

- Life Cycle Objectives (LCO)

- Life Cycle Architecture (LCA)

- Initial Operational Capability (IOC)

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

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

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

- Concept of Operations (COO) – концепция < использования> системы;

- Life Cycle Objectives (LCO) – цели и содержание жизненного цикла;

- Life Cycle Architecture (LCA) – архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;

- Initial Operational Capability (IOC) – первая версия создаваемого продукта, пригодная для опытной эксплуатации;

- FinalOperationalCapability (FOC) – готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

Достоинства:

– большое внимание раннему анализу возможностей повторного использования;

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

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

– контроль источников проектных работ и соответствующих затрат;

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

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

Недостатки:

– высокая нагрузка на заказчика, который становится, по сути, участником разработки;

– большая сложность в прогнозировании окончания проектных работ;

– наличие риска снижения качества финальной версии ПС по причине отказа от последних итераций для снижения сроков разработки.

Сфера применения:

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

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

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

Качество процессов

ISO/IEC определяет три связанных модели качества программного обеспечения – внутреннее качество, внешнее качество и качество в процессе эксплуатации, а также набор соответствующих работ по оценке качества программного обеспечения (ISO/IEC 14598 [7, 8]).

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

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

– Европейский подход TickIT, рассмотривающий общую систему менеджмента качества ISO 9001 в приложении к программным проектам и представленный, также, в виде специальных рекомендаций ISO 90003-04.

– Американский подход CMMI предоставляющий рекомендации по совершенствованию (повышению зрелости) отдельных процессов.

CMM/CMMI

Наверное, самым именитым стандартом качества следует считать Capability Maturity Model (CMM) – модель оценки уровня зрелости процессов разработки вместе с его производными. Он был создан SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона. Первая официальная версия стандарта вышла в 1993 г., хотя работы над ним начались гораздо раньше – основные его положения были опубликованы еще в 1986 г.

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

Модель CMM (табл. 1) предусматривает пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов (Key Process Areas, KPA).

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

Таблица 1. Уровни модели CMM

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

Стандарт CMM оказался весьма успешным, и впоследствии на его основе была создана целая серия стандартов (табл. 2). Притом он получил новое имя – SW-CMM (Capability Maturity Model for Software), точнее отражающее его положение в достаточно многочисленном семействе стандартов.

Таблица 2. Развитие стандартов CMM

Название стандарта	Описание
System Engineering CMM (SE-CMM)	Ориентирован на вопросы системного инжиниринга – разработку продуктов (анализ требований, проектирование систем продукта и их интеграция) и их производство (планирование производственных линий и функционирование)
Trusted CMM (T-CMM)	Предназначен для обслуживания чувствительных и закрытых программных систем, которые требуют гарантии высокого качества ПО
System Security Engineering CMM (SSE-CMM)	Сфокусирован на аспектах безопасности программной инженерии, обеспечивает безопасный процесс разработки, в том числе и безопасность членов команды создателей
People CMM (P-CMM)	Рассматривает вопросы развития персонала в софтверных организациях
Software Acquisition CMM (SA-CMM)	Охватывает вопросы приобретения программных продуктов у внешних организаций
Integrated Product Development CMM (IPD-CMM)	Служит средой для интеграции усилий по разработке на всех этапах жизненного цикла и со стороны каждого отдела компании

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

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

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

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

Разрешить большинство проблем CMM призван новый стандарт SEI – Capability Maturity Model Integrated (CMMI) – Интегрированная модель оценки уровня зрелости процессов разработки. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний.

Для того чтобы устранить необходимость «выравнивания» процессов организации и быть более приспособленным к ее бизнес-потребностям, а не наоборот, стандарт CMMI имеет две формы представления – классическую, многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная форма представления рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процессов (Process Areas, PA). В табл. 3 дано соответствие уровней зрелости стандарта CMM, а также уровней зрелости многоуровневого представления CMMI и уровней возможностей непрерывного представления CMMI.

Таблица 3. Соответствие уровней CMM/CMMI

№ уровня	Уровень зрелости CMM	Уровень зрелости многоуровневого представления CMMI	Уровень возможностей непрерывного представления CMMI
	–	–	Незавершенный
	Начальный	Начальный	Выполнимый
	Повторяющийся	Управляемый	Управляемый
	Определенный	Определенный	Определенный
	Управляемый	Управляемый количественно	Управляемый количественно
	Оптимизируемый	Оптимизируемый	Оптимизируемый

SEI отказывается от CMM и взамен активно продвигает CMMI, обещая ужесточить контроль за процессом сертификации, вводя новые классы, позволяющие сократить затраты на него и сделать его более привлекательным для небольших организаций; обеспечивая совместимость со стандартами ISO. Однако факт остается фактом: в современных условиях наличие сертификата определенного уровня CMM/CMMI не является таким значимым фактором, как несколько лет назад, и принимается без дополнительных вопросов разве что в проектах, выполняемых по государственному заказу.

TickIT

TickIT – схема сертификации систем менеджмента качества ИТ–компаний на основе стандартов ISO серии 9000, предложенная группой ведущих фирм и некоммерческих организаций Великобритании, работающих в области информатики.

Стандарты ISO серии 9000 – обширная и наиболее распространенная во всем мире серия стандартов качества. Они охватывают множество отраслей современной индустрии и периодически обновляются.

Изначально стандарты ISO серии 9000 слабо учитывали специфику отрасли ПО и были больше ориентированы на производственную сферу. Однако в конце 1980-х годов был выпущен первый ориентированный на области разработки ПО стандарт, получивший название ISO 9000-3: 1997. Несмотря на то, что ISO 9000-3 оперировал терминологией, которая используется при разработке ПО, и рассматривал характерные для программной индустрии вопросы, он являлся не более чем расширенным вариантом ISO 9001: 1994, а потому не всегда соответствовал специфике программных проектов.

Сегодня на смену ISO 9000-3 пришел стандарт ISO/IEC 90003: 2004 [29], который, в свою очередь, является проекцией промышленного стандарта ISO 9001: 2008 на программную индустрию. По сравнению с предыдущим он гораздо более приспособлен к специфике отрасли, в частности, ссылается на модели жизненного цикла программных систем и детально рассматривает вопросы, характерные для разработки ПО. Однако стандарт ISO 90003: 2004 – это стандарт обеспечения качества и не может быть использован для оценки уровня зрелости и предсказания результата программного проекта. В таких случаях прибегают к стандарту ISO/IEC 15504 [39, 40], который предназначен для оценки процесса разработки информационных систем, в частности, программного обеспечения. Он изначально был спроектирован таким образом, чтобы в значительной степени соответствовать существующим в отрасли стандартам оценки процесса создания ПО. Именно это требование определило схожесть стандарта с основными принципами CMM/CMMI. Его текущая версия предусматривает шесть уровней возможностей (от нулевого до пятого), которые соответствуют уровням возможностей непрерывного представления стандарта CMMI (табл. 4).

Таблица 4. Уровни CMMI (2004)

№ уровня	Название уровня возможностей стандарта ISO/IEC 15504	Название уровня возможностей непрерывного представления CMMI
	Незавершенный	Незавершенный
	Выполнимый	Выполнимый
	Управляемый	Управляемый
	Установленный	Определенный
	Предсказуемый	Управляемый количественно
	Оптимизируемый	Оптимизируемый

Следует отметить, что в целом стандарты ISO/IEC 15504 и CMMI взаимозаменяемы, в частности, для CMMI предусматривается режим сертификации, в соответствии с которым одновременно проводится и сертификация по ISO/IEC 15504.

Качество программного продукта регламентирует стандарт ISO/IEC 9126, состоящий из отдельных частей, которые выпускаются независимо. ISO/IEC 9126 предлагает комплексную иерархическую структуру для описания качественных характеристик ПО.

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

Прочие подходы

Начало методологии шести сигм (Six Sigma) было положено в Motorola в конце 1980-х годов. Motorola провозгласила курс на повышение качества производимой продукции, одним из направлений которого было снижение количества дефектов до уровня 6σ (где σ – дисперсия) – 3, 4 дефекта на миллион возможных (на самом деле 3, 4 дефекта на миллион возможных означает не 6, а 4, 5 сигмы, однако разработчики методологии добавили полторы сигмы для того, чтобы учесть нестабильность процессов). Подобное значение было избрано не случайно – в результате проведенных в компании исследований было установлено, что именно такой уровень качества обеспечит, кроме явных преимуществ в виде повышения конкурентоспособности продукции, также сокращение издержек за счет уменьшения затрат на доводку некачественных разработок и устранение дефектов.

Реализация шести сигм происходит в виде процесса DMAIC (Define, Measure, Analyze, Improve, Control):

- определение;

- измерение;

- анализ;

- совершенствование;

- управление.

Этот процесс построен на количественных методах принятия решений. Сильная сторона шести сигм – ориентация на интенсивное применение математического аппарата.

Несмотря на промышленное происхождение, методология шесть сигм получила популярность среди разработчиков ПО. Ориентация на количественные методы позволила применять шесть сигм как инструмент для обеспечения постоянного совершенствования процесса. Особенно заметно его преимущество при использовании в организациях, которые достигли высоких уровней зрелости в соответствии с CMM/CMMI и ISO/IEC 15504.

Недостатки:

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

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

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

Весьма популярная в Европе методология ITIL (IT Infrastructure Library) ориентирована на обеспечение функционирования IT-инфраструктуры. ITIL разработана при участии правительства Великобритании в конце 80-х – начале 90-х годов XX в. и первоначально получила распространение в правительственных проектах этой страны.

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

Библиотека состоит из семи книг, в которых изложен комплекс вопросов по всем аспектам управления ИТ ресурсами предприятия [45]:

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

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

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

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

– Управление безопасностью (Security Management) – детализирует подходы к планированию и управлению безопасностью информации и ИТ сервисов.

– Бизнес–перспектива (The Business Perspective) – описывает подходы к организации деятельности ИТ подразделений как бизнес–подразделений, охватывает вопросы организации взаимоотношений с потребителями и поставщиками, вопросы коммуникаций и обмена знаниями, согласования на стратегическом уровне потребностей бизнеса и возможностей ИТ.

– Планирование внедрения сервисного подхода (Planning to Implement Service Management) – содержит описание подходов к планированию, реализации и совершенствованию процессов управления ИТ сервисами в организациях.

Новая третья версия библиотеки ITIL сосредотачивается главным образом на ИТ-стратегии в рамках организации и на постоянном улучшении сервисов. Библиотека состоит из трёх частей: ядро (core), дополнительные книги (complementary) и интернет-часть (Web). Идеологическая часть ITIL® v3 - ядро - включает пять книг: по сервисной стратегии (service strategy), проектированию сервисов (service design), передаче сервисов (service transition), эксплуатации сервисов (service operation) и их постоянному улучшению (continual service improvement).

ITIL хорошо согласуется со стандартами серии ISO 9000 и может служить основой для проведения по ним последующей сертификации.

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

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

Оценка и аудит

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

1 Назначение управленческих оценок состоит в отслеживании развития проекта (продукта), определения статуса планов и расписаний, утверждения требования и распределения ресурсов, или оценки эффективности управленческих подходов, используемых для достижения поставленных целей. [IEEE 1028-97 “IEEE Standard for Software Reviews”]. Управленческие оценки поддерживают принятие решений о внесении изменений и выполнении корректирующих действий, необходимых в процессе выполнения программного проекта. Управленческие оценки определяют адекватность планов, расписаний и требований, в то же время, контролируя их прогресс или несоответствие. Эти оценки могут выполняться в отношении продукта, будучи фиксируемы в форме отчетов аудита, отчетов о состоянии (развитии),

2 Назначением технических оценок является исследование программного продукта для определения его пригодности для использования в надлежащих целях. Цель состоит в идентификации расхождений с утвержденными спецификациями и стандартами. [IEEE 1028-97 “IEEE Standard for Software Reviews]. Для обеспечения технических оценок необходимо распределение следующих ролей: лицо, принимающее решения, лидер оценки, регистратор, а также технический персонал, поддерживающий (непосредственно исполняющий) действия по оценке. Техническая оценка требует, в обязательном порядке, наличия следующих входных данных:

– формулировки целей;

– конкретного программного продукта (подвергаемого оценке);

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

– списка проблем (вопросов), ассоциированных с продуктом;

– процедуры технической оценки.

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

В дополнение к оценкам ISO 12207 [”] вводит понятия инспекций, прогонок и аудитов:

1 Назначение инспекций состоит в обнаружении и идентификации аномалий в программном продукте. [IEEE 1028-97 “IEEE Standard for Software Reviews”]. Существует два серьезных отличия инспекций от оценок (управленческой и технической):

12 3 4 5 6 7 8 9 10 Следующая ⇒