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

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

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

5.1.2 Вовлекается ли персонал сопровождения сис-

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

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

дет ли реализованная

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

понимания и сопро-

вождения)

5.1.3 Адекватна ли системная документация потреб-

ностям сопровождения системы внешней или

сторонней организацией?

5.2.1 Учтены ли требования к надежности системы

при разработке ПО?

5.2.2 Учтены ли требования к готовности (восстанав-

ливаемости) системы при разработке ПО?

б) Надежность

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

трудно ли обеспечить

требования к надеж-

ности и готовности

системы)

5.2.3 Удовлетворительно ли время восстановления

работоспособности системы при сбоях?

5.3.1 Не предъявляются ли требования к защите сис-

темы при разработке ПО?

5.3.2 Если предъявляются, то можно ли обеспечить

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

в) Защищенность

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

можно ли обеспечить

достижимость требо-

ваний к защите сис-

темы)

5.3.3 Удовлетворены ли необходимые требования к

защищенности?

5.4.1 Не являются ли требования к уровню безопас-

ности более строгими, чем это принято для дан-

ного класса систем?

г) Безопасность

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

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

ния к безопасности

жестче обычных для

данного класса сис-

тем)

5.4.2 Был ли требуемый уровень безопасности уже

реализован ранее?

5.5.1 Удовлетворяет ли интерфейс конечного поль-

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

5.5.2 Применяется ли прототипирование ПО с “вы-

брасыванием” прототипа?

5.5.3 Делается ли эволюционная разработка? 5

5.5.4 Есть ли опыт разработки по применяемой мо-

дели прототипирования?

5.5.5 Поставляются ли заказчику промежуточные

версии?

д) Человеческие

факторы

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

гут ли возникнуть

трудности при экс-

плуатации системы

из-за плохо опреде-

ленного интерфейса с

конечным пользова-

телем)

5.5.6 Согласованы ли поставки с процедурами кон-

троля изменений версий?

5.6.1 Адекватны ли спецификации требований проек-

ту системы?

5.6.2 Адекватны ли спецификации аппаратуры про-

екту и реализации ПО?

5.6.3 Хорошо ли описаны спецификации внешних

интерфейсов?

5.6.4 Адекватны ли описания тестов потребностям

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

е) Спецификации

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

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

ментация потребно-

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

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

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

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

стям реализации системы?

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

Класс В. Среда и технология разработки

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

разработки»

Класс:

Среда и технология разработки

Элемент:

Процесс разработки

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

6.1.1 Выполняется ли разработка системы в рамках

единой модели (спиральной, каскадной, поша-

говой)?

6.1.2 Если нет, то просто ли выполнять координацию

между разными моделями?

а) Формализован-

ность

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

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

нять и поддерживать

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

6.1.3 Есть ли четкие и контролируемые планы по

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

6.1.4 Хорошо ли эти планы специфицируют процесс

разработки?

6.1.5 Знакомы ли разработчики с этими планами? 10

6.2.1 Соответствует ли процесс разработки типу

продукта?

б) Укомплектован-

ность

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

соответствуют ли

элементы процесса

модели разработки

(ЖЦ) ?)

6.2.2 Поддерживается ли процесс разработки со-

вместимым набором процедур, методов и инст-

рументов?

6.3.1 Все ли разработчики действуют в рамках уста-

новленного процесса разработки?

6.3.2 Можно ли измерить, насколько процесс разра-

ботки обеспечивает достижение целей произво-

дительности и качества?

в) Контролируе-

мость процесса

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

выполняется ли кон-

троль процесса с по-

мощью метрик?)

6.3.3 Хорошо ли координируются работы между со-

исполнителями?

г) Опыт примене-

ния

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

смогут ли разработ-

чики применять про-

цесс)

6.4.1 Имеют ли разработчики опыт работы в рамках

установленного технологического процесса раз-

работки?

6.5.1 Существует ли механизм трассировки требова-

ний с целью их контроля начиная от исходных

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

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

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

разработку?

6.5.3 Формализован ли процесс контроля изменений? 10

д) Контролируе-

мость продукта

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

существуют ли меха-

низмы контроля из-

менений продукта)

6.5.4 Если да, то отслеживаются ли изменения всех

рабочих продуктов (или релизов) разработки

(требований, проекта, кода и документации)?

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

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

ний, внесенных на любом уровне - от уровня

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

6.5.6 Проводится ли надлежащий анализ влияния

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

требований?

6.5.7 Есть ли возможность проследить интерфейсы? 10

6.5.8 Обновляются ли планы и процедуры тестирова-

ния в рамках процесса изменений?

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

разработки»

Класс:

Среда и технология разработки

Элемент:

Система поддержки разработки

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

7.1.1 Достаточно ли количество и мощность рабочих

станций для всех разработчиков?

а) Мощность

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

достаточна ли для

работы мощность

рабочих станций,

объем внешней и

оперативной памяти)

7.1.2 Достаточно ли мощностей для перекрываю-

щихся стадий разработки, таких как кодирова-

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

б) Укомплектован-

ность

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

насколько система

поддержки разработ-

ки охватывает все

стадии, процедуры и

функции)

7.2.1 Обеспечивает ли система поддержки разработ-

ки автоматизацию всех аспектов разработки

(анализ требований, анализ производительности,

проектирование, кодирование, тестирование,

документирование, управление конфигурацией,

трассировку требований)?

7.3.1 Считают ли пользователи систему поддержки

разработки удобной и легкой в применении?

в) Удобство приме-

нения

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

насколько легко

применять систему

поддержки разработ-

ки)

7.3.2 Есть ли хорошая документация по системе раз-

работки?

г) Опыт примене-

ния

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

достаточно ли опыта

применения)

7.3.3 Есть ли у разработчиков опыт работы с инст-

рументами и методами системы поддержки раз-

работки?

д) Надежность

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

надежна ли система в

работе)

7.4.1 Считается ли система поддержки разработки

надежной (отказоустойчивой, восстанавливае-

мой и др.)?

е) Сопровождае-

мость

7.5.1 Проходят ли сотрудники обучение применению

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

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

7.5.2 Доступны ли квалифицированные специалисты

по системе?

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

ли регулярное об-

служивание системы

со стороны продавца,

консультанта)

7.5.3 Быстро ли поставщики системы реагируют на

возникающие проблемы?

7.6.1 Устанавливается ли система поддержки разра-

ботки у заказчика?

ж) Поставка

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

предъявляются ли

определенные требо-

вания к поставке)

7.6.2 Выделены ли соответствующие ресурсы (сред-

ства, сроки, люди) для проверки и выполнения

установки этой системы?

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

Класс:

Среда и технология разработки

Элемент:

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

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

8.1.1 Выполняется ли управление проектом в соот-

ветствии с планом?

8.1.2 Вносятся ли своевременно изменения в план

при его срывах?

8.1.3 Привлекаются ли исполнители всех уровней к

планированию своих работ?

8.1.4 Есть ли альтернативные планы для известных

рисков?

а) Планирование

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

пригоден ли план

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

кой)

8.1.5 Есть ли установленные критерии для определе-

ния момента ввода альтернативных планов в

действие?

8.1.6 Адекватно ли отражаются в плане вопросы дол-

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

8.2.1 Эффективна ли организация работ? 10

8.2.2 Понимают ли сотрудники собственные обязан-

ности и обязанности других?

б) Организация

проекта

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

ясны ли персоналу

должностные обя-

занности и распреде-

ление ответственно-

сти в проекте)

8.2.3 Знают ли сотрудники, кто несет ответствен-

ность за каждый участок работы?

в) Опыт управле-

ния

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

имеет ли руководи-

тель проекта опыт в

разработке ПО,

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

боткой, предметной

области, утвержден-

ном процессе разра-

ботки и др.)

8.3.1 Есть ли в проекте опытные менеджеры в таких

областях, как управление разработкой ПО и

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

процесс разработки, предметная область проек-

та и др.?

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

8.4.1 Нет ли проблем взаимодействия на всех уров-

нях управления разработкой?

8.4.2 Своевременно ли фиксируются и устраняются

разногласия с заказчиком?

8.4.3 Привлекаются ли разработчики к участию в

совещаниях с заказчиком?

8.4.4 Дает ли управление работами уверенность в

том, что все замечания заказчика воплощаются в

решения, касающиеся функциональных и экс-

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

г) Организация

взаимодействия

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

хорошо ли налажено

взаимодействие всех

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

заинтересованных

лиц)

8.4.5 Объективная ли информация о состоянии про-

екта доводится до заказчика и руководства ор-

ганизации?

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

Класс:

Среда и технология разработки

Элемент:

Методы управления

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

9.1.1 Составляются ли периодические структуриро-

ванные отчеты о состоянии разработки?

9.1.2 Если да, получают ли составители отчетов от-

клики на них?

9.1.3 Направляется ли соответствующая информация

о состоянии проекта на нужные организацион-

ные уровни?

9.1.4 Отслеживается ли продвижение разработки по

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

а) Мониторинг

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

определены ли мет-

рики управления

проектом и отслежи-

вается ли продвиже-

ние разработки)

9.1.5 Есть ли у руководства проекта объективное

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

9.2.1 Проходят ли сотрудники необходимое обуче-

ние?

9.2.2 Входит ли это в планы проекта? 10

9.2.3 Принимается ли во внимание при назначении

исполнителей их опыт работы по соответст-

вующему профилю?

9.2.4 Легко ли управлять данным коллективом? 10

9.2.5 Знают ли разработчики всех уровней о своем

статусе в проекте согласно утвержденному пла-

ну?

б) Управление пер-

соналом

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

достаточно ли обуче-

ны сотрудники и ис-

пользуются ли они в

соответствии с ква-

лификацией)

9.2.6 Советуются ли руководители с исполнителями

перед принятием решений, касающихся выпол-

няемой ими работы?

9.2.7 Осознают ли сотрудники важность соблюдения

плана?

9.2.8. Привлекают ли руководители разработчиков

для участия в совещаниях с заказчиком?

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

9.3.1. Подобран ли компетентный персонал для вы-

полнения функций обеспечения качества ПО в

рамках проекта?

9.3.2 Есть ли определенный механизм проверки ка-

чества?

9.3.3 На всех ли уровнях и стадиях разработки вы-

полняются процедуры обеспечения качества?

в) Обеспечение ка-

чества

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

есть ли надлежащие

ресурсы и процедуры

для обеспечения ка-

чества продукта)

9.3.4 Привыкли ли люди к выполнению процедур

обеспечения качества?

9.4.1 Есть ли адекватная система управления конфи-

гурацией?

9.4.2 Подобран ли компетентный персонал для вы-

полнения функции управления конфигурацией?

9.4.3 Не нужна ли координация с какой-либо уста-

новленной на месте системой?

9.4.4 Если координация нужна, то выполняется ли

управление конфигурацией этой установленной

системы?

9.4.5 Отражает ли система управления конфигура-

цией изменения, происходящие по месту уста-

новки?

9.4.6 Не распределена ли разработка по нескольким

соисполнителям?

г) Управление кон-

фигурацией

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

есть ли процедуры

внесения изменений

или контроля версий

продукта, в частно-

сти, при территори-

ально распределен-

ной разработке)

9.4.7 Если да, то рассчитана ли система управления

конфигурацией на поддержку распределенной

разработки?

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

Класс:

Среда и технология разработки

Элемент:

Рабочая обстановка

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

10.1.1 Осведомлены ли сотрудники всех уровней о

процедурах обеспечения качества?

а) Качество работы

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

ориентированы ли

исполнители на каче-

ственное выполнение

работы)

10.1.2 Не является ли график разработки помехой

обеспечению качества?

10.2.1 Есть ли сотрудничество в рамках совместно

выполняемых функций?

10.2.2 Эффективно ли взаимодействуют сотрудники

на пути достижение общих целей?

б) Кооперация

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

ли преград к сотруд-

ничеству, не нужны

ли административные

меры для погашения

конфликтов)

10.2.3 Редко ли нужно вмешательство руководства для

обеспечения совместной работы исполнителей?

в) Коммуникация

10.3.1 Хорошо ли осуществляются взаимосвязи между

всеми участниками проекта?

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

достаточно ли

10.3.2 Предрасположены ли менеджеры к обмену ин-

формацией с исполнителями?

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

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

попросить менеджеров о помощи?

10.3.4 Могут ли члены проекта самостоятельно выяв-

лять риски, не заручаясь поддержкой менедже-

ров?

информированы со-

трудники об общих

целях и задачах, нет

ли преград на пути

распространения ин-

формации о рисках)

10.3.5 Оповещаются ли своевременно члены проекта о

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

ими работы?

10.4.1 Хороший ли моральный климат в коллективе? 10

10.4.2 Быстро ли выясняются и устраняются любые

причины, ухудшающие моральный климат в

коллективе?

г) Моральный кли-

мат

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

способствует ли ра-

бочая атмосфера в

коллективе эффек-

тивной работе)

10.4.3 Есть ли возможности удержать в коллективе

нужных специалистов?

Класс С. Внешние ограничения проекта

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

Класс:

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

Элемент:

Ресурсы

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

11.1.1 Стабильны ли сроки, отведенные для разработ-

ки?

11.1.2 Реальны ли сроки? 10

11.1.3 Основан ли метод определения сроков на исто-

рических данных?

11.1.4 Хорошо ли этот метод зарекомендовал себя? 10

а) Сроки разработ-

ки

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

являются ли сроки

нереальными и непо-

стоянными)

11.1.5 Адекватно ли планирование продолжительно-

сти разработки внутренним и внешним факто-

рам?

11.2.1 Все ли необходимые специальности и должно-

сти для выполнения работ по проекту преду-

смотрены в штатном расписании проекта?

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

лификации на всех уровнях разработки (уком-

плектован ли штат)?

11.2.3 Стабилен ли коллектив разработчиков? 10

11.2.4 Возможно ли, при необходимости, привлечение

специалиста требуемой квалификации?

11.2.5 Имеют ли разработчики опыт разработки сис-

тем данного типа?

11.2.6 Есть ли дублирование ведущих специалистов,

на которых опирается проект?

б) Штат проекта

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

укомплектован ли

проект необходимым

штатом исполните-

лей)

11.2.7 Есть ли резерв свободных специалистов на всех

уровнях разработки?

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

11.3.1 Стабильно ли финансирование? 10

11.3.2 Основана ли стоимость проекта на реалистиче-

ских оценках?

11.3.3 Основан ли метод оценки на исторических дан-

ных?

11.3.4 Хорошо ли этот метод зарекомендовал себя? 10

11.3.5 Не происходит ли потеря функций и свойств

разрабатываемого продукта в связи с оптимиза-

цией проекта по критерию стоимости?

11.3.6 Выделено ли финансирование на все виды работ

(например, на анализ и разработку концепции,

оценку качества, обучение эксплуатации и со-

провождению и т.д.)?

11.3.7 Корректируется ли стоимость при изменении

требований?

в) Финансирование

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

достаточно ли и ста-

бильно ли финанси-

рование)

11.3.8 Если да, то является ли это частью процесса

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

11.4.1 Адекватны ли средства поддержки разработки

потребностям проекта?

г) Средства разра-

ботки

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

статочно ли средств

для разработки и по-

ставки продукта)

11.4.2 Адекватна ли среда интеграции? 10

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

Класс:

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

Элемент:

Условия договора

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

12.1.1 Подходит ли тип договора по всем аспектам

разработки проекта (не обременителен ли дого-

вор)?

а) Тип договора

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

жет ли риск быть

связан с типом зак-

лючаемого договора)

12.1.2 Устраивают ли установленные в договоре тре-

бования к подготавливаемой документации (по

составу и объему)?

б) Ограничения до-

говора

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

накладывает ли дого-

вор ограничения на

методы и средства)

12.2.1 Есть ли необходимая объективная информация

для выполнения разработки (по методам, сред-

ствам поддержки разработки, по разрабатывае-

мому и приобретаемому ПО и др.)?

в) Договорные за-

висимости

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

зависит ли разработ-

ка проекта от внеш-

них факторов)

12.3.1 Не зависит ли проект от внешних факторов,

которые могут повлиять на характеристики раз-

рабатываемой системы, сроки или стоимость

(зависимость от поставщиков, соисполнителей,

заказчика и т.д.)?

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

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

13.1.1 Своевременно ли заказчик утверждает все реше-

ния (по документации, ревизиям ПО, формаль-

ным ревизиям)?

13.1.2 Приступаете ли вы к выполнению работ только

после согласования решений с заказчиком?

13.1.3 Разбирается ли заказчик в технических аспек-

тах системы?

13.1.4 Разбирается ли заказчик в ПО? 10

13.1.5 Избегает ли заказчик вмешательства в процесс

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

13.1.6 Своевременно ли руководство проекта и заказ-

чик достигают взаимоприемлемых решений (по

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

териям, срокам)?

а) Заказчик

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

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

связанные с заказчи-

ком, такие как затя-

нутое согласование

решений, плохое

взаимодействие, не-

адекватное обследо-

вание предметной

области)

13.1.7 Эффективен ли механизм взаимодействия с

заказчиком?

13.1.8 Пожелания всех ли категорий заказчиков учиты-

ваются при достижении соглашений?

13.1.9 Если да, то определен ли этот процесс формаль-

но?

13.1.10 Объективную ли информацию предоставляет

руководство разработчика заказчику?

Если проект выполняется ассоциированными смежниками:

13.2.1 Проводится ли изменение внешних интерфейсов

только после надлежащего уведомления, коор-

динации или выполнения формальных процедур

изменения?

13.2.2 Есть ли адекватный план взаимодействия

смежников?

13.2.3 Если да, то соблюдается ли он всеми смежни-

ками?

13.2.4 Своевременно ли вы получаете от смежников

информацию о сроке и предмете (объекте) уста-

новления очередного интерфейса?

б) Смежники

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

возникают ли про-

блемы в проекте из-

за сбоев во взаимо-

действии смежников)

13.2.5 Пунктуальны ли смежники?

Если головной исполнитель проекта имеет соисполнителей (субподрядчиков):

13.3.1 Если есть соисполнители, то устранены ли все

неясности в определении их задач?

13.3.2 Используют ли соисполнители те же процеду-

ры управления и отчетности, что и головной

исполнитель?

в) Соисполнители

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

есть ли риск головно-

го исполнителя при

работе с соисполни-

телями)

13.3.3 Не осуществляется ли административное и

техническое управление соисполнителем сто-

ронней (не головной) организацией?

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

13.3.4 Есть ли возможность не полагаться на экспер-

тизу соисполнителя в любых областях?

13.3.5 Возможно ли извлечение и передача знаний

соисполнителя головному исполнителю?

13.3.6 Своевременно ли вы получаете от соисполните-

лей информацию о сроках и данных по заплани-

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

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

13.4.1 Хорошо ли вы понимаете свою задачу, сформу-

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

13.4.2 Осуществляется ли административное и техни-

ческое руководство одним исполнителем?

13.4.3 Независимы ли вы от экспертов головного ис-

полнителя в любых областях?

г) Головной испол-

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

нить, есть ли риск

проекту, выполняе-

мому соисполните-

лем, со стороны го-

ловного исполните-

ля)

13.4.4 Своевременно ли вы получаете от головного

исполнителя информацию о сроках и данных по

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

13.5.1 Сообщает ли руководство проектом о своих

проблемах высшему руководству?

13.5.2 Если да, то имеет ли это эффект? 10

13.5.3 Обеспечивает ли высшее руководство своевре-

менную поддержку в решении ваших проблем?

13.5.4 Позволяет ли управление со стороны высшего

руководства (на макроуровне) избежать управ-

ления на микроуровне?

д) Высшее руково-

дство

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

достаточна ли под-

держка проекту со

стороны высшего

руководства органи-

зации)

13.5.5 Предоставляет ли ваше руководство высшему

руководству объективную информацию о со-

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

е) Продавцы

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

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

щики)

13.6.1 Можно ли положиться на продавцов, ответст-

венных за поставку критических компонентов

системы (в плане сроков, стоимости и техниче-

ских характеристик)?

ж) Политические

принципы

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

ли угроз проекту со

стороны полит. раз-

ногласий заинтересо-

ванных сторон)

13.7.1 Свободен ли проект и принимаемые техниче-

ские решения от влияния политических принци-

пов руководства организаций-участников проек-

та?