Управление программными проектами. Учебное пособие

появились перфокарты Германа Холерита. В это же время начало развиваться производство перфокарт и появились перфокарты, считывание которых выполнялось электрическим способом.

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

Команда разработчиков проекта SWEBOK определила пять основных целей:

1Характеристика дисциплины программного инжиниринга.

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

3Выполнение непротиворечивого обзора процесса программного инжиниринга.

4Уточнение места (и набора ограничений) программного инжиниринга относительно других дисциплин, таких как информатика, менеджмент проектов,

компьютерный инжиниринг и математика.

5 Обеспечение фундамента для обучения процессу разработки и

индивидуального сертификационного материала.

Врезультате структурирования областей знаний согласно SWEBOK

охватываются перечисленные ниже области знаний.

Требования к ПО:

1Процесс инжиниринга требований.

2Выявление требований.

3Анализ требований.

4Спецификация требовании.

5Аттестация требований.

6Управление требованиями.

Проектирование ПО:

1Основные концепции, определяющие разработку ПО.

2Структура и архитектура ПО.

3Оценка и анализ качества, реализуемого в процессе разработки ПО.

111

4Записи в процессе проектирования программы.

5Стратегии и методы, применяемые в процессе разработки программ.

Конструирование ПО:

1 Уменьшение степени сложности:

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

методы формального конструирования;

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

2 Предвидение расхождений:

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

методы формального конструирования;

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

3 Структурирование процесса аттестации:

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

методы формального конструирования;

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

4 Использование внешних стандартов:

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

методы формального конструирования;

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

Тестирование ПО:

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

2 Уровни тестирования.

3 Методики тестирования.

4 Измерения, производимые в процессе тестирования.

5 Управление процессом тестирования.

Сопровождение ПО:

1 Основные концепции процесса сопровождения.

2 Ключевые вопросы менеджмента ПО.

3 Методики, применяемые на этапе сопровождения.

112

Менеджмент конфигурации ПО (КПО): 1 Управление процессом КПО.

2 Идентификация конфигурации ПО.

3 Контроль конфигурации ПО.

4 Учет статуса, реализуемого при конфигурации ПО.

5 Поставка и управление версиями ПО.

Управление программным инжинирингом: 1 Организационный менеджмент.

2Менеджмент процессов/проектов.

3Измерения на стадии программного инжиниринга.

Процесс программного инжиниринга

1 Концепции процесса программного инжиниринга.

2 Инфраструктура процесса.

3 Измерения, осуществляемые при выполнении процесса.

4 Определение процесса.

5 Количественный анализ процесса.

6 Реализация и изменения процесса.

Инструменты и методы программного инжиниринга.

1 Программные инструменты:

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

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

инструменты конструирования программ.

инструменты тестирования программ.

инструменты, предназначенные для тестирования программ.

инструменты, реализующие поддержку процесса инжиниринга.

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

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

инструменты, позволяющие реализовывать инжиниринг ПО.

инструменты, обеспечивающие поддержку необходимой инфраструктуры.

113

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

2 Программные методы:

эвристические методы.

формальные методы.

методы прототипирования.

различные вопросы, связанные с применением методов.

Вопросы качества ПО:

1Концепции, определяющие качество ПО.

2Определение и планирование качества.

3Методики, требующие усилий двух или большего числа исполнителей.

4Поддержка других методов.

5Специальное тестирование по программе обеспечения качества ПО, а также выполнения аттестации / верификации.

6Методика поиска дефектов.

7Измерения при анализе качества ПО.

6.3 Документы SWEBOK и модель SEICMM

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

На рисунке 6.2 изображены 5 уровней зрелости, а также соответствующие им ключевые области процессов. Модель CMM является своего рода «дорожной картой», гарантирующей успешное улучшение процесса. Её интерпретация и применение в контексте бизнес-целей организации.

114

Оптимизация (5)

•Предотваращение появления дефектов

•Управдение технологическими изменениями

•Управление изменением процесса

Управляемый (4)

•Количественный менеджмент процесса

•Менеджмент качества ПО

Определенный (3)

•Область действий организационного процесса

•Определение организационного процесса

•Разработка программных продуктов

•Комплексный менеджмент ПО

•Взаимодействие между группами Экспертные оценки

•Учебная программа

Повторяемый (2)

•Управление требованиями

•Планирование программных проектов

•Обзор и отслеживпние ПО

•Менеджмент субподрядными договорами, заключенными на разработку ПО

•Менеджмент конфигурации ПО

•Обеспечение качества ПО

Начальный (1)

Рисунок 6.2 – Ключевые области процесса SEICMM, систематизированные

согласно уровням зрелости

115

7 Обеспечение надежности ПО

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

представлена топология факторов качества, представленная Макколом, Ричардсом и Уолтерсом (МсСall,Richards, Walters) в их совместной работе, датированной 1977

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

Рисунок 7.1 – Факторы качества ПО

Стандартный словарь терминов программного инжиниринга (IЕЕЕ

StandartGlossaryofSoftwareEngineeringTerminology) определяет надежность ПО как способность системы или компонента выполнять требуемые функции в заданных

116

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

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

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

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

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

инвестируемых в обеспечение надежности ПО.

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

В данной главе мы остановимся на рассмотрении четырех методик,

обеспечивающих создание высоконадежного ПО:

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

2Предотвращение ошибок – формальные методы, повторное использование

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

117

3Устранение ошибок – формальные инспекции, верификация и аттестация.

4Устойчивость к отказам – методики мониторинга, верификация решений,

избыточность, исключение.

7.1 Термины, используемые при определении надежности ПО

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

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

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

Ошибка – ошибка, обнаруженная на текущей фазе или при выполнении настоящего процесса.

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

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

Проблемы – отклонение от заданных технических характеристик или ожидаемых результатов.

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

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

которая в конечном итоге становится явной.

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

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

118

Ошибки ПО происходят в силу дефектов/ошибок проекта (система или ПО),

дефектов/ошибок кодирования, организационных ошибок, несостоятельности

отладки и ошибок тестирования.

7.2 Прогнозирование ошибок, предотвращение сбоев, устранение ошибок,

отказоустойчивость

Прогноз сбоев воплощает предсказуемый подход к разработке надежного ПО.

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

Единственный способ обеспечения даже небольшой степени точности для прогнози-

рующих моделей заключается в предоставлении доступа к соответствующим ис-

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

Таблица 7.1 – Действия жизненного цикла разработки НО, относящиеся к прогнозированию сбоев

Требования и исследование системы Прогнозирование

Определение функционального профиля

Определение и классификация сбоев

Идентификация потребностей заказчиков в обеспечении требуемого уровня надежности

Альтернативные учебные курсы

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

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

119

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

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

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

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

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

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

Классификация, разработанная Борисом Бейдером (BorisBeizer).имеет соответствующие уровни легализации:

1Слабый – симптомы имеют эстетический характер.

2Умеренный – выходные данные некорректны или избыточны.

3Раздражающий – вызывает некорректное поведение системы (например,

банкомат отказывается выдавать наличные деньги).

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

5Экстремальный – проблема не ограничивается несколькими пользователями.

6Невыносимый – база данных надолго и непоправимо выходит из строя.

120