Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

642 Приложение 5

1.11. Обоснован ли выбор применяемых языков программирования, общесис-

темного ПО (СУБД, сетей и пр.) и технических средств в контексте принятых в про-

екте алгоритмов функционирования, модели данных, математического аппарата?

Адекватен ли он соответствующим требованиям ТЗ? Согласованы ли решения по

данному вопросу?

1.12. Указаны ли используемые при разработке эскизного проекта (ЭП) между-

народные, государственные, отраслевые и другие стандарты и нормативно- техниче-

ские документы? Соблюдены ли их требования по форме и содержанию?

2. Совместимость

2.1. Все ли функции будут реализованы непосредственно в данном проекте? Предпола-

гается ли использование заимствованных (унифицированных) проектных решений?

2.2. Достаточно ли полно определены "внутренние" интерфейсы для использования за-

имствованных компонентов ПО?

2.3. Согласованы ли внутренние интерфейсы по сопрягаемым алгоритмам, передавае-

мым (принимаемым, промежуточным) структурам данных?

2.4. Предполагается ли интеграция разрабатываемого ПО с другими? Достаточно ли

полно описаны внешние интерфейсы?

2.5. Обеспечивается ли совместимость выбранных языков программирования, общесис-

темных программных и технических средств?

2.6. Предполагает ли проект разработку собственных средств межъязыкового интер-

фейса для обеспечения совместимости языков программирования?

2.7. Обеспечивается ли информационная совместимость в проекте? Все ли информаци-

онные структуры совместимы?

3. Производительность (эффективность)

3.1. Регламентируется ли приемлемый уровень эффективности (по скорости обработки,

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

или требованиями заказчика?

3.2. Обоснована ли эффективность предлагаемых проектных решений? Указаны ли

ожидаемые технико-экономические показатели?

3.3. Учитывают ли проектные решения требования стандартов по эффективности и со-

ответствующие данные аналогов ПО?

3.4. Учитывают ли методы организации и доступа к данным особенности модели дан-

ных, объемы и интенсивность обработки данных?

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

ки программирования требуемую точность вычислений? Учтены ли вычислительные

возможности технических средств?

3.6. Обеспечивают ли алгоритмы требуемую скорость обработки данных?

3.7. Предполагается ли использование оптимизирующих компиляторов, сопроцессо-

ров, расширенной памяти и других специализированных методов и средств? Адек-

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

ПО?

4. Надежность

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

ритмы защиту данных?

4.2. Обеспечивается ли разграничение доступа к возможностям ПО (при наличии тре-

бований в ТЗ)?

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

казам программных и технических средств? Как будет их объем и стоимость сказы-

ваться на эффективности ПО?

Приложение 5 643

4.4. Предусматривает ли проект разработку средств контроля и обнаружения ошибок

пользователя, ошибок ввода и передачи данных, контроля хода вычислений и соот-

ветствующих средств диагностики?

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

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

контрольные точки, ведение страховой копии)?

4.6. Адекватны ли проектные решения по восстановлению требованиям в ТЗ к среднему

времени восстановления (при их наличии)?

4.7. Разработаны ли планы и процедуры тестирования (испытаний)? Адекватны ли они

требованиям к проведению испытаний?

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

проекта (иерархичность, структурность, понятность)?

5. Удобство применения

5.1. Учитывает ли проект в целом эргономические требования (при их наличии) к ПО,

связанные с удобством применения и освоения?

5.2. Предполагается ли режим подсказки (помощи, контекстные справки) для пользова-

теля?

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

лексики пользователя?

5.4. Предусмотрена ли разработка средств, облегчающих освоение ПО, а также приме-

ров, иллюстрирующих возможности ПО, учебных материалов и курсов?

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

требованиям (выбор цветовой палитры, удобное размещение информации на экране

и т.п.)?

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

ному уровню пользователя?

6. Сопровождаемость

6.1. Предусматривается ли возможность выбора (изменения) варианта организации

данных?

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

новными программными функциями?

6.3. Достаточно ли прослеживаемы все проектные решения?

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

туры, возможности технических средств)?

6.5. Предполагается ли разработка средств администратора в ПО (при наличии в ТЗ

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

и т.п.)?

6.6. Обеспечивает ли выбранный подход к проектированию удобство модификации

(структурность, независимость и т.д.)?

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

средств трассировки, диагностики, сбора статистики, дампирования и анализа?

7. Мобильность (переносимость)

7.1. Достаточно ли универсальны представленные алгоритмы с позиций их переноси-

мости?

7.2. Используются ли стандартные соглашения по организации доступа к данным в

проекте, передаваемым и принимаемым данным? Предполагается ли применение не-

стандартных методов организации и доступа к данным? Насколько они обоснованы?

7.3. Отвечают ли выбранные языки программирования, операционная система требова-

ниям мобильности?

7.4. Учитывает ли структура проекта требования переносимости (независимость верх-

них уровней иерархии от среды реализации)?

644 Приложение 5

Вопросы для инспекции программного кода

1. Простота понимания и соответствие стандартам кодирования

1.1. Понятны ли спецификации элемента?

1.2. Понятен ли код элемента? Есть ли проблемы в понимании?

1.3. Откомментирован ли код? Помогают ли комментарии понять процедуры и функции

элемента?

1.4. Могут ли быть трудности при модификации элемента?

1.5. Установлены ли в проекте стандарты кодирования?

1.6. Соответствует ли код установленным стандартам кодирования?

1.7. Разработаны ли тесты для проверки соблюдения стандартов?

2. Корректность обращения к данным

2.1. Используются ли переменные с не установленными значениями?

2.2. Не выходит ли значение каждого из индексов за границы, определенные для соот-

ветствующего измерения при всех обращениях к массиву?

2.3. Принимает ли каждый индекс целые значения при всех обращениях к массиву? Не

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

опасность.

2.4. Для всех ли обращений с помощью указателей или переменных-ссылок память, к

которой производится обращение, распределена (есть ли "подвешенные" обраще-

ния)?

2.5. Корректны ли атрибуты при всех псевдонимах? Если одна и та же область памяти

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

данных в этой области корректные атрибуты при обращении по одному из этих псев-

донимов?

2.6. Соответствуют ли атрибуты записи и структуры?

2.7. Отличаются ли типы или атрибуты переменных величин от тех, которые предпола-

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

ет записи из памяти и обращается к ним как к структурам, но физическое представ-

ление записей отлично от описания структуры.

2.8. Вычислимы ли адреса битовых строк? Передаются ли битовые строки в качестве

аргументов?

2.9. Если к структуре данных обращаются из нескольких процедур или подпрограмм, то

определена ли эта структура одинаково в каждой процедуре?

2.10. Не превышены ли границы строки при индексации в ней?

2.11. Существуют ли какие-нибудь другие ошибки в операциях с индексацией

или при обращении к массиву по индексу?

3. Корректность описания данных

3.1. Все ли переменные описаны явно?

3.2. Если начальные значения присваиваются переменным в операторах описания, то

правильно ли инициализируются эти значения?

3.3. Правильно ли для каждой переменной определены длина, тип и класс памяти?

3.4. Согласуется ли инициализация переменной с ее типом памяти?

3.5. Есть ли переменные со сходными именами?

4. Корректность вычислений

4.1. Есть ли вычисления, использующие переменные недопустимых типов?

4.2. Есть ли вычисления, использующие данные разного типа (смешанные вычисле-

ния)? Возможно ли усечение дробной части?

4.3. Существуют ли вычисления, использующие переменные одного типа, но разной

длины?

4.4. Не меньше ли длина результата, чем длина вычисляемого значения?

Приложение 5 645

4.5. Возможно ли переполнение или потеря промежуточного результата во время вы-

числения?

4.6. Возможно ли, чтобы делитель в операторе был равен нулю?

4.7. Возможет ли выход значения переменной за пределы ее диапазона ?

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

5. Корректность сравнения данных

5.1. Сравниваются ли величины несовместимых типов (например, строка символов с

адресом)?

5.2. Сравниваются ли величины различных типов?

5.3. Корректны ли отношения сравнения?

5.4. Корректны ли булевские выражения?

5.5. Объединяются ли сравнения и булевские выражения?

5.6. Сравниваются ли дробные величины, представленные в двоичной форме?

5.7. Понятен ли порядок следования операторов?

6. Корректность передачи управления

6.1. Может ли значение индекса в переключателе превысить число переходов?

6.2. Будет ли завершен каждый цикл?

6.3. Будет ли завершена программа?

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

6.5. Корректны ли возможные погружения в цикл?

6.6. Есть ли ошибки отклонения числа итераций от нормы?

6.7. Соответствуют ли друг другу операторы DO и END в группах DO-END?

7. Корректность интерфейса между модулями

7.1. Есть ли несоответствие количества, порядка, типов и размеров параметров в вызы-

вающем и вызываемом модулях (подпрограммах)?

7.2. Если модуль имеет несколько точек входа, передается ли параметр всегда вне зави-

симости от точки входа?

7.3. Не изменяет ли подпрограмма параметр, который должен использоваться только

как входная величина?

7.4. Все ли глобальные переменные используются правильно?

7.5. Передаются ли в качестве аргументов константы?

8. Корректность ввода-вывода

8.1. Нет ли ошибок в описаниях атрибутов файлов и операторах ввода-вывода?

8.2. Соответствует ли размер буфера размеру записи?

8.3. Открыты ли файлы перед их использованием?

8.4. Обнаруживаются ли признаки конца файла?

8.5. Обнаруживаются ли ошибки ввода-вывода?

8.6. Существуют ли текстовые ошибки в выходной информации?

646

Приложение 6. ВОПРОСЫ ДЛЯ ОЦЕНКИ РИСКА

ПРОЕКТА

Вопросы для анализа и оценки риска проекта объединены в группы в соот-

ветствии с трехуровневой таксономией “класс-элемент-атрибут” (таблица 6.1).

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

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

нумерацию. Форма задания вопросов выбрана с учетом удобства автоматизации

обработки вопросника.

Вопросник содержит несколько вопросов к одному атрибуту таксономии,

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

которые связаны с указанным атрибутом.

Каждому вопросу приписан максимальный вес, отражающий важность дан-

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

ше вес, тем существеннее вопрос с точки зрения обнаружения риска.

Возможные варианты ответа на вопрос таковы: “Да”, “Нет”, “Частично”,

“Не знаю”, “Не применим”.

Ответ “Да” свидетельствует об отсутствии риска, суть которого сформули-

рована в вопросе.

Ответ “Нет” или “Не знаю” свидетельствует о наличии риска.

Ответ “Частично” также свидетельствует о наличии риска, но дает возмож-

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

мого в таблице максимального веса.

Ответ “Не применим” соответствует неправомерности задания вопроса для

данного проекта.

Класс А. Технические аспекты разработки

Таблица 6.1. Вопросы для оценки рисков по элементу «Требования»

Класс:

Технические аспекты разработки

Элемент:

Требования

Атрибут Код Вопрос Вес

1.1.1 Остаются ли стабильными требования в ходе

разработки?

a) Стабильность (цель

- выяснить, изменяются

ли требования в про-

цессе реализации)

1.1.2 Не могут ли измениться внешние интерфейсы? 10

1.2.1 Нет ли требований, уточнение которых отложе-

но для последующего определения?

1.2.2 Отражены ли в спецификации все известные

или предполагаемые требования?

б) Полнота

(цель - выяснить, есть

ли пропущенные или не

полностью описанные

требования)

1.2.3 Можно ли установить любое пропущенное тре-

бование к системе?

1.2.4 Зафиксированы ли документально все требова-

ния и пожелания заказчика к системе?

1.2.5 Если да, то можно ли отразить эти требования в

системе?

Приложение 6 647

1.2.6 Полностью ли определены внешние интерфей-

сы?

1.3.1 Понятны ли требования, изложенные в докумен-

те?

в) Однозначность

(цель - выяснить, нуж-

даются ли требования в

разъяснении или ин-

терпретации)

1.3.2 Можно ли устранить все неоднозначности в тре-

бованиях?

1.4.1 Включены ли в требования все пожелания поль-

зователя?

1.4.2 Есть ли план действий по проверке охвата тре-

бованиями пожеланий пользователя?

1.4.3 Одинаково ли понимание требований разработ-

чиком и заказчиком?

1.4.4

Если да, то можно ли это обосновать (например,

с помощью прототипирования, анализа, модели-

рования и др.)?

г) Достоверность

(цель - выяснить, отве-

чают ли требования к

системе ожиданиям

заказчика)

1.4.5 Есть ли согласованный план валидации требо-

ваний?

1.5.1 Все ли требования технически реализуемы? 10

1.5.2 Можно ли выявить и упорядочить по приорите-

там трудности технической реализации требова-

ний?

1.5.3 Проводится ли исследование возможности реа-

лизации требований?

д) Реализуемость

(цель - выяснить, пока-

зывает ли анализ тре-

бований возможность

их реализации)

1.5.4 Есть ли гарантии правильности результатов ис-

следования?

1.6.1 Удалось ли избежать “беспрецедентных” требо-

ваний (в таких областях как новые технологии,

методы, языки или аппаратное обеспечение)?

1.6.2 Имеют ли разработчики и заказчики необходи-

мый спектр знаний в этих областях?

е) Новизна

(цель - выяснить, есть

ли у разработчика опыт

создания подобных

систем)

1.6.3 Есть ли план получения необходимых знаний в

этих областях?

1.7.1 Приемлемы ли объем и сложность системы для

разработки?

1.7.2 Есть ли опыт разработки подобных крупномас-

штабных систем?

ж) Масштабность

(цель - выяснить, есть

ли опыт разработки

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

объема и сложности)

1.7.3 Могут ли быть обеспечены в организации усло-

вия разработки, адекватные масштабу разраба-

тываемой системы (достаточно ли велика сама

организация-разработчик)?

648 Приложение 6

Таблица 6.2. Вопросы для оценки риска по элементу «Проект»

Класс:

Технические аспекты разработки

Элемент:

Проект

Атрибут Код Вопрос Вес

2.1.1 Соответствуют ли алгоритмы или проектные

решения предъявленным функциональным тре-

бованиям?

a) Функциональ-

ность

(цель - выяснить,

есть ли потенциаль-

ные проблемы с

удовлетворением

функциональных

требований)

2.1.2 Существует ли утвержденная процедура демон-

страции возможности реализации алгоритмов

или проектных решений (например, прототипи-

рование, анализ, моделирование)?

2.2.1 Все ли проектные решения основаны на досто-

верных и устоявшихся предпосылках?

2.2.2 Все ли требования или функции целесообразно

реализовывать?

б) Сложность

(цель - выяснить,

трудно ли будет

спроектировать и/

или реализовать про-

ект)

2.2.3 Есть ли проектные решения по всем требовани-

ям?

2.3.1 Хорошо ли определены внутренние интерфейсы

(программно-аппаратные, программные)?

2.3.2 Оформлено ли определение внутренних интер-

фейсов в виде процесса?

2.3.3 Обеспечивает ли этот процесс контроль за из-

менениями внутренних интерфейсов?

2.3.4 Ведется ли разработка требуемого аппаратного

обеспечения параллельно с разработкой ПО?

2.3.5 Окончательны ли спецификации аппаратного

обеспечения?

2.3.6 Определены ли все интерфейсы с ПО? 10

в) Интерфейсы

(цель - выяснить,

хорошо ли опреде-

ляются и контроли-

руются все внутрен-

ние интерфейсы)

2.3.7 Будут ли модели проектирования ПО таковыми,

что смогут применяться для тестирования ПО?

2.4.1 Решены ли проблемы производительности (в

таких областях риска как пропускная способ-

ность каналов, распределение асинхронных со-

бытий в масштабе реального времени, доступ к

БД и обработка запросов)?

2.4.2 Проведен ли анализ характеристик производи-

тельности?

2.4.3 Есть ли уверенность в его результатах? 10

г) Производитель-

ность

(цель - выяснить,

установлены ли же-

сткие ограничения по

времени обработки

или пропускной спо-

собности каналов)

2.4.4 Существует ли модель отслеживания произво-

дительности от начала проекта до реализации

продукта?

д) Тестопригод-

ность

2.5.1 Легко ли будет тестировать ПО? 8

Приложение 6 649

2.5.2 Включены ли в проект средства (свойства), об-

легчающие тестирование?

10 (цель - выяснить, в

какой мере будет

сложно тестировать

продукт)

2.5.3 Привлекаются ли тестировщики к процессу ана-

лиза требований?

е) Аппаратные ог-

раничения

(цель - выяснить,

есть ли ограничения

на целевое аппарат-

ное обеспечение)

2.6.1 Обеспечивает ли аппаратура реализацию требо-

ваний к системе (к архитектуре, объему памяти,

пропускной способности каналов, времени обра-

ботки запросов, производительности БД, функ-

циональности, надежности, пригодности)?

Если применяется повторно используемое

или модифицированное ПО

2.7.1 Не применяется ли при разработке системы по-

вторно используемое или модифицируемое ПО?

2.7.2 Разрешены ли все проблемы с поставкой, доку-

ментацией, эффективностью функционирования

или настройкой такого ПО?

Если применяется коммерческое ПО

2.7.3 Решены ли все проблемы, связанные с использо-

ванием приобретенного коммерческого ПО (не-

хватка документации для определения интер-

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

эффективность; большой объем требуемой опе-

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

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

сопровождения разработчика и т.п.)?

2.7.4 Обеспечивается ли обновление версий приобре-

тенного ПО и их проверка?

ж) Приобретаемое

ПО

(цель - выяснить,

есть ли проблемы с

повторно используе-

мым или приобре-

тенным ПО)

2.7.5 Приобретено ли коммерческое ПО у официаль-

ных представителей (дилеров)?

Таблица 6.3. Вопросы для оценки риска по элементу «Кодирование и

автономное тестирование»

Класс:

Технические аспекты разработки

Элемент:

Кодирование и автономное тестирование

Атрибут Код Вопрос Вес

3.1.1 Достаточно ли полно и однозначно определены

элементы проекта для реализации?

а) Реализуемость

(цель - выяснить,

легко ли реализовать

проект)

3.1.2 Легко ли можно реализовать алгоритмы и про-

ектные решения?

3.2.1 Будет ли автономное тестирование начинаться

только после верификации (проверки) исходного

кода по отношению к проекту?

б) Автономное тес-

тирование

3.2.2 Отделено ли автономное тестирование от отлад-

ки (как самостоятельное действие)?

650 Приложение 6

3.2.3 Достаточно ли времени для выполнения всех

автономных тестов?

10 (цель - выяснить,

адекватно ли уста-

новлены уровни и

время автономного

тестирования)

3.2.4 Сохранится ли запланированный объем авто-

номного тестирования при недостатке времени

на его полное выполнение?

3.3.1 Достаточно ли подробны проектные специфи-

кации для написания кода?

3.3.2 Окончательны ли проектные решения и специ-

фикации перед началом кодирования?

3.3.3 Адекватны ли системные ограничения (по вре-

мени, оперативной и внешней памяти) сложно-

сти реализации?

3.3.4 Удачно ли выбран язык реализации ПО для дан-

ной системы?

3.3.5 Один ли язык используется для реализации ПО? 8

3.3.6 Если нет, совместимы ли их межъязыковые ин-

терфейсы?

3.3.7 Разрабатывается ли ПО на той же модели ком-

пьютера, на которой предполагается его экс-

плуатация?

3.3.8 Если нет, то поддерживают ли оба компьютера

один и тот же компилятор?

3.3.9 Если в рамках системы разрабатывается аппа-

ратное обеспечение, то адекватны ли специфи-

кации аппаратуры для реализации ПО?

в) Кодирование/

реализация

(цель - выяснить,

есть ли проблемы,

связанные с кодиро-

ванием/реализацией)

3.3.10 Окончательны ли спецификации аппаратуры

перед началом реализации?

Таблица 6.4. Вопросы для оценки риска по элементу «Интеграция и

интеграционное тестирование»

Класс:

Технические аспекты разработки

Элемент:

Интеграция и интеграционное тестирование

Атрибут Код Вопрос Вес

4.1.1 Соответствуют ли аппаратные средства зада-

чам интеграции и тестирования?

а) Среда

(цель - выяснить,

адекватна ли среда

для интеграции и

тестирования)

4.1.2 Реалистичны ли разработанные сценарии и тес-

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

любых требований к системе (например, специ-

фицированных потоков данных, обработки за-

просов в масштабе реального времени, управле-

ния асинхронными процессами, многопользова-

тельского режима взаимодействия)?

4.1.3 Можно ли проверить производительность сис-

темы в среде разработки?

4.1.4 Применяются ли аппаратные и программные

средства поддержки тестирования?

Приложение 6 651

4.1.5 Если да, то достаточны ли они для полного тес-

тирования?

4.2.1 Доступна ли, при необходимости, целевая аппа-

ратно-программная среда?

4.2.2 Согласованы ли критерии приемки по всем тре-

бованиям?

4.2.3 Если да, то строго ли они установлены? 10

4.2.4 Хорошо ли определены, описаны и стандартизо-

ваны внешние интерфейсы?

4.2.5 Можно ли проверить все требования? 10

4.2.6 Хорошо ли специфицирована интеграция про-

дукта?

4.2.7 Достаточно ли времени выделено на интегра-

цию и тестирование?

4.2.8 Если применяются готовые программные про-

дукты, то будут ли данные поставщика учиты-

ваться при верификации требований, связанных

с этими продуктами?

б) Интеграция про-

дукта

(цель - выяснить,

есть ли плохо опре-

деленные интерфей-

сы и неадекватные

средства и достаточ-

но ли времени на

интеграцию)

4.2.9 Если да, то оговорено ли это в контракте с по-

ставщиком?

4.3.1 Достаточно ли четко специфицирована инте-

грация системы?

4.3.2 Достаточно ли времени выделено для интегра-

ции и тестирования системы?

4.3.3 Все ли уровни соисполнителей представлены в

группе, выполняющей системную интеграцию?

4.3.4 Не встраивается ли продукт в существующую

систему?

4.3.5 Если встраивается, то выделен ли период време-

ни для встраивания?

4.3.6 Если не встраивается, то можно ли гарантиро-

вать, что интегрированная система будет рабо-

тать корректно?

в) Интеграция сис-

темы

(цель - выяснить,

хорошо ли коорди-

нируются и управля-

ются работы по инте-

грации системы, хо-

рошо ли определены

интерфейсы и сис-

темные средства)

4.3.7 Не придется ли выполнять интеграцию у заказ-

чика (пользователя)?

Таблица 6.5. Вопросы для оценки риска по элементу

«Нефункциональные характеристики»

Класс:

Технические аспекты разработки

Элемент:

Нефункциональные характеристики

Атрибут Код Вопрос Вес

а) Удобство сопро-

вождения

5.1.1 Учтены ли в системной архитектуре, проектных

решениях или программном коде требования к

удобству сопровождения?