И. Соммервилл - Инженерия программного обеспечения (1133538), страница 130
Текст из файла (страница 130)
Группы обеспечения качества. которые занимаются составлением стандартов, обычно основывают нормативы организации на общих национальных и мсждународных стандартах. Используя их в качестве отправного пункта, группа обеспечения качества разрабатываст свой "справочник" по стандартам. В нсм содержатся стандарты, отражающие специфику дсятсльности данной органиэации. В табл. 24.2 приведены примеры стандартов, которыс могут входить в состав такого справочника.
24, Управление качеством 499 Чтобы нс возникало подобных проблем в работе, менеджеры по качеству, отвечающие за разработку стандартов, должны быть достаточно подготовленными и действовать следующим образом. 1. Вовлечь самих программистов в разработку стандартов. Они должны ясно понимать, с какой целью разрабатывается стандарт, и четко следовать установленным правилам и нормативам.
Важно, чтобы документ с описанием стандарта включал не только изложение самого норматива качества, но и объяснение необходимости именно этого норматива. 2. Регулярно просматривать и обновлять стандарты, чтобы идти в поо с быстро раэ вивающимися технологиями. Как только стандарт разработан, его помещают в справочник организации по стандартам, где его холят и лелеют, меняя с большой неохотой. Справочник по стандартам — вещь длл организации необходимая, однако он должен развиваться по мере развития новых технологий.
3. Подумать о том, чтобы обеспечить поддержку стандартов программпымн средствами везде, где только можно, Всяческие "канцелярские" стандарты вызывают ог. ролщое количество жалоб. связанных с нудной и утомительной работой по их выполнению. Если же имеются в наличии средства поддержки, выполнение стандартов не требует больш нх усилий. Стандарты на процессы разработки ПО также могут вызвать ряд проблем, если ставят перед командой разработчиков практически неосуществимые задачи.
Такие ста~щарты дают руководящие советы по выполнению работы, при этом менеджеры проектов могут интерпретировать их каждый по.своему. Нет смысла указывать определенное паправле. ние работы, если оно неприменимо к данному проекту или к самой команде рээрабатчи. ков. Поэтому менеджер проекта должен иметь право изменять стандарты процесса создания ПО в соответствии со специфическими условиями именно данного проекта. Здесь следует оговоритьсл, что это утверждение не относится к стандартам на качество готовой продукции и на процесс сопровождения программной системы, которые могут быть из. мепспы только после глубокого изучспил данного вопроса.
Менеджер проекта и менеджер по управлению качеством могут легко избежать подводных камней, связанных с "неподходюцимн" стандартами, путем тщательной разработки плана мероприятий по обеспечению качества. Именно они должны решить, какие стандарты из справочника можно использовать без изменений, какие нз пих подлежат изменению, а какие следует исключить.
Иногда возникает необходимость в разработке нового стандарта, что может быть вызвано условиями выполнения определенного проекта. Например, трсбустсл установить стандарт длл формальной спецификации, если прежде в проектах он не использовался. Такие стандарты должны разрабатываться в процессе выполнения проекта. 24.1.1. Стандарты на техническую документацию Необходимость стандартов на документацию в программном проекте становится очевидной, если пе существует никакого другого реального способа отображения процесса разработки ПО.
Стандартные документы имеют четкую последовательную структуру, вид и качество, а значит, их легко читать и воспринимать. Существует три типа стандартов па документацию. 1. Спшядлрлпи нл процесс оидлнкл докулензюции. Определяют способ создания технической документации. 500 Часть в э. Управление 2. Смондаргом но оокуменвс. Опрсдсляют структуру и внешний вид документов. 3.
Сжондорши на обчен дмсуненвньнн. Гарантируют совместимость всех электронных версий документов. Стандарт на процесс создания документации предоставляет описание способа изготовления документов. Он включает описания действий по созданию документов и предло. латает программные средства для нх создания. Кроме этого, нужно описать процедуры проверки и редактирования документов, благодаря которым обеспечивается необходимый уровень их качества. Станларты качества на процесс документирования должны быть достаточно гибкими, чтобы их можно было применять ко всем типам документации.
Естественно, совсем нс. обязательно проводить дегальныс проверки качества рабочей документации или служебных записок. Однако при работе с официальными документами, имеющими отношение к дальнейшей разработке продукта либо предназначенными лля заказчика, нужно иметь ус. тановленную процедуру проверки их качества. На рис. 24.3 показана одна из возможных моделей такого процесса. Этап 3.
Пвчать Рнс 24з. Прокосе создания докузмнмоунн, вкеючяюмнй проверку зсачепнво докднентов Этапы сбора, учета и внссенил замечаний в проект или очередную версию документа повторяются до тех пор, пока не будет создан документ соответствующею уровня качест. ва. Уровень качества документа зависит от типа документации и от того, кому предназначен данный документ. Стандарты на документацию следует применять ко всем документам, которые создаются в процессе работы над программнылз продуктом.
Такие документы должны быть одинако. ными по стилю изложения и внешнему виду, а документы, которые относятся к одному типу, должны также иметь одинаковую структуру. Несмотря на то что стандарты на документацию ма~ус быть адаптированы к определенного вида проектам, все жс для органиэации неплохо было бы выработать собственный "фирменный" стиль, применяемый ко всем документам. 24. Управление качеством 501 Приведем примеры различных стандартов на документацию. 1. Сэындпрэгм идюгтификлциоггггмк дгжулгнэкм.
В процессе создания больших систем производятся тысячи документов, каждому из которых должно быть присвоено уникальное имя, т.е. каждый документ должен быть идентифицирован по определенной системе. Для формальных документов может применяться формальный идентификатор, определенный менеджером по конфигурации. Для неформальных документов идентификатор может быть определен менеджером проекта.
2. Сэглмдл)гэги на гжрукжу)гу дакунгнэкь Кажлый класс документов, создаваемый в процессе разработки ПО, должен иметь стандартную структуру. Стандартами на струк. туру определяются разделы, которые входят в документ, а также элсмснты форматирования и макетирования документа, например нумерация страниц, содержание верхнего и нижнего колонтитулов, нумерация разделов и подразделов. 3.
Сэюнд~фжм вижкнего вЫа дакумгяэюцик. Эти стандарты определяют "фирменный" стиль документов: использование шрифтов и стилей, логотипов, назвапнл фирмы, цветовых выделений для элементов структуры документа и т.д. 4. Сжлггдаржм нп обновление докумгяэитции. Так как докуменгы должны отображагь изменения, возникающие в процессе разработки системы, желательно применять по.
следовательный способ обозначения изменений в документации. Чтобы выделить новую, измененную версию документа, для печатных документов можно использовать обложки разных цветов, а для выделения изменений в тексте можно делать цветовые указатели иа полях. Особал роль отводится стандарту на совместимость документов, так как часто приходится работать с разными электроннымн версиями документов.
Использование стандартов на совместимость позволяет осуществлять передачу документов в электронном виде и при необходимости восстанавливать их в первоначальном виде. Поскольку стандартами на процесс создания документации предусмотрено использование инструментальных средств, стандарты на совместимость очерчивают сферу и способ использования таких средств в работе нэд документами. В качестве примера подобных стандартов на совместимость можно привести согласованный стандарт на комплект макросов при форматировании текста документа или на использование стандартной таблицы стилей (шаблонов) при работе с системами обработки текстов.
Кроме того, введение в действие стандартов на совместимость может ограничить количество используемых шрифтов и стилей, что вызвано различными возможностями принтеров и компьютерных дисплеев. 24.1.2. Качество процесса создания ПО и качество программного продукта Правило, лежащее в основе успешного управления качеством, гласит, что качество процесса производства ПО влияет и на качество готового программного продукта. Это предположение первоначально появилось в сфере промышленного производства, где качество продукции напрямую связано с качеством процесса ее изготовления.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
