Оцінки процесу розробки програмного забезпечення

використовуються для визначення:

1. Оценка процесса происходит путем сравнения процесса

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

Що з наступного є перевагою використання методів визначення

метрик на підставі "ціль-питання" ?
effective use of resources and rapid and focused improvement.
2.Вопрос
Эффективое использоваение ресурсов и быстрое и сфокусированное
улучшение

Відповідно до CMMI, метою планування проекту з розробки

програмного забезпечення є:
CMMI содержит набор рекомендаций в виде практик, реализация которых,
по мнению разработчиков модели, позволяет реализовать цели,
необходимые для полной реализации определённых областей
деятельности.
Использование данной модели позволяет организации оценить
3.Вопрос
эффективность бизнес-процессов, установить приоритетные направления их
усовершенствования, а также внедрить данные усовершенствования.
Однако следует помнить, что нельзя улучшать бизнес-процессы во имя их
улучшения, данные улучшения должны помогать бизнесу, достичь
поставленных перед ним целей. Также необходимо иметь в виду, что
улучшение процессов это долговременное, стратегическое усилие
организации.
 Що з переліченого є найбільш важливим критерієм для вибору моделі
надійності програмного забезпечення ?

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

4.Вопрос
порядка их совместного использования для определения надежности
программного обеспечения на протяжении всего его жизненного цикла.
Поэтому существует необходимость определять надежность программного
обеспечения на всех стадиях его жизненного цикла.
5.Вопрос Що з переліченого нижче є основоположним принципом запобігання
дефектів програмного забезпечення ?
Самоконтроль - ? Poka-yoke (Принцип нулевой ошибки, англ. Zero defects)

Вряд ли возможно разрабатывать ПО вообще без дефектов, но

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

 Прототипирование. Создание и опробование модели

разрабатываемой системы с целью проверить ее
характеристики и выявить неверные предположения и
решения, которые могли бы привести к серьезным дефектам (и
переделкам) при разработке [6].
 Использование стандартов на все виды продуктов,
производимых в ходе разработки ПО (требования, дизайн,
код, различная документация и т.д.).
 Применение компонентного подхода [6].
 Использование готовых компонентов— чем меньше
приходится разрабатывать новых решений, тем меньше
ошибок.
 Предварительная разработка тест-кейсов (до этапа
кодирования) позволяет глубже понять требования к
разрабатываемой системе и лучше спроектировать ее. Частный
случай этого подхода— Test-Driven Development, при котором
модульные тесты разрабатываются не после, а до кодирования.
 Рефакторинг кода, то есть приведение его в надлежащий вид
[5].
 Регулярный анализ причин появления наиболее серьезных
дефектов и поиск путей устранения этих причин. Это
может происходить на периодических собраниях команды
разработчиков [3], или можно проводить такой анализ для
каждого серьезного дефекта, найденного на этапах системного
тестирования или после внедрения. Результатом такого
анализа должны быть модификации процесса разработки,
направленные на устранение причин появления дефектов или,
 как минимум, способствующие более раннему обнаружению
подобных дефектов.

Стоит также упомянуть человеческий фактор— никакие методы не

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

6.Вопрос Що з перерахованого нижче є допустимою ціллю якості програмного

забезпечення ?

Цели в области качества являются основой для разработки

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

Во-первых, цель должна быть конкретной (Specific). Это означает,

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

Во-вторых, цель должна быть измеримой (Measurable). Т.е. на

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

В-третьих, формулировка цели должна мотивировать на ее

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

В-четвертых, цель должна быть реалистичной (Realistic). Если

установить заведомо недостижимые цели, то стимула к достижению
такой цели тоже не будет.

В-пятых, цель должна быть ограничена во времени (Time framed). На

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

Так как цели в области качества имеют привязку ко времени, то по

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

 Цели в области качества корпоративного уровня;

 Цели в области качества по подразделениям;
 Цели в области качества по процессам;
 Цели в области качества по продуктам (услугам).

Відповідно до ISO 9001, записи відносно якості повинні бути

7.Вопрос
збережені для того, щоб:
Якщо вся площа під кривою Релея стає менше, то прогнозований
8.Вопрос
відсоток дефектів буде: больше(?)
Що з наступного характеризує вартість помилок ? этап
9.Вопрос разработки(чем больше кода написали и чем дальше, тем выше
стоимость ошибки) - ?
У чому основна різниця між оглядами та інспекціями ?
программного продукта и совершенствование навыков
разработчика.

1..Вопрос В процессе инспекции кода могут быть найдены и

устранены такие проблемы, как ошибки в форматировании
строк, состояние гонки, утечка памяти и переполнение
буфера, что улучшает безопасность программного
продукта.
 Яке з наступних тверджень є істинним з позицій діаграми, наведеної
нижче ?

11.Вопрос