Материал: DO178 Учебное пособие_в183

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

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

    1. Отслеживание и контроль

Отслеживание и контроль проекта (Project Tracking and Control) сопровождает программную разработку на протяжении всего ее жизненного цикла и обеспечивает:

  • реалистичное распределение задач по фазам проекта и между исполнителями;

  • разрешение перекрытий/сжатий графика и иных конфликтов;

  • раннее выявление ошибок в продукте и планах по его разработке;

  • учет возможных будущих изменений в проекте;

  • регулярную проверку взаимозависимостей в проекте;

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

  • учет фактической обеспеченности кадрами и распределения задач между исполнителями.

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

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

Табл. 12. Форма для заполнения ежедневных трудозатрат участником проекта

Код ра-бо-ты

Наименование работы

Затрачен-ное время

Объем работы, выполненной за день

Общ. объем вып. работ

Текст

Код

Кол-во дефек-тов

План

Факт

Новых

Переис-польз.

Удален-ных

часы

часы

слов

KAELOC

KAELOC

KAELOC

шт.

%

 

Фазы жизненного цикла:

 

 

 

 

 

 

 

 

CE

Концептуализация НИР -- Concept Exploration

 

 

 

 

 

 

 

 

Pl

Планирование и требования – Planning

 

 

 

 

 

 

 

 

ThR

Теоретическое обоснование – Theoretical Research

 

 

 

 

 

 

 

 

PrS

Получение результатов -- Problem Solving

 

 

 

 

 

 

 

 

Ver

Проверка результатов – Verification

 

 

 

 

 

 

 

 

Fin

Сдача заказчику – Finalizing

 

 

 

 

 

 

 

 

 

Ключевые работы:

 

 

 

 

 

 

 

 

IS

Поиск в Интернет -- Internet Surfing

 

 

 

 

 

 

 

 

RL

Чтение литературы – Reading

 

 

 

 

 

 

 

 

Th

Обдумывание – Thinking

 

 

 

 

 

 

 

 

Dv

Разработка – Development

 

 

 

 

 

 

 

 

Sm

Семинары – Seminar

 

 

 

 

 

 

 

 

Rv

Обзоры -- Review

 

 

 

 

 

 

 

 

Tr

Обучение – Training

 

 

 

 

 

 

 

 

CM

Управление конфигурацией – Configuration Management

 

 

 

 

 

 

 

 

ИТОГО:

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

    1. Верификация и валидация

Деятельности по собственно разработке, отслеживанию и контролю объемлются постоянно идущими деятельностями по верификации и валидации (Verification and Validation – V&V) как создаваемых в них рабочих продуктов, так и самих процессов и технологических приемов их создания.

Верификация – это проверка корректности реализации; т.е., соответствия выполненных деятельностей известным стандартам и процедурам. Отвечает на вопрос: “Правильно ли это сделано? – Did we do the thing right?”

Валидация – это проверка пригодности созданной реализации к предполагаемому использованию; т.е., того, что она действительно заключает в себе заявленную для заказчика ценность. Отвечает на вопрос: “Сделано ли действительно то, что нужно? – Did we do the right thing?”

Очевидно, что корректно построенный программный продукт (т.е., успешно прошедший верификацию), может оказаться непригодным к использованию и тем самым привести проект к неудаче. Типичными деятельностями по верификации и валидации являются регулярные внутренние аудиты (internal audits), отчеты по качеству (quality reports) создаваемых рабочих продуктов и оценивания (assessments) в форме самооценивания (self-assessment) или официального оценивания (formal assessment), проводимого уполномоченными на то организациями или лицами. Результаты всех деятельностей доводятся до сведения всех исполнителей и заказчика для выработки и принятия к исполнению при необходимости соответствующих поправочных действий.

    1. Обеспечение качества

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

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

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

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

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

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

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

Обычно все метрики по программным проектам собираются и накапливаются в группе качества для их анализа и учета в планировании и проверке соответствующих деятельностей. Группа SQA ведет эту метрическую БД и регулярно дополняет ее данными из внешних источников.

Источник: https://studfile.net/preview/16431019/