Разумеется, присутствие таких слов в документе не значит, что документ неоднозначен, а только говорит о возможной неоднозначности.
Отслеживание и контроль проекта (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.
Деятельности по собственно разработке, отслеживанию и контролю объемлются постоянно идущими деятельностями по верификации и валидации (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), проводимого уполномоченными на то организациями или лицами. Результаты всех деятельностей доводятся до сведения всех исполнителей и заказчика для выработки и принятия к исполнению при необходимости соответствующих поправочных действий.
Обеспечение качества (Software Quality Assurance – SQA) представляет собой ряд деятельностей, обеспечивающих заданное качество будущего программного продукта. В своем самом простом виде оно состоит в регулярной проверке того, что разработчики выполняют свои обязанности в соответствии со стандартами и требованиями организации, данной проектной группы и заказчика. Обычно в проекте выделяется отдельная роль инженера по качеству (как правило, часть полной ставки) из специальной группы качества, которая обслуживает все проекты в данной организации и подчиняется непосредственно ее руководителю. Этот специалист совместно с разработчиками и руководством обеспечивает корректную реализацию процесса разработки и непрерывное улучшение всего производственного процесса в данной организации и росту качества выпускаемых программных продуктов.
В плане разработки предусматривается отдельный план по обеспечению качества, в котором прописываются соответствующие действия: разработки и уточнение стандартов, процедур и шаблонов для соответствующих рабочих продуктов проекта, обзоры, инспекции кода и документации, повышение квалификации, процедуры документирования и отслеживания разрешения разногласий и другие действия, запланированные для достижения поставленных целей по качеству. При этом должно быть предусмотрено и выделение адекватных этим задачам ресурсов. Этот план готовится, начиная с ранних этапов проекта и параллельно с разработкой общего проектного плана, и все относящиеся к проекту лица и группы должны ознакомиться с ним в обязательном порядке.
Планом обеспечения качества определяется документация, которую должна создавать группа качества, методика и частота предоставления сведений проектным и всем заинтересованным группам (так реализуется обратная связь). Процедуры, относящиеся к обеспечению качества, могут описываться в плане или представляться в виде ссылок на другие документы, в которых содержится их описание.
Группа качества через своего выделенного представителя принимает участие в подготовке и проверке соблюдения проектного плана, стандартов и процедур. Она проверяет стандарты и процедуры, используемые в проектах, на предмет соответствия принятым в организации стандартам, требованиям применимости стандартов к конкретному проекту. Проверяет наличие в проектных планах необходимых разделов, связанных с обеспечением качества, наличие в каждом проекте и доступность всем относящимся к проекту лицам планов, стандартов и процедур, установленных процессом. При необходимости инженер по качеству консультируется по спорным вопросам данного проекта с другими членами группы качества и ее руководителем.
Группа качества проверяет работы по проектированию программного продукта с точки зрения их соответствия проектному плану. Она сопоставляет деятельность по разработке с планом, процедурами и стандартами с целью обнаружения отклонений. Выявленные отклонения в обязательном порядке документируются, составляется план устранения выявленных недостатков. В последующем проверяется устранение выявленных недостатков, сопоставляются сроки их устранения с плановыми данными.
Группа качества также проверяет качество создаваемых рабочих продуктов и устанавливает их соответствие или несоответствие условиям контракта на разработку. Все рабочие продукты, предназначенные для поставки, обязательно проверяются до передачи заказчику на предмет их соответствия стандартам, процедурам и требованиям заказчика. Выявленные отклонения документируются, составляется план их устранения, который в дальнейшем проверяется.
Обнаруженные отклонения документируются и обрабатываются в соответствии с формальной процедурой. При обнаружении отклонений вопрос о возможности продолжения работ по разработке сначала обсуждается с соответствующими руководителями групп или руководителем проекта. Вопросы, которые разрешить с руководителями групп или руководителем проекта не удается, сообщаются старшему руководителю, ответственному за разрешение разногласий, и регулярно проверяются на предмет разрешения. Группа SQA регулярно обсуждает результаты своих проверок с персоналом аналогичного подразделения заказчика.
Обычно все метрики по программным проектам собираются и накапливаются в группе качества для их анализа и учета в планировании и проверке соответствующих деятельностей. Группа SQA ведет эту метрическую БД и регулярно дополняет ее данными из внешних источников.